Add interim summary

[Christian Ehrhardt]

On Fri, Aug 10, 2018 at 1:42 PM 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.
>

While the change of "responsibility" who is handling a service is puzzling
at first, it is still rather clear.
I don't think changing it here would fix our current issue.
I appreciate these changes for the sake of clarity thou.

Consider what I wrote happens when I remove all sysV scripts.
The dh_*system code will generate the code with "restart" but not only for
the listed service, but also required sockets it seems.
The problem is the bleeding of -restart-after-upgrade into other elements
that got set with --no-stop-on-upgrade.
In the current case that is libvirtd (-restart-after-upgrade) bleeding into
the sockets listed as required.

In the example I added A is not to be restarted, but that is exactly what
happens due to the "deb-invoke-systemd restart B.service A2.socket"

We'd either need logic to consider what those other elements were set to
(restart or not) and pull required services in under those conditions.
Or we consider it a rare case anyway and would add automation code, but
instead a switch which can disable pulling required services in.

Never the less all of the above might be only long term solutions.
Short term libvirt needs a way to restart "libvirtd" without restarting
"virtlogd".
I have added my "Fix V" which would achieve that, but I'd appreciate:
- to hear (from systemd experts) if there might be other solutions than the
ones already tried to achieve that?
- to hear from Guido about my Fix V being an interim solution for libvirt
for now?

In fact since the former "dh_systemd_start libvirtd" ignored the service
since there is a equally named sysV script - thereby we don't really loose
anything here.
The only real thing that might need consideration is the removal of
virtlogd sysV script.
It is required to fix the issue and not a problem for me on the Ubuntu side.
But I thought to remember Debian allows to switch init systems, so I'm not
sure if that is acceptable for you?


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
>
>
>

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180810/aaa4d2a9/attachment-0002.html>