Am 05.07.2015 um 15:30 schrieb Ritesh Raj Sarraf: > On Sunday 05 July 2015 12:27 AM, Michael Biebl wrote: >>> Other point I can see is that the invoking process is systemd. >> >> Well, sure, if a service start is triggered, the invoking process will >> be systemd. That is not a bug though. >> >> It's still unclear to me what the bug in systemd is supposed to be. >> > > LMT can be invoked multiple ways. Through systemd, through acip and > through udev, which is the most common invoking parent.
Even if the trigger is e.g. acpid or udev, the activation should go through systemd, e.g. by using systemctl or SYSTEMD_WANTS. >> >>> systemd is new, and I am hoping you guys are the right contact to help >>> me conclude. >>> >>> >>> From within LMT, we background another script, lm-polling-daemon. This >>> script is backgrounded after we acquire a lock in the main program i.e. >>> /usr/sbin/laptop_mode, and not released until the polling daemon is killed. >>> >>> >>> How is systemd/cgroup supposed to handle scripts that background other >>> scripts ? >> >> Why do you need all those background/looping/locking etc? >> > > lm-polling-daemon was created because different users have different > battery types, and many a times, those batteries don't report their > status. So we added a module, lm-polling-daemon/battery-level-polling, > giving users the flexibility to poll the battery, and if the state > changes, then act on it. > >> If it is to assure, that only a single process is started, even when you >> have multiple start requests at the same time, you get that for free >> already under systemd. >> > > Yes. But LMT is older than systemd, and that locking was added mostly > for udev invocation, where there may be many events. > > And we also have users on machines where systemd is not the active init > >> It seems to me, that you are trying to work against systemd and not use >> the features it provides. >> >> > > No. I'm just not making it depend on systemd. It should work on systems > without systemd too. That's a difference. You can still make use of systemd when available. > By the way, I think in version 221, something more may have broken for > systemd in general. The udev rules don't seem to be processed, nor the > commands invoked. Reverting to 220, and the processing/invocation works > back. > > Both LMT and systemd upgraded around the same time, and I took it as a > bug in LMT. :-) It is a bug in lmt. You can't spawn long running, daemonized processes from udev rules under systemd. They are killed by udevd. man 7 udev is quite clear about that: Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. If that worked in the past, then only by accident. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature