4

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?

Improve this question
1
  • It's probably safer to backup the configuration files, then apt-get purge opendkim, apt-get install openkdim and then manually edit the new installed configuration files, if needed.
    – Ortomala Lokni
    Commented Jul 4, 2017 at 12:14

1 Answer 1

Reset to default
5

None of the above.

  • Do not muck about with _SYSTEMCTL_SKIP_REDIRECT. That's an internal mechanism that is none of your business.
  • The unit file is not in that location. That is a symbolic link. The systemd unit file is /lib/systemd/system/opendkim.service.
  • Do not edit the systemd unit file. It is supplied by the OpenDKIM package for Debian and is not supposed to be modified.
  • It is a good rule of thumb in general that an answer misplaced as a comment on the question will be poor advice; and it is here.

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 the AF_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, overriding User, Group, and ExecStart 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 explicit systemctl daemon-reload.

Further reading

Improve this answer
1
  • Many thanks. I suppose this might also apply for the opendmarc service - will go check that out. Did not expect that the problem was that the package has something funky going on. In the general case, though, should I still be able to edit /etc/default/[service], and the packaged service unit file or generator is expected to pick up the config parameters? And if it does not, I would then write a snippet?
    – Bingu Bingme
    Commented Jul 4, 2017 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .