0

I got a strange problem concerning dovecot. My dovecot was working flawlessly on my cubietruck until yesterday, when I upgraded from debian/jessie to debian/stretch (armhf).
/var is symlinked to another mounted drive (mountpoint /extended): /var -> /extended/hostname/var

Now whenever I start it as service ("systemctl start dovecot"), it does not start but exits immediately with error.

May 08 21:16:20 hostname systemd[1]: Starting Dovecot IMAP/POP3 email server...
May 08 21:16:20 hostname dovecot[32167]: Error: bind(/var/spool/postfix/private/auth_dovecot) failed: No such file or directory
May 08 21:16:20 hostname dovecot[32167]: Fatal: Failed to start listeners
May 08 21:16:20 hostname systemd[1]: dovecot.service: Control process exited, code=exited status=89
May 08 21:16:20 hostname systemd[1]: Failed to start Dovecot IMAP/POP3 email server.
May 08 21:16:20 hostname systemd[1]: dovecot.service: Unit entered failed state.
May 08 21:16:20 hostname systemd[1]: dovecot.service: Failed with result 'exit-code'.

Whenever I start dovecot as root in shell by dovecot it does not show any error but works flawlessly.

my dovecot.conf:

auth_mechanisms = plain login
log_timestamp = "%Y-%m-%d %H:%M:%S "
passdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
protocols = imap pop3
service auth {
  unix_listener /var/spool/postfix/private/auth_dovecot {
    mode = 0660
    user = postfix
    group = postfix
  }
  unix_listener auth-master {
    mode = 0600
    user = vmail
  }
  user = root
}
ssl_cert =</etc/postfix/sslcert/server.crt
ssl_key =</etc/postfix/sslcert/server.key
userdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
protocol pop3 {
  pop3_uidl_format = %08Xu%08Xv
}

# Enable installed protocols
!include_try /usr/share/dovecot/protocols.d/*.protocol

# Most of the actual configuration gets included below. The filenames are
# first sorted by their ASCII value and parsed in that order. The 00-prefixes
# in filenames are intended to make it easier to understand the ordering.
!include conf.d/*.conf

# A config file can also tried to be included without giving an error if
# ried not found:
!include_try local.conf
  • I already deleted the socket /var/spool/postfix/private/auth_dovecot before start, but no avail when started as service. When started in shell the socket (auth_dovecot) is recreated on start.
  • Commenting out the unix_listener-part leads to possibly timeout on start. The error reads PID file /var/run/dovecot/master.pid not readable (yet?) after start.
  • Using another name for the socket (/var/spool/postfix/private/auth) leads to same error.
  • I already tried to reinstall dovecot completely (apt purge, autoremove, autoclean, clean, install, ...), but that leads to timeout problems and strange config files.
  • searching on google/stackexchange doesn't bring up a solution.

Because I can run dovecot without problems as root from shell, I strongly suspect systemd generating some sort of chroot but I need some hints to further investigate it.

Thank you in advance.

PS: Fortunately I should be able to go back to debian/jessie since I have an tar.gz-archive of the cubietruck SD-card.

SirFartALot
  • 101
  • 3
  • 1
    Would the upgrade have activated SELinux? – Gerard H. Pille May 09 '20 at 04:44
  • Doesn't seem so. Only "libselinux" is installed, no other selinux related packages. "getenforce" or "sestatus" are not available on the machine. I don't know selinux, so where else to look at, whether it's activated or disturbing my dovecot? – SirFartALot May 09 '20 at 06:10
  • Changing the default locations/paths of a product is something that SELinux would prevent. And I had the impression your problem had to do with permissions eg. (starting as root works). Be sure to check if dovecot has the necessary permissions on /var/spool/postfix. – Gerard H. Pille May 09 '20 at 07:42
  • What filesystem is /extended? – Gerard H. Pille May 09 '20 at 07:47
  • /extended is ext4. I found a solution after doing a relatively clean upgrade from my jessie backup to stretch. – SirFartALot May 10 '20 at 11:58
  • 1
    Always keep it as clean as possible, your Smelliness. – Gerard H. Pille May 10 '20 at 12:03

1 Answers1

0

There seems to be some strange behaviour regarding systemd.

I solved it by editing the postfix.service file (/etc/systemd/system/multi-user.target.wants/dovecot.service) and set the default entry PrivateTmp=true to PrivateTmp=false.

# This file is part of Dovecot
#
# If you want to pass additionally command line options to the dovecot
# binary, create the file:
#   `/etc/systemd/system/dovecot.service.d/service.conf'.
# In this file create a Service section and configure an Environment with
# the variable `OPTIONS'. For example:
#
#   [Service]
#   Environment='OPTIONS=-p'
#
# In the `Service' section you may also specify various other setting.
# If you have trouble with `Too many open files' you may set:
#LimitNOFILE=8192
#
# If you want to allow the Dovecot services to produce core dumps, use:
#LimitCORE=infinity

[Unit]
Description=Dovecot IMAP/POP3 email server
Documentation=man:dovecot(1)
Documentation=http://wiki2.dovecot.org/
After=local-fs.target network.target

[Service]
Type=forking
ExecStart=/usr/sbin/dovecot
PIDFile=/var/run/dovecot/master.pid
ExecReload=/usr/bin/doveadm reload
ExecStop=/usr/bin/doveadm stop
PrivateTmp=false
NonBlocking=yes
# Enable this if your systemd is new enough to support it:
#ProtectSystem=off

The reason why a config parameter named PrivateTmp is not only working on the documented folders /tmp or /var/tmp but also blocks access to /var/spool (or /var/spool/postfix/private/auth_dovecot) content is not clear to me.

SirFartALot
  • 101
  • 3