Public bug reported: Package
amavisd-milter (Debian/Ubuntu packaging — affects all releases using the Type=forking + /etc/init.d/amavisd-milter systemd unit, tested on amavisd-milter 1.7.2-3 / Ubuntu, likely affects Debian equivalents too) Summary The packaged default configuration places amavisd-milter's PID file inside /var/run/amavis (/run/amavis), the same runtime directory owned and managed by amavis.service via RuntimeDirectory=amavis. Because systemd deletes and recreates that directory on every start/stop of amavis.service, restarting amavis silently deletes amavisd-milter's PID file out from under the still-running amavisd-milter process — even though amavisd-milter itself is untouched and keeps running. The next systemctl restart amavisd-milter then fails: start-stop-daemon can't find the (now-missing) PID file to identify and stop the running process, so it does nothing, and a second amavisd-milter instance starts and fails to bind its already-held listening socket: amavisd-milter: Unable to bind to port inet:[email protected]: Address already in use amavisd-milter: Unable to create listening socket on conn inet:[email protected] could not open milter socket inet:[email protected] Root cause Two independent, individually-reasonable decisions collide: /etc/default/amavisd-milter's shipped default (commented) suggests: # Pidfile is placed in run-directory from amavisd-new #PIDFILE=/var/run/amavis/amavisd-milter.pid i.e., intentionally reusing amavisd-new's runtime directory rather than creating a dedicated one for amavisd-milter. The current amavis.service systemd unit declares RuntimeDirectory=amavis, which tells systemd to own that directory's full lifecycle — wiping and recreating it on every start/stop of amavis, with no awareness that another, unrelated unit (amavisd-milter.service) has a file living inside it. Reusing that directory was harmless under sysvinit/upstart, where directory lifecycle wasn't tied to a specific service's start/stop. It stopped being safe once amavis.service adopted RuntimeDirectory=, and the amavisd-milter packaging (and its default config comment) was never updated to reflect that. Steps to reproduce Confirm amavisd-milter is running and its PID file exists in /var/run/amavis/amavisd-milter.pid (default config). systemctl restart amavis Observe /var/run/amavis/amavisd-milter.pid no longer exists, while amavisd-milter is still running (netstat -tlpn | grep 10024 still shows the original PID). systemctl restart amavisd-milter Observe the bind failure above in the mail log; systemctl status amavisd-milter shows a new PID that failed to start, while the original orphaned process is still bound to the port. Suggested fix Change the packaged default PIDFILE (and the debian/amavisd-milter.init script's directory-creation logic, which already handles creating and chowning $(dirname "$PIDFILE")) to point at a dedicated directory not owned by amavis.service, e.g. /run/amavisd-milter/amavisd-milter.pid, and update the accompanying comment in /etc/default/amavisd-milter accordingly. This requires no change to amavis.service itself. Workaround (currently applied locally) sh sed -i -e 's/^# *PIDFILE=\/var\/run\/amavis\/amavisd-milter\.pid/PIDFILE=\/run\/amavisd-milter\/amavisd-milter.pid/' /etc/default/amavisd-milter mkdir -p /run/amavisd-milter chown amavis:amavis /run/amavisd-milter systemctl restart amavisd-milter Environment OS: Ubuntu 26.04 (resolute) amavisd-milter version: 1.7.2-3 amavis.service unit confirms RuntimeDirectory=amavis, no PIDFile= amavisd-milter.service unit uses Type=forking, GuessMainPID=no, RemainAfterExit=yes, wrapping /etc/init.d/amavisd-milter ** Affects: amavisd-milter (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2165162 Title: amavisd-milter pidfile shares amavis.service's RuntimeDirectory, causing stop/restart to silently fail To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amavisd-milter/+bug/2165162/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
