Debian Jessie Uses Systemd

systemd, sysvinit, upstart

In the old days, all your daemon startup scripts were typically in /etc/init.d/.

With the release of Debian Jessie, however, daemon startup scripts are now located in /etc/init.d/, /etc/init/, and /lib/systemd/system.

Unlike upstart and sysvinit, systemd overides the parameters passed to a sysvinit script. For example, spindown no longer shows which disks are in standby state when I type sudo service spindown status or sudo /etc/init.d/spindown status.

Likewise, when I switched from Wheezy to Jessie varnish stopped working properly because it is now a systemd service meaning the sysvinit script pointing at /etc/default/varnish was now being ignored.

In this article I am going to fix these two issues.

Spindown Status

Spindown status is an easy fix. I simply edited /etc/init.d/spindown and changed "status") to "status2") in the switch case code block.

Now when I type sudo service spindown status2 or sudo /etc/init.d/spindown status2 I once again get the status of the watched disks, rather than the systemd status of the service.

Varnish

Varnish is a bit tougher to solve because it has switched to systemd as well.

The basics, however, are as follows.

sudo su
grep -v "^#" /etc/default/varnish > /etc/varnish/varnish.params
nano /etc/varnish/varnish.params

Delete the DAEMON_OPTS= multi-line parameter, save the file, and close it.

echo VARNISH_USER=varnish >> /etc/varnish/varnish.params
echo VARNISH_GROUP=varnish >> /etc/varnish/varnish.params
nano /lib/systemd/system/varnish.service

[Unit]
Description=Varnish HTTP accelerator

[Service]
LimitNOFILE=131072
LimitMEMLOCK=82000
#ExecStartPre=/usr/sbin/varnishd -C -f /etc/varnish/default.vcl
#ExecStart=/usr/sbin/varnishd -a :6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
#ExecReload=/usr/share/varnish/reload-vcl
EnvironmentFile=/etc/varnish/varnish.params
Type=forking
PIDFile=/var/run/varnish.pid
PrivateTmp=true
ExecStartPre=/usr/sbin/varnishd -C -f $VARNISH_VCL_CONF
ExecStart=/usr/sbin/varnishd \
        -P /var/run/varnish.pid \
        -f $VARNISH_VCL_CONF \
        -a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
        -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
        -t $VARNISH_TTL \
        -u $VARNISH_USER \
        -g $VARNISH_GROUP \
        -S $VARNISH_SECRET_FILE \
        -s $VARNISH_STORAGE \
        $DAEMON_OPTS

ExecReload=/usr/share/varnish/reload-vcl


[Install]
WantedBy=multi-user.target

systemctl daemon-reload
service varnish restart
exit

Varnish should now be working again.

Dovecot

After a bit of maintenance earlier (2015-10-21) I could not access my mail. It turned out that Dovecot was refusing to start.

master: Error: systemd listens on port 993, but it's not configured in Dovecot. Closing.

The problem turned out to be due to socket connections and/or a slight misconfiguration.

To disable dovecot using socket connections:

sudo systemctl disable dovecot.socket

To fix the configuration file, open /etc/dovecot/conf.d/10-master.conf and make sure each active inet_listener has an address associated with it.

  inet_listener imaps {
    port = 993
    ssl = yes
  }

  inet_listener imaps {
        address = *
    port = 993
    ssl = yes
  }

Previously I was relying on no address being equal to all IP addresses because my home server has a dynamic IP address. This modification does the same thing (albeit having to be specified rather than assumed).

A restart of dovecot and imapproxyd later and I am able to access my mail again. Because postfix uses dovecot for authentication, I am not yet sure if disabling sockets will have any unintended side-effects.