Systemd – Migrate Basic Upstart Script to Systemd

systemdupstart

I just upgraded a server from Ubuntu 14.10 to 15.04, and a couple of services that I start via custom upstart scripts are no longer running.

My understanding is that I need to re-write them as systemd services, but the thought of learning the entire systemd system overnight is a little daunting.

The upstart script simply launches autossh at startup, and I have a couple of other similar scripts that launch long-running processes.

#/etc/init/autossh.conf

description "Maintain a permanent SSH tunnel to <other_server>"

start on started mountall
stop on shutdown

exec autossh -N other_server

How can I re-write this as a systemd service?

Best Answer

the first rule for migrating to systemd

At this point, in 2015, it's most likely that someone has already done it.

systemd has been around for some years. And there has been a whole cottage industry of people writing unit files and publishing them. GitHub, in particular, seems to attract repositories of collections of service units.

Indeed simply searching the WWW for autossh.service (as a phrase) turns up:

a template unit

That said, as I've pointed out in several places on StackExchange alone, this sort of migration is not a mechanistic process, and sometimes just robotically translating from whatever one has to a unit file is doing things wrongly, or at least poorly. In this case, autossh is positively panting to be handled with a template unit, that it is instantiated into actual service units, parameterized by the target name. So as /etc/systemd/system/autossh@.service, have:

[Unit]
Description=AutoSSH service for a reverse tunnel from %i 
After=network.target

[Service]
User=autossh
EnvironmentFile=/etc/%p/%i.conf
ExecStart=/usr/bin/autossh -M 0 -q -N $SSH_USER@%i $SSH_OPTIONS

[Install]
WantedBy=multi-user.target

Create a file named /etc/autossh/other_server.example.conf with, minimally:

SSH_USER=joe

All of the usual controls then apply:

systemctl enable autossh@other_server.example — Enable an instance to be automatically started at bootstrap.
systemctl start autossh@other_server.example — Manually start that instance immediately.
systemctl status autossh@other_server.example — See its status.

And yes, the first rule even applies to this. Searching, one can find that I was beaten to this, by just under a fortnight, by Greg Freemyer at OpenSUSE.

Related Solutions

Ubuntu – Upstart or Systemd

They will support Upstart for as long as 14.04 is supported (until 2019), but systemd is the future, from 15.04 onwards. As of today: Upstart is used on the following supported releases:

10.04
12.04
14.04
14.10

15.04 is slated to use systemd (and the development builds have made the switch already). Ubuntu Touch, however, will continue to use Upstart in 15.04.

Ubuntu – SysV, Upstart and systemd init script coexistence

Only one init system can be active at once. On 16.04, that's systemd.

A number of packages ship with files for multiple init systems, so they can be managed with multiple init systems on different OSes. On Ubuntu, sometimes scripts for multiple init systems get installed, even though they are not all used at the same time.

Newer init systems try to maintain compatibility with older ones. In particular, systemd tries to maintain compatibility with both Upstart and SysV init scripts.

In the case of the "init.d" script you mentioned, that is a "SysV" init script, not an Upstart script. Also, "SysV" init scripts would only be started on boot if they were symlinked to a directory like "/etc/rc5.d". You'll find that Network Manager does not have a symlink installed there.

To understand how systemd manages old "SysV" init scripts, see How does systemd use /etc/init.d scirpts?.

Now, to answer the question about why it works to restart Network Manager with "service network-manager restart". The service command is used with both Upstart scripts and SysV init scripts, preferring the former. Network Manager also has an Upstart script installed on 16.04 at /etc/init/network-manager.conf.

If you review the output of sudo strace service network-manager restart, you can get a sense of what's happening. First, the output shows that systemctl is being called, indicating that the command is being redirected to systemd. First, shortly after it opens /usr/bin/service, you can see it start to read in the file as a shell script:

open("/usr/sbin/service", O_RDONLY)     = 3
...
read(10, "#!/bin/sh\n\n#####################"..., 8192) = 8192

Now that we know that service is a shell script, we can go check out the source code of it. In the source code, we find that is_systemd is detected and set. For the systemd case, you can see that the command gets rewritten to be systemctl restart network-manager.

So while the three init systems co-exist and have some compatibility, there are layers of complexity. To minimize the complexity of what's happening going forward, it's best to use systemd unit files and the systemctl tool to manage services.