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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
