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
