Univention Bugzilla – Bug 39542
univention-mail-postfix broken in docker container
Last modified: 2015-11-17 12:12:31 CET
postfix seems to be completely broken in docker container (dudle-docker app) * mail/alias/root: systemmail@. * postfix/cleanup: /etc/postfix/canonical.db No such file or directory * postfix/qmgr[1404]: warning: connect to transport private/retry: No such file or directory * /etc/init.d/postfix restart Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfixpostfix/postfix-script: fatal: the Postfix mail system is already running failed!
Can we remove it from the docker container?
(In reply to Stefan Gohmann from comment #1) > Can we remove it from the docker container? yes, we define univention-mail-postfix | mail-transport-agent in our packages, so we could pre-install a different lightweight mta (which?), but the first groupware docker app will hit these problems again
Ah, I meant complete without a MTA. If it is not possible, we should fix the postfix configuration.
This is fixed by running: # ucr commit /etc/postfix/main.cf # /etc/init.d/postfix start The problem originates from something during the image/container setup: The host has no FQDN, only a hostname: # hostname -s owncloud8-docker-1445592891194249 # hostname -f owncloud8-docker-1445592891194249 That is because /etc/hosts misses the FQDN entry: # grep owncloud8-docker-1445592891194249 /etc/hosts 172.17.0.1 owncloud8-docker-1445592891194249 The problem is, that the file cannot be remade, because it is somehow mounted: # ucr commit /etc/hosts Multifile: /etc/hosts E: your request could not be fulfilled # mount | grep hosts /dev/mapper/vg_ucs-root on /etc/hosts type ext4 (rw,relatime,errors=remount-ro,data=ordered) In the host the file is empty: # ls -l /var/lib/docker/overlay/8b51c6dff16ecacd65fa783a392a63a103781d42fd5aadebe54786c80eb47e22/*/etc/hosts -rwxr-xr-x 1 root root 0 Okt 23 11:36 /var/lib/docker/overlay/8b51c6dff16ecacd65fa783a392a63a103781d42fd5aadebe54786c80eb47e22/merged/etc/hosts -rwxr-xr-x 1 root root 0 Okt 23 11:36 /var/lib/docker/overlay/8b51c6dff16ecacd65fa783a392a63a103781d42fd5aadebe54786c80eb47e22/upper/etc/hosts
Maybe the fix from #38011 didn't make it into the image?
(In reply to Daniel Tröder from comment #5) > Maybe the fix from #38011 didn't make it into the image? The /etc/hosts stuff worked in my container, but postfix does not: root@dudle-docker-1445608036200544:/# ucr commit /etc/hosts Multifile: /etc/hosts root@dudle-docker-1445608036200544:/# grep dudle /etc/hosts 172.17.0.1 dudle-docker-1445608036200544.deadlock44.intranet dudle-docker-1445608036200544 root@dudle-docker-1445608036200544:/# ucr commit /etc/postfix/main.cf Multifile: /etc/postfix/main.cf root@dudle-docker-1445608036200544:/# /etc/init.d/postfix restart Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfixpostfix/postfix-script: fatal: the Postfix mail system is already running failed! root@dudle-docker-1445608036200544:/# hostname -f dudle-docker-1445608036200544.deadlock44.intranet root@dudle-docker-1445608036200544:/#
(In reply to Stefan Gohmann from comment #6) > root@dudle-docker-1445608036200544:/# /etc/init.d/postfix restart > Stopping Postfix Mail Transport Agent: postfix. > Starting Postfix Mail Transport Agent: postfixpostfix/postfix-script: fatal: > the Postfix mail system is already running > failed! The univention-docker-container-mode now only disables the postfix start via UCR: postfix/autostart?false If I stop postfix on the host outside the container, everything works. So I think if we deliver a groupware app as docker container, we need to stop postfix on the host and redirect the mail ports into the container. OK?
(In reply to Stefan Gohmann from comment #7) > If I stop postfix on the host outside the container, everything works. So I > think if we deliver a groupware app as docker container, we need to stop > postfix on the host and redirect the mail ports into the container. > > OK? We've decided to fix it. Otherwise cron mails won't be delivered. I've removed the autostart variable: r64880
(In reply to Stefan Gohmann from comment #7) > (In reply to Stefan Gohmann from comment #6) > > root@dudle-docker-1445608036200544:/# /etc/init.d/postfix restart > > Stopping Postfix Mail Transport Agent: postfix. > > Starting Postfix Mail Transport Agent: postfixpostfix/postfix-script: fatal: > > the Postfix mail system is already running > > failed! > > The univention-docker-container-mode now only disables the postfix start via > UCR: postfix/autostart?false > > If I stop postfix on the host outside the container, everything works. So I > think if we deliver a groupware app as docker container, we need to stop > postfix on the host and redirect the mail ports into the container. In docker containers even root processes do not have permission to read /proc/$PID/exe. This file was used by /etc/init.d/postfix to determine if postfix was already running. The following code block dir=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* -> //; s/\/[^\/]*$//') if [ "X$dir" = "X/usr/lib/postfix" ]; then echo y fi has been replaced by pgrep -f /usr/lib/postfix -s "$pid" && echo y || true univention-mail-postfix (10.0.0-3): r65011 | Bug #39542: fix detection if postfix master is already running r65014 | Bug #39542: updated detection if postfix master is already running NONE: r65012 | Bug #39542: added changelog entry r65013 | Bug #39542: updated changelog entry
OK, stop/start works but i can't send a mail to root with -> echo "aa" | sendmail root inside the container mail.log ... ng: maildrop/5DF45814F2: error writing 5EFE9814F3: queue file write error
(In reply to Felix Botner from comment #10) > OK, stop/start works > > but i can't send a mail to root with > -> echo "aa" | sendmail root > inside the container > > mail.log > ... > ng: maildrop/5DF45814F2: error writing 5EFE9814F3: queue file write error At least the following commands have to be executed to fix this problem: postmap /etc/postfix/canonical postmap /etc/postfix/relocated These should be called by univention-mail-postfix.postinst automatically during installation. Any idea why *.db is removed from /etc/postfix/ ?
r65168: relocated changelog entry from section changelog:umc:mail to changelog:service:mail.
The create-docker-ucs-appbox-image.log logfile from 17:52 shows this: =================================================================== Multifile: /etc/postfix/main.cf ESC[91mpostmap: fatal: bad string length 0 < 1: mydomain = ESC[0mESC[91mpostmap: fatal: bad string length 0 < 1: mydomain = ESC[0mESC[91mpostmap: fatal: bad string length 0 < 1: mydomain = ESC[0mESC[91mpostmap: fatal: bad string length 0 < 1: mydomain = ESC[0mESC[91mpostmap: fatal: bad string length 0 < 1: mydomain = ESC[0mESC[91mnewaliases: fatal: bad string length 0 < 1: mydomain = ESC[0mAdding user `postfix' to group `sasl' ... Adding user postfix to group sasl Done. File: /etc/mailname File: /etc/listfilter.secret Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix. ESC[91minvoke-rc.d: policy-rc.d denied execution of reload. ===================================================================
univention-docker-container-mode now supports hook scripts of other packages that are called upon container startup. All all scripts in /etc/univention/docker/init.d/ are now run by /etc/init.d/univention-docker-container-mode. This way, univention-mail-postfix has the ability to check for missing .db files after the hostname/domainname has been configured. During app creation, the hostname is not known and therefore postmap fails to create the missing db files. Additionally the UCR variable mail/alias/root is set to "systemmail@$domainname.$hostname" if the variable still contains the incorrect value "systemmail@.". univention-mail-postfix (10.0.0-6): r65227 | Bug #39542: recreate missing lookup tables / fix mail/alias/root univention-docker-container-mode (1.0.11-1): r65226 | run all scripts from /etc/univention/docker/init.d after starting univention-docker-container-mode (Bug #39542) Additional changelog entry not required.
OK, installed a docker app updates univention-mail-postfix and then univention-docker-container-mode after restarting the container a mail too root has been delivered to /var/spool/mail/systemmail.
UCS 4.1 has been released: https://docs.software-univention.de/release-notes-4.1-0-en.html https://docs.software-univention.de/release-notes-4.1-0-de.html If this error occurs again, please use "Clone This Bug".