<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 10, 2018 at 1:42 PM Michael Biebl <<a href="mailto:biebl@debian.org">biebl@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 10.08.2018 um 13:32 schrieb Christian Ehrhardt:<br>
> I think I'd want/need a "dh_systemd_start --no-dependent-services/sockets"<br>
> option to intentionally have it generate "just" for libvirt.service and not<br>
> the sockets it depends on.<br>
> As mentioned, for all of the complexity pulling in the systemd people might<br>
> help as well.<br>
> So I'm eager to see what they will reply here as well.<br>
<br>
<br>
I guess the complication arises from the fact that<br>
dh_installinit/invoke-rc.d directly handles systemd service files if the<br>
SysV init script and service file name match.<br>
dh_installsystemd only handles those unit files for which no<br>
corresponding SysV init script exists. </blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the solutions for this could be, to let dh_installsystemd handle<br>
all systemd unit files.<br>
dh_installinit/invoke-rc.d on the other hand would be updated to only<br>
handle SysV init scripts.<br>
<br>
In the long run I guess this will be less confusing at is clearer which<br>
tool is responsible for which task and it makes it easier to override<br>
the behaviour in debian/rules.<br></blockquote><div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">While the change of "responsibility" who is handling a service is puzzling at first, it is still rather clear.</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">I don't think changing it here would fix our current issue.</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">I appreciate these changes for the sake of clarity thou.</div><div><br></div><div>Consider what I wrote happens when I remove all sysV scripts.</div><div>The dh_*system code will generate the code with "restart" but not only for the listed service, but also required sockets it seems. </div>The problem is the bleeding of -restart-after-upgrade into other elements that got set with --no-stop-on-upgrade.</div><div>In the current case that is libvirtd (<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">-restart-after-upgrade) bleeding into the sockets listed as required.</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div>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"</div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div>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.</div><div>Or we consider it a rare case anyway and would add automation code, but instead a switch which can disable pulling required services in.</div><div><br></div><div>Never the less all of the above might be only long term solutions.</div><div>Short term libvirt needs a way to restart "libvirtd" without restarting "virtlogd".</div><div>I have added my "Fix V" which would achieve that, but I'd appreciate:</div><div>- to hear (from systemd experts) if there might be other solutions than the ones already tried to achieve that?</div><div>- to hear from Guido about my Fix V being an interim solution for libvirt for now?</div><div><br></div><div>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.</div><div>The only real thing that might need consideration is the removal of virtlogd sysV script.</div><div>It is required to fix the issue and not a problem for me on the Ubuntu side.</div><div>But I thought to remember Debian allows to switch init systems, so I'm not sure if that is acceptable for you?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Felipe has been doing some initial work for enable that kind of<br>
behaviour at<br>
<a href="https://salsa.debian.org/debian/init-system-helpers/merge_requests/4" rel="noreferrer" target="_blank">https://salsa.debian.org/debian/init-system-helpers/merge_requests/4</a><br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8px">Christian Ehrhardt</span><div style="color:rgb(136,136,136);font-size:12.8px">Software Engineer, Ubuntu Server</div><div style="color:rgb(136,136,136);font-size:12.8px">Canonical Ltd</div></div></div></div></div></div>