Hello Tomas, On Wed, 2016-04-06 at 15:38 +0200, Tomas Janousek wrote: > Hi Ritesh, > > On Wed, Apr 06, 2016 at 04:30:15PM +0530, Ritesh Raj Sarraf wrote: > > > > The good part of systemd integration is that it can keep trace of all > > invocations of systemd, be it udev or systemd. > In theory it can, but as it is currently implemented, it does not. lmt-udev > does indeed call /usr/sbin/laptop_mode directly for runtime-pm events. >
Yes. And from the information I've gathered so far, udev does not guarantee complete execution. But I've never run into any problem so far, especially after trimming down the invocation to just 1 LMT module. The worst I hit recently was: https://github.com/rickysarraf/laptop-mode-tools/issues/59 Which, after setting the correct Unit attribute, is not seen anymore. Note: From the logs in the above mentioned github bug, systemd reported of the failure. So, that (failed) invocation was supervised by systemd, is what I understand. > > > > > > > > I suspect that "lmt-udev force modules=runtime-pm ..." is being run by > > > udev > > > before the systemd service is started, and then strange things happen. All > > > modules except runtime-pm are skipped but lmt probably makes a note > > > somewhere > > > that it applied everything and doesn't need to do that again, so when the > > > service later starts nothing is done. Or maybe not, maybe it's just that > > > this > > > "lmt-udev force ..." is being run via the "non_systemd_way" in the > > > background > > > regardless of whether systemd runs or not and is probably getting killed > > > early. > > There was one corner case where, upon swsusp resume, tasks would get killed. > > That got fixed in 1.69.2. > Can you please explain why this is not still the case for the runtime-pm lmt > invocation? It's clearly being invoked outside of systemd, via non_systemd_way > "$@" & due to the if checking for systemd AND the first argument being equal > to "auto". But udev invokes lmt-udev with first argument being "force" so it > goes to the non-systemd branch. I can't see why this wouldn't get killed. > Yes. Here you are correct. Only 1 use case, i.e. device of type of USB will be covered through this condition. I've not been able to see a process kill under this condition. What error logs have you got ? I'd like to check for the same in my journal logs to see if I missed something. > > > > I'm not sure why that'd get invoked for you, in the beginning of the boot. > > Do > > you have external USB devices ? > External, no. But I have internal USB devices. A camera, a bluetooth adapter, > possibly a fingerprint reader had I not disabled it in BIOS. It's worth > mentioning that the order systemd/udev run things is not exactly predictable. > It's not like you can plug a USB mouse, reboot and reproduce my issue. > Sometimes even here laptop-mode.service starts before udev manages to mess > things up with runtime-pm. What you can do, though, is manually make sure that > "lmt-udev force modules=runtime-pm" is run before systemd starts the > laptop-mode.service unit, e.g. by adding an ExecStartPre into > laptop-mode.service that invokes "lmt-udev force modules=runtime-pm" and waits > a few seconds. I didn't try that though and to be honest I'd prefer not to > reboot today. You have pretty much a standard configuration. It is inline with what I (and many other may) have. So I'm still wondering how I've missed this. But thanks for the tip. I'll try to reproduce this locally based on your suggestion. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
