Solution (almost certainly): postfix fails to launch at boot

[Gerben Wierda]

> On 10 Jan 2020, at 18:37, Gerben Wierda <gerben.wierda at rna.nl> wrote:
> 
> postfix is started during boot on my macOS system. This fails with:
> 
> Jan 10 18:00:08 mail postfix/master[488]: fatal: bind 0.0.0.0 port 25: Address already in use
> Jan 10 18:00:10 mail /postfix-script[511]: fatal: mail system startup failed
> 
> but when I shortly thereafter launch it it just starts fine.
> 
> It seems something in the postfix/macOS combo makes this happen. Probably a weirdness in macOS if postfix starts when the system is still in some startup state (there have been more issues like this with macOS), so what I could use is a way to make postfix a bit more persistent in trying to start on a fatal.
> 
> startupitem.create      yes
> startupitem.start       "${prefix}/sbin/${name} start"
> startupitem.stop        "${prefix}/sbin/${name} stop"
> 
> Given that postfix writes a pid file in /opt/local/var/spool/postfix/pid/master.pid would it be possible to use a startupitem.pidfile entry that triggers daemondo to try to relaunch when this happens? Note: postfix is started by a program running  script which then starts the master process that writes the pid file.
> 

It is not necessary as the cause has (probably) been found.

macOS still contains a postfix and it is launched at boot time during 60 seconds with a launchdaemon plist /System/Library/LaunchDaemons/com.apple.postfix.master.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
 	<string>com.apple.postfix.master</string>
        <key>Program</key>
        <string>/usr/libexec/postfix/master</string>
        <key>ProgramArguments</key>
        <array>
                <string>master</string>
                <string>-e</string>
                <string>60</string>
        </array>
	<key>QueueDirectories</key>
        <array>
                <string>/var/spool/postfix/maildrop</string>
        </array>
        <key>AbandonProcessGroup</key>
        <true/>
</dict>
</plist>

This runs master for 60 seconds during boot to clear any queue created by Apple’s sendmail and when something is dropped in that queue. This creates a race condition with MacPorts postfix (hence the remark in the mail-server Port that launching postfix after boot is unreliable).

Apple’s postfix master is steered by /etc/postfix/master.cf, which contains entries for smtpd (2x) and postscreen. Commenting these out:

# ==== Begin auto-generated section ========================================
# This section of the master.cf file is auto-generated by the Server Admin
#  Mail backend plugin whenever mails settings are modified.
# GW: Commented postscreen, smtpd commands as Apple's postfix master gets run for 60 sec at boot
#smtp      inet  n	 -	 n	 -	 1	 postscreen
#smtpd     pass  -       -       n       -       -       smtpd
dnsblog   unix  -	-	n	-	0	dnsblog
tlsproxy  unix  -       -       n     	-	0	tlsproxy
#submission inet n	 -	 n	 -	 -	 smtpd
#  -o smtpd_tls_security_level=encrypt

Will result in Apple’s postfix not starting to listen on ports 25 and 587 for 60 seconds during boot or when anything is dropped in its queue by sendmail. (Actually, the second line doesn’t need to be as it doesn’t listen on inet)

Maybe the postfix port should issue a warning about /etc/postfix/master.cf or even better, uncomment these lines (not-commented lines that end in ’smtpd' or ‘postscreen’ and every non-empty-non-comment line that starts with whitespace immediately after. Multiline edit, so a job for awk and beyond my comfort zone.)

G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20200111/5e4c6019/attachment.html>