Trying an interim TL;DR:
- Service A - --no-stop-on-upgrade
  A Requires A1.socket
  A Requires A2.socket
- Service B - --restart-after-upgrade
  B Requires=A1.socket
- A and B have also sysV scripts.
- d/rules calls dh_installinit and dh_systemd_start
- maintscripts get

This is confusing enough - re-summarize the approaches I had so far.

- when there is a sysV script it will call invoke.rc
- without sysV script it will call deb-systemd-invoke

Original Issue:
- invoke.rc on virtlogd
  - this will realize the new dependency to virtlogd-admin.socket
  - virtlogd-admin.socket can't be started because
    virtlogd-admin.socket: Socket service virtlogd.service already active, 
  - virtlogd.service is running fine, but the start returns RC!=0
  - that makes the upgrade fail

Fix I:
- drop both sysV scripts (virtlogd/libvirtd)
  - virtlogd will be started via deb-systemd-invoke
    This ignores errors in the postinst and is fine on upgrade
  - but libvirtd being taken over by deb-systemd-invoke is bad
    - the dh_systemd_start checks the service file and adds dependencies to the 
      deb-systemd-invoke restart 'libvirtd.service' 'virtlockd.socket' 
    - it knows that to restart a socket the service has to be stopped and 
    - so virtlogd is restarted ignoring the --no-restart-on-upgrade of the 
actual virtlogd 

Fix II:
- drop only virtlogd sysV script
  - virtlogd will be started via deb-systemd-invoke
    This ignores errors in the postinst and is fine on upgrade
  - libvirtd will continue to be started by invoke.rc which will restart "just" 
    (from dh_installinit)
  - but dh_systemd_start will have added a restart section
    deb-systemd-invoke $_dh_action 'virtlockd.socket' 'virtlogd.socket' 
>/dev/null || true
  - this will still restart the virtlogd service which has originally
    dh_installinit -p libvirt-daemon-system --name=virtlogd 
  - We have two dh-systemd_start calls in d/rules, assuming retain order
    dh_systemd_start -p libvirt-daemon-system --restart-after-upgrade 
    is the one which makes it generate the restart on the sockets.
    It seems to realize that libvirtd will be started by invoke.rc, so it 
leaves that out, but 
    will trigger the two dependencies.

Fix III:
- drop virtlogd sysV script and change the dh_systemds_start order
  - hope is that the dh_systemd_start of libvirtd considers the .socket
    files already handled and would no more add them with restart due to 
  - It changed the order in the generated maintainer script
  - But the section triggered by libvirtd.service still adds the sockets to the 
restart action
    deb-systemd-invoke $_dh_action 'virtlockd.socket' 'virtlogd.socket' 
>/dev/null || true
  - Please do mind, as in other cases here libvirtd itself is not here
    as it is taken over by the sysV start via invoke.rc

Fix IV:
- drop both sysV script, set compat 11, convert to dh_installsystemd
  - Intention: Use the new code only and check if it does any better?
  - This has so many other unrelated things due to the compat change that I 
won't go on this path 
    unless being the only left :-/

I'm short of d/rules:
  sed -i -e 'take stuff out' debian/libvirt-daemon-system.postinst
but that is so wrong ... :-/

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.

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  double virtlogd sockets with services running can trigger issues on

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to