I am in the process of updating a .deb package from a legacy SysV-style init script to native systemd units. However, I'd like to leave the old init script in the package for now for users of other init systems. The service in question can be configured to run as multiple users on the system.

For the old init script, the administrator added the desired users to a specific group, and the init script took care of starting an instance of the service for each user. For systemd, I'd instead like to use a template to enabled separate instances for each user. E.g., systemctl enable my-service@user1; systemctl enable my-service@user2. This allows each user's instance to be started and stopped independantly, instead of all or nothing.

Normally, when a package has both a SysV-style init script and a systemd unit, they'll have the same name, so the native systemd unit will shadow the init script, ensuring systemd users use the systemd unit. In this case, however, since the new unit is a template, it does not shadow the init script. How can I prevent systemd users from enabling the init script, and instead guide them to the systemd service template?

1 Answer 1


In Debian, this is done by various services, e.g. saned:

  • The SysVinit-style script is /etc/init.d/saned, which would normally cause systemd-sysv-generator to auto-generate saned.service.
  • But the package disables this by providing a symbolic link /lib/systemd/system/saned.service -> /dev/null, which both blocks the autogeneration and causes systemd to regard saned.service as masked.
  • In addition, the package provides its own template /lib/systemd/system/[email protected]. Any instances of this template are fully separate from the masked saned.service and work as normal.

In other words, to get what you want, you'll just need to package a symbolic link /lib/systemd/system/my-service.service pointing to /dev/null.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .