I’ve gone on some mini-rants in other posts about starting daemons immediately after they’re installed in Ubuntu and Debian. Things are a little different in Ubuntu 16.04 and I thought it might be helpful to share some tips for that release.
Before we do that, let’s go over something. I still don’t understand why this is a common practice within Ubuntu and Debian.
Take a look at the postinst-systemd-start script within the init-systems-helpers package (source link):
|
1 2 3 4 |
if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true deb-systemd-invoke start #UNITFILES# >/dev/null || true fi |
The daemon-reload is totally reasonable. We must tell systemd that we just deployed a new unit file or it won’t know we did it. However, the next line makes no sense. Why would you immediately force the daemon to start (or restart)? The deb-systemd-invoke script does check to see if the unit is disabled before taking action on it, which is definitely a good thing. However, this automatic management of running daemons shouldn’t be handled by a package manager.
If you don’t want your package manager handling your daemons, you have a few options:
The policy-rc.d method
This method involves creating a script called /usr/sbin/policy-rc.d with a special exit code:
|
1 2 3 4 5 |
# echo -e '#!/bin/bash\nexit 101' > /usr/sbin/policy-rc.d # chmod +x /usr/sbin/policy-rc.d # /usr/sbin/policy-rc.d # echo $? 101 |
This script is checked by the deb-systemd-invoke script in the init-systems-helpers package (source link). As long as this script is in place, dpkg triggers won’t cause daemons to start, stop, or restart.
You can start your daemon at any time with systemctl start service_name whenever you’re ready.
The systemd mask method
If you need to prevent a single package from starting after installation, you can use systemd’s mask feature for that. When you run systemctl mask nginx, it will symlink /etc/systemd/system/nginx.service to /dev/null. When systemd sees that, it won’t start the daemon.
However, since the package isn’t installed yet, we can just mask it with a symlink:
|
1 |
# ln -s /dev/null /etc/systemd/system/nginx.service |
You can install nginx now, configure it to meet your requirements, and start the service. Just run:
|
1 2 |
# systemctl enable nginx # systemctl start nginx |
If you *do* for some reason want deb-systemd-invoke to start or restart a specific service, test $1 against the systemd unit name. “exit 104” for services you do want deb-systemd-invoke to manage.
#!/bin/bash
[[ “$1” = “salt-minion.service ]] && exit 104
exit 101
I never really understood why this is a problem for people… If you install nginx it doesn’t seem like an unreasonable assumption that you want it to run. Does it?
I’d definitely like it to run — but only after I’ve configured it, put my web content in place, etc. Otherwise I’ll need to do all of that configuration and restart it. The initial startup provides no value for me.
We’re talking about the difference between:
Starts after installation with a usable, default config -> I make some changes -> I restart it
and:
Doesn’t start after installation -> I make changes to the config -> I start it
I must be missing something, because I can’t see how you’d get worked up over that enough to dedicate multiple blog posts to it.
Because, for example, sometimes the “make changes/config” part is important enough it should happen before the daemon ever starts.
Generally if you are setting up 1 instance it might not be a big deal to install, start, configure, restart. If you are trying to support multiple instances behind a load balancer for example of a particular service you need to ensure that the system is completely good to go before you start it up.
Honestly, I never understood how Debian (and Ubuntu) could get the initscript and startup config process so wrong like this for so long. It’s been standard for pretty much forever on the Red Hat / RPM side to NOT start up a service on install for explicitly this reason (the details still survive in EPEL: https://fedoraproject.org/wiki/EPEL:SysVInitScript#Why_don.27t_we…. ).
This was one of the many, many beefs sysadmins had with systemd; service management and the init process should be distinct to allow for more control at install time.
Switching back and forth between RedHat family and Debian family this has been one of my major annoyances.
I tried giving the first alternative a shot, but because both
stopandstartmight be issued by a dpkg trigger when also uninstalling packages (e.g. mysql-server) it quickly became more of a nuisance than of any help. Had a quick look at the source code and didn’t seem to be possibly to only prevent autostart when installing packages, but would you happen to know of any other solution?Systemd mask however works fine, but it’s a bit of a hassle to incorporate into all my Ansible roles (not to mention third party ones!).
Thank you for this post. This have been driving me nuts with configuration management tools. Sometimes the tool will hang, because it can’t stop the package started service after I have rewritten the configuration file and tried to restart the service.
I found this way:
Just add runlevel, i.e.
sudo RUNLEVEL=1 apt-get install iptables-persistent
Thank you! This was very helpful.
Was much helpful. Thanks for sharing!
IMHO apt-get should take an arg to perform this action.