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
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