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.
# Change to /var/spool/postfix/var/run/opendkim to use a Unix socket with
# postfix in a chroot:
# Uncomment to specify an alternate socket
# Note that setting this will override any Socket value in opendkim.conf

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?

  • 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 Jul 4 '17 at 12:14

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

  • 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 Jul 4 '17 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.