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

[Robert Milasan]

On Thu, 25 Jun 2015 21:15:18 +0200
"Johannes Bauer" <dfnsonfsduifb at gmx.de> wrote:

> Hi list,
> 
> I'm seeing a very odd issue with udev and I'm not really sure which
> component could/would be responsible -- udev is pretty much my only
> hope.
> 
> Here's the situation: I have a USB/serial converter attached to my
> computer. It's detected as /dev/ttyUSB0. A program is started as my
> local user (UID 1000) and forks into the background. Every now and
> then it sends one of four characters to this device and reads a bit
> of data back. So far, so good, everything working as expected.
> 
> Now the odd thing: When I put my computer into suspend-to-RAM, I'm
> seeing something very odd when the thing wakes back up (about 3 in 4
> times this happens, nondeterministically). The character device
> /dev/ttyUSB0 is replaced by a regular file with 0644 permissions which
> is owned by root:root:
> 
> joequad joe [~]: ls /dev/ttyUSB0
> -rw-r--r-- 1 root root 1   25.06.2015 18:09:29 /dev/ttyUSB0
> joequad joe [~]: cat /dev/ttyUSB0 | hexdump -C
> 00000000  24                                                |$|
> 00000001
> 
> 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).
> 
> Here's what dmesg says when suspending/waking up:
> 
> [...] lots of output [...]
> [186649.272605] ark3116 ttyUSB0: ark3116 converter now disconnected
> from ttyUSB0
> [186649.272619] ark3116 7-2.2:1.0: device disconnected
> [186650.452061] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [186650.888603] ACPI Error: [DSSP] Namespace lookup failure,
> AE_NOT_FOUND (20131115/psargs-359)
> [186650.888605] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0.SAT1.SPT2._GTF] (Node ffff880893e1ae38), AE_NOT_FOUND
> (20131115/psparse-536)
> [186651.030846] ACPI Error: [DSSP] Namespace lookup failure,
> AE_NOT_FOUND (20131115/psargs-359)
> [186651.030849] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0.SAT1.SPT2._GTF] (Node ffff880893e1ae38), AE_NOT_FOUND
> (20131115/psparse-536)
> [186651.031003] ata7.00: configured for UDMA/133
> [186651.031097] sd 6:0:0:0: [sdc] Starting disk
> [186652.988078] ata6: link is slow to respond, please be patient
> (ready=0) [186655.676059] ata6: SATA link up 3.0 Gbps (SStatus 123
> SControl 300) [186655.679062] ACPI Error: [DSSP] Namespace lookup
> failure, AE_NOT_FOUND (20131115/psargs-359)
> [186655.679069] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0.SAT1.SPT1._GTF] (Node ffff880893e1adc0), AE_NOT_FOUND
> (20131115/psparse-536)
> [186655.712350] ACPI Error: [DSSP] Namespace lookup failure,
> AE_NOT_FOUND (20131115/psargs-359)
> [186655.712356] ACPI Error: Method parse/execution failed
> [\_SB_.PCI0.SAT1.SPT1._GTF] (Node ffff880893e1adc0), AE_NOT_FOUND
> (20131115/psparse-536)
> [186655.712521] ata6.00: configured for UDMA/133
> [186655.712640] sd 5:0:0:0: [sdb] Starting disk
> [186655.720875] PM: resume of devices complete after 8128.520 msecs
> [186655.720895] ark3116 7-2.2:1.0: ark3116 converter detected
> [186655.721740] usb 7-2.2: ark3116 using RS232 mode
> [186655.721822] usb 7-2.2: ark3116 converter now attached to ttyUSB0
> [186655.722165] PM: Finishing wakeup.
> 
> My userspace program happens to hang in a call to write(2) when the PC
> is put in suspend. The write returns with errno = 5 (I/O error) when
> the PC comes back up.
> 
> Another clue is here: I've seen this issue with my old (much slower
> PC) before. But it happened very sporadically, about once every 30
> suspend/wakeup-cycles. I thought this was odd, but blamed some weird
> random component to do this. Now I've switched to a much faster
> computer and am seeing this issue in around 75% of all
> suspend/wakeup-cycles and it's really annoying the hell out of me. So
> I'm guessing there's some kind of race condition involved which hits
> much more often now that my PC is fast enough.
> 
> Oh, I'm running Linux Mint on x86_64. udev is version 204.
> 
> If you have any hints whatsoever on how I could debug this really
> weird issue, please let me know. I really just don't have a clue how
> to debug udev/this weird phaenomenon.
> 

Don't think udev is creating those char devices in such a new version.
I think is handled by the kernel.

I've seen such a bug once, but it was related to /dev/null, some script
or app was remove /dev/null and creating a normal file, don't know why.