Say I have two packages, A and B, that offer a service each, a and b.

b depends on a. In other words, if service a is currently active (running), then I can start and stop b no problem. However, if a is not active, b should not start, at least not without first trying to start a. Similarly, if I want to stop a, then I expect b to be taken down first, then a. This all works great with systemd.

I applied a fix to package A.

What is the proper behavior of the package when I run dpkg --install A?

It seems pretty evident that A may know nothing of B. So, if the prerm script of A runs:

systemctl stop a

It will take b down along with it.

Then the new version of A gets installed and in the postinst I restart a with:

systemctl start a

Is that the expected procedure to upgrade a package such as A? Will systemd somehow always remember to restart b automatically? What if I had many more dependencies?

migrated from stackoverflow.com Sep 11 '16 at 15:53

This question came from our site for professional and enthusiast programmers.


In systemd, the systemctl restart operation has a special behavior as compared to a pair of stop+start:

  • systemctl restart a — stop b, stop a, start a, start b (i. e. restarts dependent units, all in correct order)
  • systemctl stop a && systemctl start a — stop b, stop a, start a (i. e. does not remember about the dependent units)

Note that this only happens when b.service has Requires=a.service. Wants=, After= and Before= do not enable this special behavior (but After=a.service is most likely needed as well to order stops and starts against each other).

So, to make this work, you probably need to run nothing from A's prerm script and systemctl restart from A's postrm script if their first argument is upgrade, and normal systemctl stop + systemctl start otherwise. (Note: I may be wrong here ­— not a Debian user/maintainer),

  • Hmmm... I have full systemd packages now and the stack works on a reboot. However, if I upgrade A and B depends on A, the upgrade will do systemctl stop A in preinst (I think that's preinst) and when the upgrade is done, it calls systemctl start A. Which means B does not get restarted. I suppose that means upgrades are just not working at all if you have dependencies? – Alexis Wilke Sep 14 '16 at 22:46
  • Two additional notes that may interest others too: (1) If you do not stop A before upgrading A, the unpack process will fail because somehow systemd protects the daemon which is not over-writable while running; (2) I use the dh $@ --with systemd to build my packages so I am not in control of what function gets called to handle the start / stop of the daemons. – Alexis Wilke Sep 15 '16 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.