Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)
Hello, i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I facing the fact that open("port name", error_code) command on an already openned port do not return an error. My test sequence : On the same machine I pre-open /dev/ttsS0 on minicom : minicom -D /dev/ttyS0 and check that is indeed open by sending some chars. Now while minicom still openned, I try openning a second minicom on same /dev/ttyS0 and this return an error : "device /dev/ttyS0 locked" as expected. So the device and system is able to knows that ttyS0 is already open (minicom + OS is capable of doing that) Now, with first minicom still running, if I run my program which is doing open("/dev/ttySO",ec), ec is 0 and further is-open() returns true while obviously the port is not openned. When device not already openned with minicom, my software is behaving properly. Am I doing something wrong detecting if the "open" operation suceeded ? I have a separated boost::thread io_thread(boost::bind(&C_IO_Controller::run,&theIOController)); that is running the boost::asio::io_service object the open command is called from the main thread (not the io_thread ) Regards Mathieu
Hello, this probably is a linux issue.
i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I facing the fact that open("port name", error_code) command on an already openned port do not return an error.
My test sequence :
On the same machine I pre-open /dev/ttsS0 on minicom : minicom -D /dev/ttyS0 and check that is indeed open by sending some chars.
You could use /dev/cua*-devices for this instead of /dev/ttyS*. /dev/cua*-Devicess take exclusive use of the serial port, while /dev/ttyS* are intended for being used in interactive sessions (with a serial terminal attached). Until recently, the linux kernel included a file Documentation/devices.txt (It was there in Linux-4.9.72) saying /dev/cua* are major 5, minor 64 and up. Newer kernels describe the cua*-devices in Documentation/admin-guide/devices.rst.
Now while minicom still openned, I try openning a second minicom on same /dev/ttyS0 and this return an error : "device /dev/ttyS0 locked" as expected.
This works, because minicom uses additional locking with a lock-file. If you strace minicom, you will see, that minicom not even tried to open /dev/ttyS0. The locking procedure for serial ports also is described in Documentation/admin-guide/devices.rst. 73, Mario -- Mario Klebsch Actia I+ME GmbH Mario.klebsch@ime-actia.de Dresdenstrasse 17/18 Fon: +49 531 38 701 716 38124 Braunschweig Fax: +49 531 38 701 88 Germany
2018-01-11 12:12 GMT+03:00 Mathieu Peyréga via Boost-users <boost-users@lists.boost.org>:
Hello,
i'm using boost asio 1.66 serial port on a Ubuntu Mate 64 machine, and I facing the fact that open("port name", error_code) command on an already openned port do not return an error.
Could you please check the previous release of Boost? For example, in my case, version 1.65.1 used on CentOS Linux release 7.4.1708 (Core). If ttyS0 opened with screen (screen /dev/ttyS0 115200) ASIO will not open it with error $ sreqrep /dev/ttyS0 "%%" [2018-01-11 17:49:30.868] [serial] [error] Error: Device or resource busy $ If your case related only to 1.66, then it'll be possible regression bug. -- Best Regards, Sergei Nikulov
Could you please check the previous release of Boost?
For example, in my case, version 1.65.1 used on CentOS Linux release 7.4.1708 (Core).
If ttyS0 opened with screen (screen /dev/ttyS0 115200) ASIO will not open it with error
$ sreqrep /dev/ttyS0 "%%" [2018-01-11 17:49:30.868] [serial] [error] Error: Device or resource busy $
If your case related only to 1.66, then it'll be possible regression bug.
Thanks for the people who answered ! Unfortunatly, i'm not able to try another bosot version right now. I can not easily change boost version and have not another machine to test. As suggested I tested starting my software and taking control of /dev/ttyS0 and then launching screen and screen start correctly (screen steals the control of /dev/ttyS0 to my software) If I try to reconnect to /dev/ttyS0 while screen still running, this time asio gives a no go (I guess screen is putting a "kernel" lock on the file) At this point, I guess this is more a Linux point that is really considering /dev/ttyS0 as a regular file and allows multiple opens unless the openning process takes a lock on it. I added that on my serial port wrapper class through flock calls call from #include <sys/file.h> flock(this->m_SerialPort.native_handle(), LOCK_EX | LOCK_NB) flock(this->m_SerialPort.native_handle(), LOCK_UN | LOCK_NB) at adequate points. This at least prevent other software from tampering with the serial port i just openned...
You could use /dev/cua*-devices for this instead of /dev/ttyS*. /dev/cua*-Devicess take exclusive use of the serial port, while /dev/ttyS* are intended for being used in interactive sessions (with a serial terminal attached). Until recently, the linux kernel included a file Documentation/devices.txt (It was there in Linux-4.9.72) saying /dev/cua* are major 5, minor 64 and up. Newer kernels describe the cua*-devices in Documentation/admin-guide/devices.rst.
those files are not exposed on my machine (kernal too old) mathieu@UbuntuMate-VirtualBox:/dev$ uname -a Linux UbuntuMate-VirtualBox 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8 16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux About minicom, it's probably getting its own internal mecanism to prevent several instances openning same port, but not actually taking a filesystem lock on the /dev/ttyS0 (maybe with a specific option it can do that but the basic -D device option does not). This means I should probably also try to see if another process is using the file. Linux had a fuser or lsof commands for that (and therefore could be implemented at code level) but they only reports process of the current user (which would already be better than nothing) Reading here https://stackoverflow.com/questions/1048592/how-to-check-if-a-file-has-been-... it seems that the last option would be to moutn the filesystem a special way and add special flag to some files but that would be very platform specific. From these findings, I believe boost::asio::serial_port should propose a (default enabled) option to implement "locking" the port at open time and checking if it's used (at least by same user) pre-open time at library level, that would make those serial port safer as most of the time, datastream going though serial ports are really not intended to have multiple talkers on any side. Regards, Mathieu -- tel : +33 (0)6 87 30 83 59
participants (1)
-
Klebsch, Mario -
Mathieu Peyréga -
Sergei Nikulov