Re: [Boost-users] Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)

Subject: Re: [Boost-users] Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)
From: Mathieu Peyréga (mathieu.peyrega_at_[hidden])
Date: 2018-01-12 09:54:11

> 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_at_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-opened-by-another-application-in-c 
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 : [phone]