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:

• Phillipp Klaus doing this in 2013
• Thomaz Fritz doing this in 2014
• unknown people doing this in 2013

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.

1- Why:

Upstart's model for starting processes is greedy event-based, all available jobs whose startup events happen are started as early as possible. During boot, upstart synthesizes some initial events like startup or rcS as the tree root, the early services start on those, and later services start when the former are running.

Systemd's model for starting processes is lazy dependency-based, a unit will only start if and when some other starting unit depends on it. During boot, systemd starts a root unit, which then transitively expands and starts its dependencies.

2- systemd-debug-generator

Is a generator that reads the kernel command line and understands three options:

systemd.mask= option

Followed by a unit name,this unit is masked for the runtime. This is useful to boot with certain units removed from the initial boot transaction for debugging system startup.

systemd.wants= option

Followed by a unit name, this unit is added to the initial transaction. This is useful to start one or more additional units at boot.

systemd.debug-shell option

The debug shell service "debug-shell.service" is pulled into the boot transaction. It will spawn a debug shell on tty9 during early system startup.

3- To do so:

Select the Advanced options for Ubuntu at the boot prompt when your computer starts.

Then, select the Ubuntu, with Linux ... (upstart) entry.

However, this will work only for the current session

So if you want to make it permanent, you'll have to install the upstart-sysv package.

Source