[systemd-devel] Weird udev issue: char device replaced by regular file on suspend

[Johannes Bauer]

On 26.06.2015 07:43, Greg KH wrote:

>> It's one byte long and this one byte is exactly the data that my
>> userspace program tried to send. But obviously my user space program
>> could not have created that node (no permission to write in /dev,
>> obviously, and my program has no suid or anything, runs just as UID 1000).
> 
> Are you sure about the permissions of that script?

Dead sure:

$ ps axu | grep hifictrl
joe       2815  0.0  0.0  16184   968 pts/5    S+   11:04   0:00 grep
--colour=auto hifictrl
joe      15670  0.0  0.0  37212  8308 ?        S    Jun23   0:43
/usr/bin/python3 ./hifictrl

$ pstree -s -p 15670
init(1)───hifictrl(15670)

$ ps -alU joe | grep hifi
1 S  1000 15670     1  0  80   0 -  9303 poll_s ?        00:00:44 hifictrl

No funny business, just my local user opening up the device file once,
then the script runs forever and occasionally does a few reads and writes.

> This really looks like the tty device is not present (suspend
> disconnects the device which removes the /dev node) and then when you
> resume, your script runs and writes a byte to /dev/ttyUSB0 before the
> device node is created.

I agree, but this wouldn't explain the user/permissions the /dev/ttyUSB0
node gets when it's created as a regular file. Another thing: Whenever
this issue hits, wouldn't the kernel recognize that /dev/ttyUSB0 is
already taken and rename the device to /dev/ttyUSB1? Because that's not
happening (there is just no char device created at all)

> Like others have said, this isn't a udev issue as udev isn't involved in
> creating device nodes.  I think you should change your script to test to
> see if /dev/ttyUSB0 is present _before_ you write to it :)

Well the thing is that I do my open once and of course I do check if
it's present before I do the open (I need to traverse some udevadm info
in order to find out which serial adapter is the correct one in case it
isn't /dev/ttyUSB0). Then I should have my fd and I don't think you
suggest rechecking if the char dev node exists before doing write(2), right?

In case the write(2) fails I wait 30 seconds before rescanning the
files, and I only ever do open(2) if the node passed all the udevadm
info checks.

So I really think that I'm innocent here and if you're saying this can't
be a kernel issue then the last one left would be the Python interpreter
itself. It performs os.write(fd, data), but this also runs with the
permissions of my local user. So, in any case, weird.

The only thing I could offer would be to strace the whole process. But
since it somehow really seems to be linked with the overall speed of my
system, I'm guessing the bug will magically disappear once I strace it :-(

Best regards,
Johannes