In the midst of me configuring postfix and opendkim, I decided to upgrade Debian jessie (oldstable) to stretch. Since then, I can't get opendkim to start up properly.
What I expect is that the configuration in /etc/default/opendkim should be honoured, in particular that the RUNDIR and SOCKET settings should be place within the postfix chroot:
# Command-line options specified here will override the contents of
# /etc/opendkim.conf. See opendkim(8) for a complete list of options.
#DAEMON_OPTS=""
# Change to /var/spool/postfix/var/run/opendkim to use a Unix socket with
# postfix in a chroot:
RUNDIR=/var/spool/postfix/var/run/opendkim
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf
SOCKET=local:$RUNDIR/opendkim.sock
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=
However, regardless of whether I reboot, execute "service opendkim start" or "/etc/init.d/opendkim start", /var/run/opendkim is used as the RUNDIR instead, and so the pid file and socket are placed in the wrong locations:
/usr/sbin/opendkim -P /var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock
I've read that this is because the /etc/init.d/opendkim file (as with all other debian init files) includes the LSB init functions at /lib/lsb/init-functions, which runs the systemd script at /lib/lsb/init-functions.d/40-systemd, which in turn redirects execution to be "systemctl start opendkim"
This means that the unit file in /etc/systemd/system/multi-user.target.wants/opendkim.service is read, and the ExecStart line within it is executed
I've also read that I can skip the systemctl redirect by setting the env variable _SYSTEMCTL_SKIP_REDIRECT before the lsb init functions are included.
What is the correct way for me to configure opendkim now?
a. Should I still edit /etc/default/opendkim and add the _SYSTEMCTL_SKIP_REDIRECT to /etc/init.d/opendkim?
b. How is the systemctl unit file in /etc/systemd/system/multi-user.target.wants/opendkim.service generated, and is it supposed to be smart enough to include my configuration? i.e. am I don't something wrong?
c. Or should I edit the ExecStart line directly?
Best Answer
None of the above.
_SYSTEMCTL_SKIP_REDIRECT
. That's an internal mechanism that is none of your business./lib/systemd/system/opendkim.service
.The OpenDKIM people provide an
opendkim.service
file for systemd. It is geared towards RedHat and its/etc/sysconfig
system rather than towards Debian and its/etc/default
system, and so takes no notice of/etc/default/opendkim
at all.Rather than fix it, the Debian people provide another
opendkim.service
file for systemd that is used in place of the OpenDKIM-supplied one in Debian packages. That service unit does not read either/etc/sysconfig/opendkim
or/etc/default/opendkim
and hardwires the location of theAF_LOCAL
socket that OpenDKIM uses. That is what one gets as/lib/systemd/system/opendkim.service
.One might think that one edits
/lib/systemd/system/opendkim.service
, therefore. One does not. The systemd rule is that one does not edit package-supplied service unit files in/lib/systemd
. The systemd way of modifying this service is to add an override INI file in the/etc/systemd/system/opendkim.service.d/
directory. This contains a snippet of the part of the package-supplied service unit that one wants to override.One might think that one simply creates such a snippet, therefore. One does not. The Debian people have provided a "generator" program named
opendkim.service.generate
that automatically creates such a snippet from the contents of the/etc/default/opendkim
file, overridingUser
,Group
, andExecStart
as appropriate.The problem is that the Debian people have not wired this generator properly into systemd. It isn't really a systemd generator, which has a specific form and has a specific kind of output which this program does not have. Nor is it hooked into the Debian package installation and removal process. You need to run
/lib/opendkim/opendkim.service.generate
by hand, followed by an explicitsystemctl daemon-reload
.Further reading