- systemd is very well adopted across linux distros and is becoming the default for Debian and Ubuntu sometime in the next year.
- Upstart is the default for Ubuntu 14.04 LTS and that’s what we
currently deploy to.
- It is not super trivial to change 14.04 LTS to use to systemd
- It is pretty trivial to change 14.10 to use systemd, but I’m not sure we want to deploy to that.
- It’s the future
- It seems like most distributions are converging on systemd.
- Socket activation
- https://savanne.be/articles/deploying-node-js-with-systemd/
- This is really rad. systemd is event based, so rather than launching processes only at startup, it can listen for events and react to them, and one of those events is a socket connection. So when a new connection hits a certain port, systemd can spawn the appropriate process to handle it, which means the process doesn’t always have to be running & listening and consuming resources. This is useful for subsystems (like the deployer) that aren’t part of the main application and should be as nice as possible when consuming resources.
- Simple configuration format
- systemd can do complicated stuff, but it has a relatively simple configuration format.
- It’s the present
- 14.04 LTS is going to be around for a while, upstart is still the default in 14.10 and there isn’t a solid date on when they’re going to make the switch.
- Socket activation (kinda)
- Upstart also recently got socket activation, but it feels under-documented. It must be possible since uWSGI can use it.
I think the most compelling reason for using upstart is that “it’s the present” – we are deploying to 14.04 LTS and we’re probably gonna continue to for the foreseeable future. We also can’t easily switch to systemd to prepare. Socket activation is super rad, but A) upstart can do it too (kinda) and B) even if we can’t figure it out, we don’t need it.
I think systemd is really interesting and would be worth experimenting with down the line, it just probably shouldn’t be part of our production systems for now.