No way! You're totally awesome, that was the right track... On 26.06.2015 07:14, Martin Pitt wrote:
> This sounds like a script or program that runs for suspend tries to > apply an "atomically update file contents" approach (write data into a > file.new, then mv file.new file) to a /dev node, which would result in > this situation. This is sometimes hidden in some API like > g_file_set_contents(). > > Can you reproduce this with a direct > > echo mem | sudo tee /sys/power/state ...no. I couldn't reproduce it, tried about twenty times, but everything worked smooth as could be... > ? This will circumvent any suspend etc. hooks that you might have: > pm-utils, /usr/lib/systemd/system-sleep/ hooks, or something an > inhibitor might do. I. e. it could be that NetworkManager sets a > suspend inhibitor, tries to stop modemmanager before suspend and > restart it after, and that might mis-handle /dev/ttyUSB0. (We didn't > get any report about this so far, so I doubt it's actually > modemmanager -- it just illustrates how this could happen in > principle). ...so I looked into the scripts that execute when suspend is initiated. And I found leftovers of a device driver of some shady EPROM writer which I had installed about a year ago in /etc/pm/sleep.d/. It was a binary, but strings and grep showed that it really had /dev/ttyUSB0 hardcoded somewhere in there. Disabled the thing, problem is gone. Also explains the weird permissions (suspend script runs with root privileges obviously). And that they also use the "$" sign to encode some kind of command was apparently just coincidence. Oh man, I'm so sorry for bothering all you guys but at the same time so insanely happy this problem is finally solved. Even though the solution was quite unspectacular. Thank you so very much for your help. All the best, Johannes _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel