On Fri, Aug 10, 2018 at 11:30 AM Christian Ehrhardt < christian.ehrha...@canonical.com> wrote:
> > > On Fri, Aug 10, 2018 at 3:54 PM Felipe Sateler <fsate...@debian.org> > wrote: > >> >> >> On Fri, Aug 10, 2018 at 7:42 AM Michael Biebl <bi...@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
