Bug#791412: systemd invoking a service on its own

[Michael Biebl]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150705/91d053ef/attachment-0002.sig>