Bug#781886: qcontrol failure to start on boot sometimes (jessie, systemd?)

[Michael Biebl]

Hi,

Am 14.04.2015 um 21:56 schrieb Michael Stapelberg:
> On Tue, Apr 14, 2015 at 8:59 PM, Ian Campbell <ijc at debian.org> wrote:
> 
>> On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
>>
>>>         > Apr 02 12:08:28 hostname systemd[1]: Started LSB: Start
>>>         qcontrol daemon.
>>>
>>>
>>> This line in the logfile indicates that systemd is using the sysvinit
>>> script (hence the “LSB: ” prefix) of qcontrold, not the native systemd
>>> service file.
>>
>> Ah, that seems obvious now you point it out.
>>
>>> The git log shows that 0.5.2 is the first version that is supposed to
>>> have systemd service files, but actually, when I look
>>> at https://packages.debian.org/jessie/armhf/qcontrol/filelist, I don’t
>>> see any files in /lib/systemd/system/, which suggests that the Debian
>>> package doesn’t install the systemd service files that upstream
>>> provides.
>>>
>>>
>>> Ian, it seems like you should be following
>>>
>> https://wiki.debian.org/systemd/Packaging#Using_debhelper_with_dh_systemd
>> to get the package to properly pick up the systemd service files, at which
>> point this bug should be fixed.
>>
>> I could have sworn this got done (I even thought the patches had come
>> from you!) but it really hasn't.
>>
>> Unfortunately I think switching over to the systemd initfiles for Jessie
>> is out of the question at this stage, given
>> https://lists.debian.org/debian-devel-announce/2015/03/msg00016.html.
>>
>> Once Jessie is out I'll get the proper fix into Stretch and
>> Jessie-backports as soon practical.
>>
>> In the meantime is there any simple workaround you can think of which
>> would make the existing sysvinit script work properly with systemd's LSB
>> compat mode?
>>
>> FYI qcontrold.init currently has:
>> # Required-Start:    $local_fs $remote_fs $syslog
>>
>> I'd have thought that $remote_fs would be sufficiently late to ensure
>> the /etc/modules.conf had been processed and udev to have been settled.
>> But perhaps some other dependency is required? Any idea what it might
>> be?
>>
> 
> pkg-systemd-maintainers, see above: is there a way to wait for udev devices
> to be available? What’s the current take on udev-settle, would that be a
> reasonable workaround for this situation?

Possible solutions, in order of preference:

The best way to fix this, is to make qcontrol hotplug aware, i.e. use
udev_monitor [1] to listen for new devices.
This way, it doesn't matter when the daemon starts, it will pick up new
devices when they come (and go).

An alternative, if the daemon is only supposed to be started when
certain hardware is available, is to trigger the start via a udev rule
and starting the .service via SYSTEMD_WANTS. See the bluez package for
inspiration.

"udevadm settle" is not really a solution, but rather a workaround. As a
consequence, it was removed from the boot sequence under systemd.
Most likely that's the reason that qcontrol now fails under systemd.
If qcontrol ships native service files, it can pull in the
systemd-udev-settle.service unit though via

Wants=systemd-udev-settle.service
After=systemd-udev-settle.service

If I read the bug report correctly, qcontrol doesn't ship a native
service file yet, though and only provides a SysV init script?

In that case, the (legacy) SysV init script could run "udevadm settle".
This is super ugly though and not something I would recommend. I only
mention it for completeness sake.




Michael



[1]
https://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html
[2]
http://www.freedesktop.org/software/systemd/man/systemd.device.html#SYSTEMD_WANTS=
-- 
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: 834 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150415/d86fc93f/attachment-0002.sig>