Dovecot 2.4 LMTP socket for Postfix / Dovecot base_dir not created upon restart
Hi there,
After over a week of Dovecot 2.3 -> 2.4 upgrade testing in various mailserver clones, I am now ready for the big picture. Thanks Aki for the Config Upgrader https://dovecot.org/upgrader/ which helped a lot!
Tomorrow, I am planning to upgrade a larger mailserver in these 3 steps:
- Debian Bullseye / Dovecot 2.3.21 => 2.4.1
- Debian Bullseye => Bookworm / Dovecot 2.4.1 => 2.4.2
- Debian Bookworm => Trixie
Postfix needs to talk to Dovecot over LMTP, using the following in main.cf:
virtual_transport = lmtp:unix:/run/dovecot/lmtp
Now, while testing this in a full server clone, I stepped over my planned LMTP server setup:
=============================================== service lmtp { unix_listener /run/dovecot/lmtp { mode = 0666 user = postfix group = postfix } }
protocols = imap pop3 sieve lmtp
The socket needs to be owned by postfix:postfix for some (security) reasons, otherwise Postfix complains. That's why I cannot go with the default, as documented here:
https://doc.dovecot.org/2.4.2/core/config/delivery/lmtp.html#lmtp-server
The UNIX listener on $base_dir/lmtp is enabled by default when protocols setting contains lmtp.
But, when using an absolute path on unix_listener, upgrade step 2) Bullseye=>Bookworm breaks with:
Processing triggers for dovecot-core (2:2.4.2-2+debian12) ... Job for dovecot.service failed because the control process exited with error code. (...) dovecot[34446]: master: Error: service(lmtp): Socket already exists: /var/run/dovecot/lmtp dovecot[34446]: master: Fatal: Failed to start listeners
I then moved to unix_listener lmtp:
service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } }
Bookworm upgrade (restarted from scratch with a fresh server clone) went through fine. But even after several dovecot.service restarts, the socket ended up in /run/lmtp without creating the /run/dovecot directory, and after a full system reboot, it was suddenly back where I have expected it: /run/dovecot/lmtp I never changed base_dir, which defaults to /var/run/dovecot/
So, here's my question:
Is that really the recommended setup (using inet_listener lmtp instead of an absolute path) and how can I trust Dovecot to always create the socket in $base_dir/lmtp as documented?
Are you guys aware of this issue or was it just me, a temporary hiccup on my just upgraded server? I just found this in mail.log:
dovecot: master: Error: bind(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Error: service(lmtp): net_listen_unix(/var/run/dovecot/lmtp) failed: No such file or directory dovecot: master: Fatal: Failed to start listeners
Again, this problem seems to have occurred both with unix_listener /run/dovecot/lmtp and unix_listener lmtp and only resolved after a full system reboot.
Thanks, Philip
On 24/02/2026 00:57 EET Philip Iezzi via dovecot <dovecot@dovecot.org> wrote:
<snip/>
But, when using an absolute path on unix_listener, upgrade step 2) Bullseye=>Bookworm breaks with:
Processing triggers for dovecot-core (2:2.4.2-2+debian12) ... Job for dovecot.service failed because the control process exited with error code. (...) dovecot[34446]: master: Error: service(lmtp): Socket already exists: /var/run/dovecot/lmtp dovecot[34446]: master: Fatal: Failed to start listeners
I then moved to
unix_listener lmtp:service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } }
Bookworm upgrade (restarted from scratch with a fresh server clone) went through fine. But even after several dovecot.service restarts, the socket ended up in /run/lmtp without creating the /run/dovecot directory, and after a full system reboot, it was suddenly back where I have expected it: /run/dovecot/lmtp I never changed base_dir, which defaults to /var/run/dovecot/
On most modern operating systems, /var/run and /run are the same. So unless you touched something, dovecot should always use /run/dovecot. Not sure what happened there, but I suspect you accidentically changed something.
Aki
On 24 Feb 2026, at 06:53, Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 24/02/2026 00:57 EET Philip Iezzi via dovecot <dovecot@dovecot.org> wrote:
<snip/>
But, when using an absolute path on unix_listener, upgrade step 2) Bullseye=>Bookworm breaks with:
Processing triggers for dovecot-core (2:2.4.2-2+debian12) ... Job for dovecot.service failed because the control process exited with error code. (...) dovecot[34446]: master: Error: service(lmtp): Socket already exists: /var/run/dovecot/lmtp dovecot[34446]: master: Fatal: Failed to start listeners
I then moved to
unix_listener lmtp:service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } }
Bookworm upgrade (restarted from scratch with a fresh server clone) went through fine. But even after several dovecot.service restarts, the socket ended up in /run/lmtp without creating the /run/dovecot directory, and after a full system reboot, it was suddenly back where I have expected it: /run/dovecot/lmtp I never changed base_dir, which defaults to /var/run/dovecot/
On most modern operating systems, /var/run and /run are the same. So unless you touched something, dovecot should always use /run/dovecot. Not sure what happened there, but I suspect you accidentically changed something.
Thanks Aki. I know, /var/run -> /run symlink always existed (since very old Debian versions), so that definitely did not change on Bookworm upgrade. So it must have been some Bookworm upgrade "glitch" with /run temporarily not being available... Is there some code in Dovecot that decides to fall back to /run if $base_dir (/run/dovecot) is missing? That's the only thing I really wondered about - why dit the socket ever end up in /run/lmtp instead of /run/dovecot/lmtp ? If the whole /run/dovecot cannot be created for some reason, Dovecot should not be able to start.
Please just confirm that my current config is "sane":
service lmtp { unix_listener lmtp { mode = 0666 user = postfix group = postfix } }
With this setup, am I somehow fighting against the default lmtp socket which would already be created as root:root because of protocols = lmtp ... definition?
Just want to make sure this socket will always be available, as it is the most crucial part of my whole setup.
Cheers, Philip
participants (2)
-
Aki Tuomi
-
Philip Iezzi