Add interim summary

Felipe Sateler fsateler at debian.org
Fri Aug 10 17:50:51 BST 2018


On Fri, Aug 10, 2018 at 11:30 AM Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

>
>
> On Fri, Aug 10, 2018 at 3:54 PM Felipe Sateler <fsateler at debian.org>
> wrote:
>
>>
>>
>> On Fri, Aug 10, 2018 at 7:42 AM Michael Biebl <biebl at debian.org> wrote:
>>
>>> Am 10.08.2018 um 13:32 schrieb Christian Ehrhardt:
>>> > I think I'd want/need a "dh_systemd_start
>>> --no-dependent-services/sockets"
>>> > option to intentionally have it generate "just" for libvirt.service
>>> and not
>>> > the sockets it depends on.
>>> > As mentioned, for all of the complexity pulling in the systemd people
>>> might
>>> > help as well.
>>> > So I'm eager to see what they will reply here as well.
>>>
>>>
>>> I guess the complication arises from the fact that
>>> dh_installinit/invoke-rc.d directly handles systemd service files if the
>>> SysV init script and service file name match.
>>> dh_installsystemd only handles those unit files for which no
>>> corresponding SysV init script exists.
>>>
>>> I think the solutions for this could be, to let dh_installsystemd handle
>>> all systemd unit files.
>>> dh_installinit/invoke-rc.d on the other hand would be updated to only
>>> handle SysV init scripts.
>>>
>>> In the long run I guess this will be less confusing at is clearer which
>>> tool is responsible for which task and it makes it easier to override
>>> the behaviour in debian/rules.
>>>
>>> Felipe has been doing some initial work for enable that kind of
>>> behaviour at
>>> https://salsa.debian.org/debian/init-system-helpers/merge_requests/4
>>
>>
>> This should help, but then you get the next problem: dh_installsystemd
>> parses the Also= lines, and generates deb-systemd-invoke for all referenced
>> units.
>>
>> I think the Also= lines in libvirtd.service are superfluous and removing
>> them should avoid this problem.
>>
>> I'm still not sure why we parse Also= for starting. Michael, do you
>> remember the rationale?
>>
>
> Uh I see, you mean dropping this section from libvirtd.service right?
>
> [Install]
> WantedBy=multi-user.target
> Also=virtlockd.socket
> Also=virtlogd.socket
>
> The above is certainly worth a try - I need to check what I "loose" by
> that.
>

I'd say nothing. libvirtd.service already Requires the sockets, so they
will be pulled in anyway.

Note that the Also= lines are actively harmful. If you want to disable
automatic start at boot, and instead rely on socket activation, doing
`systemctl disable libvirtd.service` will also disable the sockets.


> I'd still need to drop virtlogd sysV script as the "invoke.rc virtlogd"
> will complain about missing dependencies (the new .socket for it can't be
> started since the service is already running).
> The dh_systemd_start generated code triggers "start" and ignores the
> retval, the dh_installinit code through invoke.rc calls start but fails
> since systemd replied "I'm running but there are dependency issues".
> Because virtlogd.service has Requires virtlogd.socket and
> virtlogd-admin.socket.
>

Yes, this is the part that could be addressed with the merge request
Michael referenced.

-- 

Saludos,
Felipe Sateler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180810/83a8b9a5/attachment-0002.html>


More information about the Pkg-systemd-maintainers mailing list