<![CDATA[QSerialPort permissions problem (No. Not the easy problem)]]>Qt 11.2 on CentOS 7. I'm having a problem with permissions on a set of /dev/ttyUSB? devices while running Qt apps. They act like a user somehow gets an invisible exclusive ownership of a device which prevents other users from using the device, errno is set to EPERM (operation not permitted). The devices are all crw-rw-rw-, and all the users are in the dialout group. This problem persists even after unplugging/plugging the device, reboots, and power cycles. Non Qt apps like screen have no problems accessing the devices.

More information: I wrote a stub class TSerialPort : public QIODevice { } which uses calls ::open() to open the serial device. This has no problem, so I know that the base functionality of QIODevice isn't the problem.

]]>https://forum.qt.io/topic/101007/qserialport-permissions-problem-no-not-the-easy-problemRSS for NodeMon, 21 Sep 2026 08:56:59 GMTFri, 22 Mar 2019 17:10:23 GMT60<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 09:43:59 GMT]]>@Kent-Dorfman
Out of curiosity, and not wanting to start a flame war, I'm slightly surprised that you ship I/O access out-of-process. It may well be convenient for debugging/testing, but for production? Then again I know nothing about hardware, so you may so that serial port top speed is slow it doesn't matter, I don't know....

]]>https://forum.qt.io/post/519127https://forum.qt.io/post/519127Sat, 23 Mar 2019 09:43:59 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 07:29:02 GMT]]>@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):

I'd prefer it if this lock feature were optional.

Lock files it is a common practicle. Besides, it gives same behavior on different platforms (as on Windows the serial ports opened only with exclusive access). And I can't imagine at all a situation when needs an access to the same serial port from different processes.

]]>https://forum.qt.io/post/519117https://forum.qt.io/post/519117Sat, 23 Mar 2019 07:29:02 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 05:58:57 GMT]]>@aha_1980 said in QSerialPort permissions problem (No. Not the easy problem):

Yeah, but that's not cross-platform ;)

Op said he's working on Linux. Actually, I usually recommend manager daemons for access to I/O devices and use of IPC to communicate with them. By abstracting in that way the benefits are: much easier to unit test and validate, and the ability to trivially swap to different IO mechanisms. If your Serial daemon reships the data as a TCP stream then your clients only need to implement a TCP client handler...and guess what? Your serial data no longer needs to reside on the local machine. Then there is GPIO...NEVER give a userland client program direct access to GPIO. Always run it through a manager so that the client can only fiddle with the channels intended, and in a way that doesn't break things.

Anyway, more than enough comment to spawn a suitable flame war, so I digres.

]]>https://forum.qt.io/post/519114https://forum.qt.io/post/519114Sat, 23 Mar 2019 05:58:57 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 05:47:24 GMT]]>@Kent-Dorfman

I usually just do POSIX programming in a separate thread

Yeah, but that's not cross-platform ;)

]]>https://forum.qt.io/post/519113https://forum.qt.io/post/519113Sat, 23 Mar 2019 05:47:24 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 04:50:08 GMT]]>Along the lines of serial port control in Linux, nothing says you HAVE to use the Qt classes for serial access. I usually just do POSIX programming in a separate thread with its own read loop and select() to read data when it's available...because I'm much familiar more with POSIX system programming. It's then not too hard to make the data available to the GUI thread via an IPC mechanism.

]]>https://forum.qt.io/post/519112https://forum.qt.io/post/519112Sat, 23 Mar 2019 04:50:08 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 04:37:48 GMT]]>@dhkaplan

Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination.

If that's the case, then it would be a bug. Because the design is as follows:

The lock file is removed in QSerialPortPrivate::close(), which is called from QSerialPort::close() which is called from the destructor ~QSerialPort()

Result: the lock file should be removed when the serial port object is removed.

Regards

]]>https://forum.qt.io/post/519110https://forum.qt.io/post/519110Sat, 23 Mar 2019 04:37:48 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Sat, 23 Mar 2019 00:34:14 GMT]]>@Kent-Dorfman That's correct. No issues with non-Qt access to the serial ports.

]]>https://forum.qt.io/post/519103https://forum.qt.io/post/519103Sat, 23 Mar 2019 00:34:14 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 23:37:23 GMT]]>@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):

Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.

And keep in mind that lock files implemented by the QSerialPort are specific to Qt, and NOT Linux system level..IOW, they only protect exclusive access in Qt applications.

]]>https://forum.qt.io/post/519098https://forum.qt.io/post/519098Fri, 22 Mar 2019 23:37:23 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 23:09:55 GMT]]>OK I know how to deal with this now. Thanks for your help.

]]>https://forum.qt.io/post/519096https://forum.qt.io/post/519096Fri, 22 Mar 2019 23:09:55 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 21:50:01 GMT]]>@Christian-Ehrlicher Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.

]]>https://forum.qt.io/post/519086https://forum.qt.io/post/519086Fri, 22 Mar 2019 21:50:01 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 20:24:29 GMT]]>I think they're created as QTemporaryFile so they should only be there when the program crashes - at least I would expect this.

]]>https://forum.qt.io/post/519067https://forum.qt.io/post/519067Fri, 22 Mar 2019 20:24:29 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 20:23:10 GMT]]>@Christian-Ehrlicher Ah ha! There they are. Are they left hanging if the devices are not explicitly closed before the program exits?

]]>https://forum.qt.io/post/519066https://forum.qt.io/post/519066Fri, 22 Mar 2019 20:23:10 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 20:08:15 GMT]]>@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):

Is it possible that a lock is left hanging if the a program exits improperly?

At least on linux yes - see /tmp/lockTTYS0 (or something similar - don't remember exactly the naming of the file but it's obvious when you see it).

]]>https://forum.qt.io/post/519063https://forum.qt.io/post/519063Fri, 22 Mar 2019 20:08:15 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 20:08:10 GMT]]>@dhkaplan

Is it possible that a lock is left hanging if the a program exits improperly?

Could be, QSP uses lock files. Does your app exit improperly?

]]>https://forum.qt.io/post/519062https://forum.qt.io/post/519062Fri, 22 Mar 2019 20:08:10 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 20:05:41 GMT]]>@Christian-Ehrlicher This is not an problem with accessing the ports at the same time. But this brings up a question, how is this exclusivity implemented? Is it possible that a lock is left hanging if the a program exits improperly?

]]>https://forum.qt.io/post/519060https://forum.qt.io/post/519060Fri, 22 Mar 2019 20:05:41 GMT<![CDATA[Reply to QSerialPort permissions problem (No. Not the easy problem) on Fri, 22 Mar 2019 17:43:48 GMT]]>See https://doc.qt.io/qt-5/qserialport.html#details

Note: The serial port is always opened with exclusive access (that is, no other process or thread can access an already opened serial port).
]]>https://forum.qt.io/post/519044https://forum.qt.io/post/519044Fri, 22 Mar 2019 17:43:48 GMT