DH_SYSTEMD_START(1)

πŸ’… DH_SYSTEMD_START(1) β€” the debhelper one, bestie

okay so you found the dh_systemd_start page, welcome, sit down, hydrate 🫢 this is a debhelper program and she is literally the one in charge of starting, stopping and restarting your systemd unit files. slay.


✨ NAME ✨

dh_systemd_start β€” start / stop / restart systemd unit files. that's it, that's the whole job. πŸ‘‘


✨ SYNOPSIS ✨

dh_systemd_start [debhelper options] [--restart-after-upgrade]
[--no-stop-on-upgrade] [unit file ...]

yes the synopsis is two lines because she's dramatic like that. πŸ’…


✨ DESCRIPTION ✨

okay so listen. dh_systemd_start is a debhelper program, and what she does is she's responsible for starting / stopping or restarting systemd unit files β€” but specifically in the case where there is no corresponding sysv init script available. no init script? she's on it. periodt.

and the way she moves is exactly like dh_installinit, bestie: the unit file gets stopped before upgrades and started afterwards β€” unless you pass --restart-after-upgrade, in which case she'll only restart it after the upgrade, no stop beforehand, no pre-upgrade downtime, the moment is hers ✨.

BUT. and this is the important part. 🌸 that whole logic is not used when there is a corresponding SysV init script. why? because in that case invoke-rc.d is the one doing the stop/start/restart. she's not gonna fight invoke-rc.d for the aux, that's not the vibe. iykyk.


✨ OPTIONS ✨

  • --restart-after-upgrade β€” do not stop the unit file until after the package upgrade has been completed. this is the default behaviour in compat 10, so if you're on compat 10 you're already living this life πŸ’–

in earlier compat levels, the default was the other thing: stop the unit file in the prerm, and start it again in the postinst. old school.

this can be useful for daemons that should not have a possibly long downtime during upgrade β€” like, nobody wants that gap, bestie. BUT: you should make sure that the daemon will not get confused by the package being upgraded while it's running before using this option. πŸ‘€ fr fr, check that first.

  • --no-restart-after-upgrade β€” undo a previous --restart-after-upgrade (or undo the default of compat 10). if no other options are given, this will cause the service to be stopped in the prerm script and started again in the postinst script. so basically: the classic stop-then-start choreography, back on the menu πŸŽ€
  • -r, --no-stop-on-upgrade, --no-restart-on-upgrade β€” do not stop service on upgrade. that's it. three names, one mood. 🌈
  • --no-start β€” do not start the unit file after upgrades and after initial installation. (the initial-installation part is only relevant for services without a corresponding init script β€” that's the fine print, don't skip it πŸ¦‹)

πŸ“Œ NOTES πŸ“Œ

okay bestie, two things, and they matter:

this command is not idempotent. dh_prep(1) should be called between invocations of this command (with the same arguments). otherwise, it may cause multiple instances of the same text to be added to maintainer scripts. 😭 that's the messy timeline. avoid it.

also β€” and this is the sequencing tea β€” dh_systemd_start should be run after dh_installinit so that it can detect corresponding SysV init scripts. the default sequence in dh does the right thing automatically, so this note is only relevant when you are calling dh_systemd_start manually. manual mode = you, by yourself, in the terminal, at 2am. respect. πŸ™ˆ


πŸ‘€ SEE ALSO πŸ‘€


πŸ‘‘ AUTHORS πŸ‘‘

pkg-systemd-maintainers@lists.alioth.debian.org


that's the whole page, you ate it, i'm obsessed πŸ“

cute little sign-off: this was version 14.5ubuntu1, dated 2026-09-21 πŸ’– go upgrade something and remember β€” dh_prep(1), always. mwah 🧚

πŸ“¦ where this page comes from