Debian Bug report logs -
#854475
postfix: systemd needs postfix@.service to have "After=network.target"
Reported by: Russell Coker <russell@coker.com.au>
Date: Tue, 7 Feb 2017 13:33:02 UTC
Severity: important
Tags: patch
Found in version postfix/3.1.4-4
Fixed in version postfix/3.1.4-5
Done: Scott Kitterman <scott@kitterman.com>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Tue, 07 Feb 2017 13:33:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Russell Coker <russell@coker.com.au>:
New Bug report received and forwarded. Copy sent to LaMont Jones <lamont@debian.org>.
(Tue, 07 Feb 2017 13:33:04 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: postfix
Version: 3.1.4-4
Severity: important
Tags: patch
The file /lib/systemd/system/postfix@.service needs to have the line
"After=network.target" to make sure that all the network interfaces are raised
before it is started. Otherwise the startup will abort if Postfix is
configured to bind to any interface other than all (or maybe localhost).
After a recent update postfix would not be running on system start, it would
report that it couldn't bind to one of the IP addresses in it's config file.
After changing the service file it works correctly.
-- System Information:
Debian Release: 9.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages postfix depends on:
ii adduser 3.115
ii cpio 2.11+dfsg-6
ii debconf [debconf-2.0] 1.5.60
ii dpkg 1.18.18
ii init-system-helpers 1.47
ii libc6 2.24-9
ii libdb5.3 5.3.28-12+b1
ii libicu57 57.1-5
ii libsasl2-2 2.1.27~101-g0780600+dfsg-2
ii libssl1.1 1.1.0c-2
ii lsb-base 9.20161125
ii netbase 5.4
ii postfix-sqlite 3.1.4-4
ii ssl-cert 1.0.38
Versions of packages postfix recommends:
ii python3 3.5.3-1
Versions of packages postfix suggests:
ii bsd-mailx [mail-reader] 8.1.2-0.20160123cvs-3
ii dovecot-core [dovecot-common] 1:2.2.27-2
ii libsasl2-modules 2.1.27~101-g0780600+dfsg-2
pn postfix-cdb <none>
ii postfix-doc 3.1.4-4
pn postfix-ldap <none>
pn postfix-lmdb <none>
ii postfix-mysql 3.1.4-4
ii postfix-pcre 3.1.4-4
pn postfix-pgsql <none>
pn procmail <none>
pn resolvconf <none>
pn sasl2-bin <none>
pn ufw <none>
-- Configuration Files:
/etc/network/if-down.d/postfix changed:
exit 0
if [ ! -d /usr/lib/postfix ]; then
exit 0
fi
RUNNING=""
if [ -f /var/spool/postfix/pid/master.pid ]; then
pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid)
exe=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* //;s/.*\///')
if [ "X$exe" = "Xmaster" ]; then
RUNNING="y"
fi
fi
if [ ! -x /sbin/resolvconf ]; then
f=/etc/resolv.conf
if ! cp $f $(postconf -h queue_directory)$f 2>/dev/null; then
exit 0
fi
if [ -n "$RUNNING" ]; then
service postfix reload >/dev/null 2>&1
fi
fi
exit 0
/etc/network/if-up.d/postfix changed:
exit 0
if [ "$IFACE" = "lo" ]; then
exit 0
fi
if [ ! -d /usr/lib/postfix ]; then
exit 0
fi
RUNNING=""
if [ -f /var/spool/postfix/pid/master.pid ]; then
pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid)
exe=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* //;s/.*\///')
if [ "X$exe" = "Xmaster" ]; then
RUNNING="y"
fi
fi
if [ ! -x /sbin/resolvconf ]; then
f=/etc/resolv.conf
if ! cp $f $(postconf -h queue_directory)$f 2>/dev/null; then
exit 0
fi
if [ -n "$RUNNING" ]; then
service postfix reload >/dev/null 2>&1
fi
fi
if [ -n "$RUNNING" ]; then
if [ -x /usr/sbin/sendmail ]; then
/usr/sbin/sendmail -q >/dev/null 2>&1
fi
fi
/etc/ppp/ip-down.d/postfix changed:
exit 0
if [ ! -d /usr/lib/postfix ]; then
exit 0
fi
RUNNING=""
if [ -f /var/spool/postfix/pid/master.pid ]; then
pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid)
exe=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* //;s/.*\///')
if [ "X$exe" = "Xmaster" ]; then
RUNNING="y"
fi
fi
if [ ! -x /sbin/resolvconf ]; then
f=/etc/resolv.conf
if ! cp $f $(postconf -hx queue_directory)$f 2>/dev/null; then
exit 0
fi
if [ -n "$RUNNING" ]; then
service postfix reload >/dev/null 2>&1
fi
fi
exit 0
/etc/ppp/ip-up.d/postfix changed:
exit 0
if [ "$IFACE" = "lo" ]; then
exit 0
fi
if [ ! -d /usr/lib/postfix ]; then
exit 0
fi
RUNNING=""
if [ -f /var/spool/postfix/pid/master.pid ]; then
pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid)
exe=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* //;s/.*\///')
if [ "X$exe" = "Xmaster" ]; then
RUNNING="y"
fi
fi
if [ ! -x /sbin/resolvconf ]; then
f=/etc/resolv.conf
if ! cp $f $(postconf -hx queue_directory)$f 2>/dev/null; then
exit 0
fi
if [ -n "$RUNNING" ]; then
service postfix reload >/dev/null 2>&1
fi
fi
if [ -n "$RUNNING" ]; then
if [ -x /usr/sbin/sendmail ]; then
/usr/sbin/sendmail -q >/dev/null 2>&1
fi
fi
/etc/rsyslog.d/postfix.conf changed:
-- debconf information excluded
-- debsums errors found:
debsums: changed file /lib/systemd/system/postfix@.service (from postfix package)
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sat, 15 Apr 2017 15:24:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Marcus Jodorf <trap@killfile.de>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sat, 15 Apr 2017 15:24:04 GMT) (full text, mbox, link).
Message #10 received at 854475@bugs.debian.org (full text, mbox, reply):
Package: postfix
Version: 3.1.4-4
Followup-For: Bug #854475
Dear Maintainer,
I found a bug that is probably related to #854475 because it seems
also to be caused by postfix starting too early.
I have several systems where mail gets stuck in the queue with
"(Host or domain name not found. Name service error for name=XXXXXXXX
type=AAAA: Host not found, try again)".
Turns out /var/spool/postfix/etc/resolv.conf is empty, only containing
the empty template
"
Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
"
from resolvconf.
But /etc/resolv.conf itself contains proper nameserver entries as
configured in /etc/network/interfaces.
So outgoing emails are stuck in the queue until I restart postfix and
/var/spool/postfix/etc/resolv.conf gets updated.
With "After=network.target" applied, postfix start is delayed and
the postfix copy of resolv.conf contains the necessary entries.
Best regards,
Marcus Jodorf
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sat, 15 Apr 2017 19:21:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Christian Schrötter <cs@fnx.li>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sat, 15 Apr 2017 19:21:05 GMT) (full text, mbox, link).
Message #15 received at 854475@bugs.debian.org (full text, mbox, reply):
Are you sure network.target is enough?
network-online.target sounds much better for me.
--
With kind regards,
Christian Schrötter
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sat, 15 Apr 2017 21:45:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Marcus Jodorf <trap@killfile.de>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sat, 15 Apr 2017 21:45:04 GMT) (full text, mbox, link).
Message #20 received at 854475@bugs.debian.org (full text, mbox, reply):
On 04/15/2017 09:14 PM, Christian Schrötter wrote:
> Are you sure network.target is enough?
>
> network-online.target sounds much better for me.
Hi Christian,
No, I'm not really sure. Just tried it after finding #854475 thinking
that it might actually catch two problems at once.
Especially after stumbling previously over #847440 with resolvconf where
I expected the problem to be in the first place.
Now, in combination with the proposed change there, my guess would be
network.target could be sufficient.
Setting network.target with postfix at least with my two machines works
but maybe network-online.target might be the safe bet considering there
are many machines out there that run slower or faster.
Since I'm currently hunting down some similar race-conditions with
systemd machines (e.g. start of inn2) I can tell you with systemd
nothing is really easy. Start a machine 20 times and at least 2 times of
these you get something quite different.
Best regards,
Marcus Jodorf
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sun, 07 May 2017 20:57:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sun, 07 May 2017 20:57:07 GMT) (full text, mbox, link).
Message #25 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sat, Apr 15, 2017 at 11:42:37PM +0200, Marcus Jodorf wrote:
Hi,
is there anything I can do to get this fixed for Stretch? I can
pretty reliably reproduce this issue with all my upgraded Stretch
systems, neither of them can send mails after a reboot until Postfix is
getting restarted
An After=network.target should be pretty low-risk even this late in the
release cycle and should fix this issue.
Best Regards,
Bernhard
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 04:03:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Scott Kitterman <debian@kitterman.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 04:03:07 GMT) (full text, mbox, link).
Message #30 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
> On Sat, Apr 15, 2017 at 11:42:37PM +0200, Marcus Jodorf wrote:
>
> Hi,
>
> is there anything I can do to get this fixed for Stretch? I can
> pretty reliably reproduce this issue with all my upgraded Stretch
> systems, neither of them can send mails after a reboot until Postfix is
> getting restarted
>
> An After=network.target should be pretty low-risk even this late in the
> release cycle and should fix this issue.
>
> Best Regards,
> Bernhard
postfix.service has After=network.target. Why isn't that enough (I have not
had a lot of time to investigate this, but I have not given on up getting a
fix into stretch)?
Scott K
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 14:09:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 14:09:03 GMT) (full text, mbox, link).
Message #35 received at 854475@bugs.debian.org (full text, mbox, reply):
Am 08.05.2017 um 05:59 schrieb Scott Kitterman:
> On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
>> On Sat, Apr 15, 2017 at 11:42:37PM +0200, Marcus Jodorf wrote:
>>
>> Hi,
>>
>> is there anything I can do to get this fixed for Stretch? I can
>> pretty reliably reproduce this issue with all my upgraded Stretch
>> systems, neither of them can send mails after a reboot until Postfix is
>> getting restarted
>>
>> An After=network.target should be pretty low-risk even this late in the
>> release cycle and should fix this issue.
>>
>> Best Regards,
>> Bernhard
>
> postfix.service has After=network.target. Why isn't that enough (I have not
> had a lot of time to investigate this, but I have not given on up getting a
> fix into stretch)?
AFAICT (Ccing systemd maintainers for input) postfix.service is mostly
used for compatibility with sysv (namely have "service postfix
something" do something reasonably by having the postfix@.service being
PartOf=postfix.service), but the actual decision what instance to start
is done by the generator
(/lib/systemd/system-generators/postfix-instance-generator) which
directly "wants" the instance.
IOW, I don't think postfix@.service being PartOf=postfix.service (which
does have After=network.target) influences its ordering.
The other quick fix for Stretch would be a "After=resolvconf.service", I
think most incarnations of this bug seen to far have been related to that.
Bernhard
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 14:21:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 14:21:02 GMT) (full text, mbox, link).
Message #40 received at 854475@bugs.debian.org (full text, mbox, reply):
I'm missing context here. Can you go into more detail please? What exactly is the question here?
Regards,
Michael
Am 8. Mai 2017 16:07:12 MESZ schrieb Bernhard Schmidt <berni@debian.org>:
>Am 08.05.2017 um 05:59 schrieb Scott Kitterman:
>> On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
>>> On Sat, Apr 15, 2017 at 11:42:37PM +0200, Marcus Jodorf wrote:
>>>
>>> Hi,
>>>
>>> is there anything I can do to get this fixed for Stretch? I can
>>> pretty reliably reproduce this issue with all my upgraded Stretch
>>> systems, neither of them can send mails after a reboot until Postfix
>is
>>> getting restarted
>>>
>>> An After=network.target should be pretty low-risk even this late in
>the
>>> release cycle and should fix this issue.
>>>
>>> Best Regards,
>>> Bernhard
>>
>> postfix.service has After=network.target. Why isn't that enough (I
>have not
>> had a lot of time to investigate this, but I have not given on up
>getting a
>> fix into stretch)?
>
>AFAICT (Ccing systemd maintainers for input) postfix.service is mostly
>used for compatibility with sysv (namely have "service postfix
>something" do something reasonably by having the postfix@.service being
>PartOf=postfix.service), but the actual decision what instance to start
>is done by the generator
>(/lib/systemd/system-generators/postfix-instance-generator) which
>directly "wants" the instance.
>
>IOW, I don't think postfix@.service being PartOf=postfix.service (which
>does have After=network.target) influences its ordering.
>
>The other quick fix for Stretch would be a "After=resolvconf.service",
>I
>think most incarnations of this bug seen to far have been related to
>that.
>
>Bernhard
>
>_______________________________________________
>Pkg-systemd-maintainers mailing list
>Pkg-systemd-maintainers@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 14:51:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 14:51:03 GMT) (full text, mbox, link).
Message #45 received at 854475@bugs.debian.org (full text, mbox, reply):
Am 08.05.2017 um 16:18 schrieb Michael Biebl:
Hi,
> I'm missing context here. Can you go into more detail please? What exactly is the question here?
Sorry.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854475 is about
several issues with postfix being started before the network is up,
failing to bind specific IPs or copying an empty resolvconf managed
/etc/resolv.conf into its chroot on startup. This is happening since
postfix ships native systemd units.
Postfix ships
postfix.service
https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.service/
(oneshot, ExecStart=/bin/true, After=network.target
postfix@.service
https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix%40.service/)
(forking, PartOf=postfix.service, NO After=network.target)
Additionally a snipped in postinst drops an override in /etc in the
standard case of having systemd-resolved installed (not necessarily
used) and the configuration being a somehow managed standard
configuration. It adds additional After= dependencies for
postfix.service on network-online.target and systemd-resolved.service
https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L650
https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L185
It also ships a generator that directly links postfix@ instances into
the WANTDIR
postfix-instance-generator
https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix-instance-generator/
Scott's question was why the After=network.target (and the additional
ordering statements added by the override) of postfix.service isn't
enough to ensure proper ordering on startup. If I understand this
correctly the generator will independently start the postfix@.service
instances. The PartOf=postfix.service does not affect ordering at all.
So for a proper fix the additional After= tweaks need to be added to
postfix@.service, not just postfix.service
Bernhard
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 17:18:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Andreas Henriksson <andreas@fatal.se>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 17:18:07 GMT) (full text, mbox, link).
Message #50 received at 854475@bugs.debian.org (full text, mbox, reply):
Hello Scott, Bernhard,
On Sun, May 07, 2017 at 11:59:10PM -0400, Scott Kitterman wrote:
> On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
>> [...]
> postfix.service has After=network.target. Why isn't that enough (I have not
> had a lot of time to investigate this, but I have not given on up getting a
> fix into stretch)?
I think the main issue here is that people are confused about what
network.target actually is/means.
For example this snippet is part of the original bug report:
The file /lib/systemd/system/postfix@.service needs to have the line
"After=network.target" to make sure that all the network interfaces are raised
[...]
The above description is completely false!
This is *not* what network.target does/means!
For further explanation and suggestions for solutions see:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Regards,
Andreas Henriksson
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 08 May 2017 18:57:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Scott Kitterman <debian@kitterman.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 08 May 2017 18:57:03 GMT) (full text, mbox, link).
Message #55 received at 854475@bugs.debian.org (full text, mbox, reply):
On Monday, May 08, 2017 07:15:06 PM Andreas Henriksson wrote:
> Hello Scott, Bernhard,
>
> On Sun, May 07, 2017 at 11:59:10PM -0400, Scott Kitterman wrote:
> > On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
> >> [...]
> >
> > postfix.service has After=network.target. Why isn't that enough (I have
> > not had a lot of time to investigate this, but I have not given on up
> > getting a fix into stretch)?
>
> I think the main issue here is that people are confused about what
> network.target actually is/means.
>
> For example this snippet is part of the original bug report:
> The file /lib/systemd/system/postfix@.service needs to have the line
> "After=network.target" to make sure that all the network interfaces are
> raised [...]
>
> The above description is completely false!
> This is *not* what network.target does/means!
>
> For further explanation and suggestions for solutions see:
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
In the postinst, if the debconf configuration is something other than none or
local, we create an override file with After=network-online.target, which is
what I think is needed in most of these cases. I did not add it to the
service file because the documentation I read cautioned against using it when
not absolutely required.
The big question that's left unanswered for me is do I need it for
postfix@.service too? Do I need to depend on some other service?
Advice appreciated.
Scott K
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Tue, 09 May 2017 08:39:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Tue, 09 May 2017 08:39:03 GMT) (full text, mbox, link).
Message #60 received at 854475@bugs.debian.org (full text, mbox, reply):
Hi Andreas,
Am 08.05.2017 um 19:15 schrieb Andreas Henriksson:
> Hello Scott, Bernhard,
>
> On Sun, May 07, 2017 at 11:59:10PM -0400, Scott Kitterman wrote:
>> On Sunday, May 07, 2017 10:55:58 PM Bernhard Schmidt wrote:
>>> [...]
>> postfix.service has After=network.target. Why isn't that enough (I have not
>> had a lot of time to investigate this, but I have not given on up getting a
>> fix into stretch)?
>
> I think the main issue here is that people are confused about what
> network.target actually is/means.
>
> For example this snippet is part of the original bug report:
> The file /lib/systemd/system/postfix@.service needs to have the line
> "After=network.target" to make sure that all the network interfaces are raised
> [...]
>
> The above description is completely false!
> This is *not* what network.target does/means!
>
> For further explanation and suggestions for solutions see:
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
I'm well aware of this, but in this particular case network.target is
probably what we want.
It is ordered after networking.service which raises the interfaces
configured by ifupdown. After network.target the majority of "server"
installations will have statically configured interfaces present and a
usable resolv.conf. This is also true for systemd-networkd.
This might still be broken for people using NetworkManager, but I doubt
those will have postfix explicitly bound to a static IP address anyway.
And it won't be worse for them than the current situation.
Bernhard
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Tue, 09 May 2017 09:06:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Tue, 09 May 2017 09:06:06 GMT) (full text, mbox, link).
Message #65 received at 854475@bugs.debian.org (full text, mbox, reply):
Am 08.05.2017 um 20:54 schrieb Scott Kitterman:
Hi Scott,
> In the postinst, if the debconf configuration is something other than none or
> local, we create an override file with After=network-online.target, which is
> what I think is needed in most of these cases. I did not add it to the
> service file because the documentation I read cautioned against using it when
> not absolutely required.
>
> The big question that's left unanswered for me is do I need it for
> postfix@.service too? Do I need to depend on some other service?
My proposal for stretch (minimal intrusive) would be to add
After=postfix.service
to postfix@.service.
This would (transitively) order postfix@.service after network.target,
which means users of ifupdown/systemd-networkd will have networking
configured at this point. I don't think we'd need network-online.target,
there is nothing in most postfix configurations that actually needs
network access to work on startup.
If I understand this correctly an additional benefit of ordering
postfix@.service after postfix.service is that "service postfix reload"
in various hooks will actually work when any instance is running.
I have tested this on top of 3.1.4-4 and it works for me.
I don't fully grasp the service override anyway.
if [ -f /lib/systemd/systemd-resolved ] && \
[ ! -f /etc/systemd/system/postfix.service.d/override.conf ] ; then
if [ "$mailer" != "No configuration" ] && [ "$mailer" != "Local
only" ]; then
echo "Adding systemd overrides to ensure network and name
services available."
add_service_override
fi
fi
/lib/systemd/systemd-resolved is part of systemd, so the first part
always evaluates to "true" if systemd is installed. If it wasn't adding
the override file would have no consequences, so why bother with the
conditional here?
Second, the override adds
[Unit]
After=network-online.target
After=systemd-resolved.service
I think network-online.target is unnecessary, as I'm not aware of any
common postfix configurations that actually need network access to
startup. At least the common case of postfix or SQL the connection is
only made when a mail is getting processed.
systemd-resolved is debatable I think. But I don't see a reason not to
add it to the master postfix.service, it's just ordering and will not
start systemd-resolved by itself.
Bernhard
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Wed, 10 May 2017 15:51:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Scott Kitterman <debian@kitterman.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Wed, 10 May 2017 15:51:03 GMT) (full text, mbox, link).
Message #70 received at 854475@bugs.debian.org (full text, mbox, reply):
On Tue, 9 May 2017 11:03:59 +0200 Bernhard Schmidt <berni@debian.org> wrote:
> Am 08.05.2017 um 20:54 schrieb Scott Kitterman:
>
> Hi Scott,
>
>
> > In the postinst, if the debconf configuration is something other than none
or
> > local, we create an override file with After=network-online.target, which
is
> > what I think is needed in most of these cases. I did not add it to the
> > service file because the documentation I read cautioned against using it
when
> > not absolutely required.
> >
> > The big question that's left unanswered for me is do I need it for
> > postfix@.service too? Do I need to depend on some other service?
>
> My proposal for stretch (minimal intrusive) would be to add
>
> After=postfix.service
>
> to postfix@.service.
>
> This would (transitively) order postfix@.service after network.target,
> which means users of ifupdown/systemd-networkd will have networking
> configured at this point. I don't think we'd need network-online.target,
> there is nothing in most postfix configurations that actually needs
> network access to work on startup.
>
> If I understand this correctly an additional benefit of ordering
> postfix@.service after postfix.service is that "service postfix reload"
> in various hooks will actually work when any instance is running.
>
> I have tested this on top of 3.1.4-4 and it works for me.
>
>
>
> I don't fully grasp the service override anyway.
>
> if [ -f /lib/systemd/systemd-resolved ] && \
> [ ! -f /etc/systemd/system/postfix.service.d/override.conf ] ; then
> if [ "$mailer" != "No configuration" ] && [ "$mailer" != "Local
> only" ]; then
> echo "Adding systemd overrides to ensure network and name
> services available."
> add_service_override
> fi
> fi
>
> /lib/systemd/systemd-resolved is part of systemd, so the first part
> always evaluates to "true" if systemd is installed. If it wasn't adding
> the override file would have no consequences, so why bother with the
> conditional here?
>
> Second, the override adds
>
> [Unit]
> After=network-online.target
> After=systemd-resolved.service
>
> I think network-online.target is unnecessary, as I'm not aware of any
> common postfix configurations that actually need network access to
> startup. At least the common case of postfix or SQL the connection is
If you specify an IP address in inet_interfaces, postfix will fail to start
withhout the override to depend on network-online.target. We can quibble
about if that qualifies a common or not, but we got bug reports [1], so it's
common enough in my opinion.
You may well be correct about the systemd-resolved.service. I tried to work
on this bug last night, but failed to make useful progress beyond learning
that NetworkManager and systemd will conspire to restart postfix once
resolv.conf is available, so the specific problem in this bug isn't an issue
for an NM based system. At least on the system with NM installed, nothing I
tried (your suggestion or others) seemed to make a difference. I need to rip
NM out of my test system and see what I can figure out next.
Scott K
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844277
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Wed, 10 May 2017 16:36:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Schmidt <berni@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Wed, 10 May 2017 16:36:05 GMT) (full text, mbox, link).
Message #75 received at 854475@bugs.debian.org (full text, mbox, reply):
Am 10.05.2017 um 17:46 schrieb Scott Kitterman:
Hi Scott,
>> I think network-online.target is unnecessary, as I'm not aware of any
>> common postfix configurations that actually need network access to
>> startup. At least the common case of postfix or SQL the connection is
>
> If you specify an IP address in inet_interfaces, postfix will fail to start
> withhout the override to depend on network-online.target. We can quibble
> about if that qualifies a common or not, but we got bug reports [1], so it's
> common enough in my opinion.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844277
Has anyone ever confirmed that this setting on postfix.service actually
fixes this issue? I see no communication in the bug about it, and to my
understanding adding _anything_ on postfix.service won't make a
difference (since the only dependencies relevant for startup are on
postfix@.service).
With ifupdown and resolvconf, and your override in place, I can still
reproduce Bug#844277 (it is easier to trigger by adding
pre-up /bin/sleep 5
to /etc/network/interfaces)
May 10 18:26:22 voip20 postmulti[638]: fatal: parameter inet_interfaces:
no local interface found for xx.xx.xx.xx
May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Control process
exited, code=exited status=1
May 10 18:26:23 voip20 systemd[1]: Failed to start Postfix Mail
Transport Agent (instance -).
May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Unit entered
failed state.
May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Failed with result
'exit-code'.
May 10 18:26:27 voip20 kernel: [ 7.787458] vmxnet3 0000:0b:00.0 eth0:
intr type 3, mode 0, 2 vectors allocated
May 10 18:26:27 voip20 kernel: [ 7.787725] vmxnet3 0000:0b:00.0 eth0:
NIC Link is Up 10000 Mbps
May 10 18:26:29 voip20 systemd[1]: Started Raise network interfaces.
Adding the After=postfix.service into postfix@.service fixes this issue
for good (because postfix@.service <- postfix.service <- network.target
<- networking.service)
NM is a completely different beast, I think you may need to be
After=network-online.target here. But static IP with NetworkManager, and
having postfix bind to it, should really be seldom enough.
Bernhard
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Thu, 11 May 2017 04:21:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Scott Kitterman <debian@kitterman.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Thu, 11 May 2017 04:21:03 GMT) (full text, mbox, link).
Message #80 received at 854475@bugs.debian.org (full text, mbox, reply):
On May 10, 2017 12:32:59 PM EDT, Bernhard Schmidt <berni@debian.org> wrote:
>Am 10.05.2017 um 17:46 schrieb Scott Kitterman:
>
>Hi Scott,
>
>>> I think network-online.target is unnecessary, as I'm not aware of
>any
>>> common postfix configurations that actually need network access to
>>> startup. At least the common case of postfix or SQL the connection
>is
>>
>> If you specify an IP address in inet_interfaces, postfix will fail to
>start
>> withhout the override to depend on network-online.target. We can
>quibble
>> about if that qualifies a common or not, but we got bug reports [1],
>so it's
>> common enough in my opinion.
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844277
>
>Has anyone ever confirmed that this setting on postfix.service actually
>fixes this issue? I see no communication in the bug about it, and to my
>understanding adding _anything_ on postfix.service won't make a
>difference (since the only dependencies relevant for startup are on
>postfix@.service).
>
>With ifupdown and resolvconf, and your override in place, I can still
>reproduce Bug#844277 (it is easier to trigger by adding
>
> pre-up /bin/sleep 5
>
>to /etc/network/interfaces)
>
>May 10 18:26:22 voip20 postmulti[638]: fatal: parameter
>inet_interfaces:
>no local interface found for xx.xx.xx.xx
>May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Control process
>exited, code=exited status=1
>May 10 18:26:23 voip20 systemd[1]: Failed to start Postfix Mail
>Transport Agent (instance -).
>May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Unit entered
>failed state.
>May 10 18:26:23 voip20 systemd[1]: postfix@-.service: Failed with
>result
>'exit-code'.
>May 10 18:26:27 voip20 kernel: [ 7.787458] vmxnet3 0000:0b:00.0
>eth0:
>intr type 3, mode 0, 2 vectors allocated
>May 10 18:26:27 voip20 kernel: [ 7.787725] vmxnet3 0000:0b:00.0
>eth0:
>NIC Link is Up 10000 Mbps
>May 10 18:26:29 voip20 systemd[1]: Started Raise network interfaces.
>
>
>Adding the After=postfix.service into postfix@.service fixes this issue
>for good (because postfix@.service <- postfix.service <- network.target
><- networking.service)
>
>NM is a completely different beast, I think you may need to be
>After=network-online.target here. But static IP with NetworkManager,
>and
>having postfix bind to it, should really be seldom enough.
>
>Bernhard
I recall doing tests. It's possible I got it wrong. I am still trying to figure out the 'simpler' world of systemd.
Scott K
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sun, 14 May 2017 15:06:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sun, 14 May 2017 15:06:10 GMT) (full text, mbox, link).
Message #85 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi everyone,
a couple of comments inline
Am 08.05.2017 um 16:47 schrieb Bernhard Schmidt:
> Am 08.05.2017 um 16:18 schrieb Michael Biebl:
>
> Hi,
>
>> I'm missing context here. Can you go into more detail please? What exactly is the question here?
>
> Sorry.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854475 is about
> several issues with postfix being started before the network is up,
> failing to bind specific IPs or copying an empty resolvconf managed
> /etc/resolv.conf into its chroot on startup. This is happening since
> postfix ships native systemd units.
>
> Postfix ships
>
> postfix.service
> https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.service/
> (oneshot, ExecStart=/bin/true, After=network.target
So postfix.service is a dummy service. You actually would want a target
to group several services together. I notice though, that your
postfix@.service has ReloadPropagatedFrom=postfix.service.
This does indeed not work for .targets atm [1]. So such a dummy service
is the best you can do.
That said, what you usually want is that
systemctl start postfix.service is only marked as started once all
instanced postfix@.service units have started up. For that
postfix@.service should have
Before=postfix.service.
> postfix@.service
> https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix%40.service/)
> (forking, PartOf=postfix.service, NO After=network.target)
>
> Additionally a snipped in postinst drops an override in /etc in the
> standard case of having systemd-resolved installed (not necessarily
> used) and the configuration being a somehow managed standard
> configuration. It adds additional After= dependencies for
> postfix.service on network-online.target and systemd-resolved.service
> https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L650
> https://sources.debian.net/src/postfix/3.1.4-4/debian/postfix.postinst/#L185
It's rather odd to have that After= ordering generated via a drop-in and
have that applied to the dummy service. You really would want to apply
that to the unit starting the real service, especially given my comment
above that you want postfix@.service have a Before=postfix.service.
I probably also wouldn't bother generating the network dependency
dynamically. After all, a user could modify the postfix config without
using dpkg-reconfigure. So you probably just want to use that
unconditionally.
As for network.target vs network-online.target, please read
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ and man
systemd.special
network.target is a so called passive target which is activated once
your network configuration has started. It doesn't actually mean that
your interfaces have been configured.
After=network.target is thus mostly interesting on shutdown, when you
want to ensure your service is stopped before the network configuration
is stopped.
What you probably want is
After=network-online.target
Wants=network-online.target
network-online.target is an active target, which needs to be pulled in
explicitly by the consumer, thus the Wants=.
For ifupdown network.target and network-online.target are mostly the
same (it basically just runs ifup -a) and that only includes interfaces
of type auto. allow-hotplug is currently not hooked up in
network-online.target/network.target in any way.
For other network configuration systems, the situation is different,
take NetworkManager.
network.target for NetworkManager simply means, that
NetworkManager.service, ie. the NetworkManager daemon has started. It
doesn't say anything about configured interfaces which are dynamically
actived by NetworkManager
network-online.target for NetworkManager means that
NetworkManager-wait-online.service has run. This is a service which
waits until nm-online reports an active connection (see man nm-online).
I suppose one of the bug reporters was using ifupdown with interfaces of
type auto. That's why After=network.target was sufficient for him.
As for systemd-resolved, I can't really comment on that why that's
necessary. At least that comment is wrong for Debian though:
> # If using systemd without systemd-resolved, you're on your own.
We do *not* enable systemd-resolved in Debian by default, so I don't
think this actually fixes something in Debian, the situation might be
different for Ubuntu.
The comment in postinst says, that you need DNS resolution. That's what
usually nss-lookup.target is for, which translates to $named in SysV. I
notice that the old SysV init script has Required-Start: $named, which
would translate into a After=nss-lookup.target ordering.
With that all said, this would be my recommendation:
- debian/postfix.postinst: drop the postfix.service.d/override.conf and
make sure to remove that conffile on upgrades
- postfix.service:
Drop After=network.target
- postfix@.service:
Add the following
PartOf=postfix.service
Before=postfix.service
ReloadPropagatedFrom=postfix.service
After=network-online.target nss-lookup.target
Wants=network-online.target
- debian/postfix.postinst: drop the postfix.service.d/override.conf and
make sure to remove that conffile on upgrades
If you have further questions, please ask.
Regards,
Michael
[1] https://github.com/systemd/systemd/issues/710
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Sun, 14 May 2017 15:33:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Sun, 14 May 2017 15:33:03 GMT) (full text, mbox, link).
Message #90 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 14.05.2017 um 17:02 schrieb Michael Biebl:
> - debian/postfix.postinst: drop the postfix.service.d/override.conf and
> make sure to remove that conffile on upgrades
Seems due to some C&P failure I duplicated this point. I wanted to
clarify that postfix.service.d/override.conf is not actually a conffile,
as it's generated dynamically.
As for my reasons to not generate this configuration dynamically:
- It's less opaque. I was puzzled for a moment where this drop-in was
coming from
- It makes it easier to override postfix@.service. Atm you e.g. don't
respect if the admin removed that drop-in deliberately and you always
recreate it.
- It's more robust in case of local modifications which don't use
dpkg-reconfigure.
- The penalty of pulling in network-online.target is simply that for the
local case postfix is started a bit later then necessary during boot.
- The behaviour is more consistent with the old SysV init script which
had Required-Start: $network (The $network LSB facility translates to
network-online.target)
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 15 May 2017 06:39:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Nuno Paquete <nunopaquete@gmail.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 15 May 2017 06:39:06 GMT) (full text, mbox, link).
Message #95 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi guys.
I'm trying to unsubscribe this newsletter but I'm not getting success.
Can someone Help?
Many thanks in advance.
Em 14/05/2017 16:33, "Michael Biebl" <biebl@debian.org> escreveu:
> Am 14.05.2017 um 17:02 schrieb Michael Biebl:
> > - debian/postfix.postinst: drop the postfix.service.d/override.conf and
> > make sure to remove that conffile on upgrades
>
> Seems due to some C&P failure I duplicated this point. I wanted to
> clarify that postfix.service.d/override.conf is not actually a conffile,
> as it's generated dynamically.
>
> As for my reasons to not generate this configuration dynamically:
> - It's less opaque. I was puzzled for a moment where this drop-in was
> coming from
>
> - It makes it easier to override postfix@.service. Atm you e.g. don't
> respect if the admin removed that drop-in deliberately and you always
> recreate it.
>
> - It's more robust in case of local modifications which don't use
> dpkg-reconfigure.
>
> - The penalty of pulling in network-online.target is simply that for the
> local case postfix is started a bit later then necessary during boot.
>
> - The behaviour is more consistent with the old SysV init script which
> had Required-Start: $network (The $network LSB facility translates to
> network-online.target)
>
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>
[Message part 2 (text/html, inline)]
Added tag(s) pending.
Request was from Scott Kitterman <scott@kitterman.com>
to control@bugs.debian.org.
(Mon, 15 May 2017 14:09:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Mon, 15 May 2017 20:33:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Scott Kitterman <debian@kitterman.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Mon, 15 May 2017 20:33:02 GMT) (full text, mbox, link).
Message #102 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Sunday, May 14, 2017 05:28:51 PM Michael Biebl wrote:
> Am 14.05.2017 um 17:02 schrieb Michael Biebl:
> > - debian/postfix.postinst: drop the postfix.service.d/override.conf and
> > make sure to remove that conffile on upgrades
>
> Seems due to some C&P failure I duplicated this point. I wanted to
> clarify that postfix.service.d/override.conf is not actually a conffile,
> as it's generated dynamically.
>
> As for my reasons to not generate this configuration dynamically:
> - It's less opaque. I was puzzled for a moment where this drop-in was
> coming from
>
> - It makes it easier to override postfix@.service. Atm you e.g. don't
> respect if the admin removed that drop-in deliberately and you always
> recreate it.
>
> - It's more robust in case of local modifications which don't use
> dpkg-reconfigure.
>
> - The penalty of pulling in network-online.target is simply that for the
> local case postfix is started a bit later then necessary during boot.
>
> - The behaviour is more consistent with the old SysV init script which
> had Required-Start: $network (The $network LSB facility translates to
> network-online.target)
>
> Michael
Thank you very much for the clear and complete input. I've just uploaded a
fixed package that puts your suggestions into operation (modulo I screwed it
up).
Scott K
[signature.asc (application/pgp-signature, inline)]
Reply sent
to Scott Kitterman <scott@kitterman.com>:
You have taken responsibility.
(Mon, 15 May 2017 21:09:07 GMT) (full text, mbox, link).
Notification sent
to Russell Coker <russell@coker.com.au>:
Bug acknowledged by developer.
(Mon, 15 May 2017 21:09:07 GMT) (full text, mbox, link).
Message #107 received at 854475-close@bugs.debian.org (full text, mbox, reply):
Source: postfix
Source-Version: 3.1.4-5
We believe that the bug you reported is fixed in the latest version of
postfix, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 854475@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Scott Kitterman <scott@kitterman.com> (supplier of updated postfix package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Mon, 15 May 2017 16:03:17 -0400
Source: postfix
Binary: postfix postfix-ldap postfix-lmdb postfix-cdb postfix-pcre postfix-mysql postfix-pgsql postfix-sqlite postfix-doc
Architecture: source amd64 all
Version: 3.1.4-5
Distribution: unstable
Urgency: medium
Maintainer: LaMont Jones <lamont@debian.org>
Changed-By: Scott Kitterman <scott@kitterman.com>
Description:
postfix - High-performance mail transport agent
postfix-cdb - CDB map support for Postfix
postfix-doc - Documentation for Postfix
postfix-ldap - LDAP map support for Postfix
postfix-lmdb - LMDB map support for Postfix
postfix-mysql - MySQL map support for Postfix
postfix-pcre - PCRE map support for Postfix
postfix-pgsql - PostgreSQL map support for Postfix
postfix-sqlite - SQLite map support for Postfix
Closes: 854475 859805 861593
Changes:
postfix (3.1.4-5) unstable; urgency=medium
.
* Add postfix-cdb Breaks: postfix << 3.1.3-7~ so that the incorrect addmap
function will not be used when postfix-cdb is configured. Closes: #861593
* Make sure to call delmap on upgrade as well as remove and purge so
dpkg-reconfigure will fix broken upgrades. Closes: #859805
* Drop ineffective service override generated in postinst and use correct
service file dependencies in postfix@.service instead. Closes: #854475
* Clean up left-over /etc/systemd/system/postfix.service.d directory
Checksums-Sha1:
cd5c16d0c8159e8fc4d6222d1a93ae7ca0a1d6f4 2650 postfix_3.1.4-5.dsc
cf68f7e08a7f94b0aa013553c443c7acc04a3a5a 191032 postfix_3.1.4-5.debian.tar.xz
f04e0f5357ceea7fc71a20f9b7c8ad4ae150e4af 2410 postfix-cdb-dbgsym_3.1.4-5_amd64.deb
c2f3ebe7ad514b65d690dbb1244930444b53fd07 313132 postfix-cdb_3.1.4-5_amd64.deb
b2b417cbeedff9237b4a7d5fd03c6d33e3654c57 97924 postfix-dbgsym_3.1.4-5_amd64.deb
c158c01098f97f6365fdda1d4681da586a7dbf75 1173646 postfix-doc_3.1.4-5_all.deb
22e09da3db4174d818ce9350eb9d315e59899be8 3118 postfix-ldap-dbgsym_3.1.4-5_amd64.deb
cf567f1fcf90bad6e04d66864d2d72a6b2adc1a4 329672 postfix-ldap_3.1.4-5_amd64.deb
4501911338e2c756ee9200112615a0ac3a25378d 2754 postfix-lmdb-dbgsym_3.1.4-5_amd64.deb
cbca4055cd52ed2de94b07f7764d975fdd949906 317366 postfix-lmdb_3.1.4-5_amd64.deb
8a1fbccb1039c152be0fd9dc4944c738a7c27a12 2674 postfix-mysql-dbgsym_3.1.4-5_amd64.deb
0760a7ed5085fc785636b17919d719b993dcb43c 319124 postfix-mysql_3.1.4-5_amd64.deb
cd59ddcb5d4385c64ba3b69e2faf99f3bf200cec 2482 postfix-pcre-dbgsym_3.1.4-5_amd64.deb
e5866cb3f107561b1a42ec0213aab9ba73d12294 317656 postfix-pcre_3.1.4-5_amd64.deb
c8f0305b66750c8c61a1387a50930140ce9c925d 2640 postfix-pgsql-dbgsym_3.1.4-5_amd64.deb
ea2b8c1d876f50db9508f05094ba7e03ca30f98d 318770 postfix-pgsql_3.1.4-5_amd64.deb
03600707f5f1120cff5eaaec3cae1c7b8943e5fa 2460 postfix-sqlite-dbgsym_3.1.4-5_amd64.deb
bfd7f7d357c6696ee61003df3b147e57fbaef87a 316780 postfix-sqlite_3.1.4-5_amd64.deb
2d7a4eac15fbd8912a671b86b9e7c270b8f59c0a 10760 postfix_3.1.4-5_amd64.buildinfo
bc07ad33f412e0b89a987e1f270972a392e82dc8 1434078 postfix_3.1.4-5_amd64.deb
Checksums-Sha256:
006366779b4c15ab4289622654528ce19887d2cc4f799d0fe5646b49d3b78d46 2650 postfix_3.1.4-5.dsc
aef1ca97c732fda445c9d290fa7d20883459e6aabfb9d3c9baaae2d3cba26c24 191032 postfix_3.1.4-5.debian.tar.xz
54ff5ae81fab28b6480233ebe0e1a5feaf558627cc6607d9ce56e7e4e733fe22 2410 postfix-cdb-dbgsym_3.1.4-5_amd64.deb
ce2ee40d1f1979ffdaaa893f24c004b5209eae7004e59c54e5b7e112a19247f0 313132 postfix-cdb_3.1.4-5_amd64.deb
9623458405108c66ea54f60c8607ec8444c444f70446b32f72e16b1c03ad5532 97924 postfix-dbgsym_3.1.4-5_amd64.deb
31e30dfc9f216ac57a619f119019f16d1d08c2846d67f0c955a0cae4428b04b1 1173646 postfix-doc_3.1.4-5_all.deb
8f279aeaa302b8d644fe9f9cdbb6c0682bd0cdb4ecea0b41881a456ea30483d2 3118 postfix-ldap-dbgsym_3.1.4-5_amd64.deb
b41b3e331e287f5933d0ee03f6a776ec8c3ce5b73ee724171abc8b1340866ca1 329672 postfix-ldap_3.1.4-5_amd64.deb
03db94241062e2ebb81f6d397f52e66a9edb5d72e5da4200d86e24a1a4254cb8 2754 postfix-lmdb-dbgsym_3.1.4-5_amd64.deb
58dead05b308bf7b9249fd4edac66b5883596821e3eaa6d7379a99a543943db5 317366 postfix-lmdb_3.1.4-5_amd64.deb
882524f13074b3eb397c04aa837f191c4670df77f266d27b6f57cb64f563bffa 2674 postfix-mysql-dbgsym_3.1.4-5_amd64.deb
cbbc676a97f9bdb0e77e479af83ea9cff52f54f4c9829350634355f495f9829f 319124 postfix-mysql_3.1.4-5_amd64.deb
c245d97e9355e7bb3d092d6db96639afa4cbcf57ccbbc229115031052879801f 2482 postfix-pcre-dbgsym_3.1.4-5_amd64.deb
eda76c3b1ba3892f83c0f24ff0477538fe053821d41ec0f3ad3f9b796a8e9093 317656 postfix-pcre_3.1.4-5_amd64.deb
99e7f227829ccba58240795caee56c4fa142de1a1c746e6a11cab8f65579e13a 2640 postfix-pgsql-dbgsym_3.1.4-5_amd64.deb
ddffdeac796f6ac27d9831c139a9c146a76fb412ada2290336c787b0b2135eaa 318770 postfix-pgsql_3.1.4-5_amd64.deb
83b203fa5fccd8b1e47a4e701d0d1a9433c97639901771d6af9b293d1f338a84 2460 postfix-sqlite-dbgsym_3.1.4-5_amd64.deb
de93aa89e44090303de2a1c5712ff120a11179ddc4c416fe6a6ffaafd5d88e2e 316780 postfix-sqlite_3.1.4-5_amd64.deb
64dfe739fb32f642f17fe81fdc790dce7dd1d6adb2783f2c451f799eb80f0714 10760 postfix_3.1.4-5_amd64.buildinfo
4ba84841fedb275ffc81898c74acfc4b8c52b3fd4e9cd9b7281b943ef761312b 1434078 postfix_3.1.4-5_amd64.deb
Files:
5713d42d0b7099c074dd8bdb8206035a 2650 mail extra postfix_3.1.4-5.dsc
cad1ae3703d49c5d694cdee73c2ea0ef 191032 mail extra postfix_3.1.4-5.debian.tar.xz
06ce385ad3bd9feaebe8121ea8dc73b0 2410 debug extra postfix-cdb-dbgsym_3.1.4-5_amd64.deb
3731ff49b3aa8a087660293e1e0b0304 313132 mail extra postfix-cdb_3.1.4-5_amd64.deb
1a42aa3fa126e748565f3957f4512e2f 97924 debug extra postfix-dbgsym_3.1.4-5_amd64.deb
e106b50f4288cc62fda139d00688d07b 1173646 doc extra postfix-doc_3.1.4-5_all.deb
56d6ac84c172898e8e9c9302a1715b2a 3118 debug extra postfix-ldap-dbgsym_3.1.4-5_amd64.deb
6a8d1a1de67981949e9d5cbe407a2719 329672 mail extra postfix-ldap_3.1.4-5_amd64.deb
683d372902bef67dac418048e16271ed 2754 debug extra postfix-lmdb-dbgsym_3.1.4-5_amd64.deb
9dedb60bc4dda57209b19496462224ef 317366 mail extra postfix-lmdb_3.1.4-5_amd64.deb
6cae813f64385ca1b4921c1ea4465af4 2674 debug extra postfix-mysql-dbgsym_3.1.4-5_amd64.deb
356382ee9836e617cfe7ca1b364e2d94 319124 mail extra postfix-mysql_3.1.4-5_amd64.deb
291b739f3fb423315645843cb4385f55 2482 debug extra postfix-pcre-dbgsym_3.1.4-5_amd64.deb
f00a0529f8ff0dee47da083bd4863958 317656 mail extra postfix-pcre_3.1.4-5_amd64.deb
b78ec1f2072ceaffc0c8a68cf2a814c3 2640 debug extra postfix-pgsql-dbgsym_3.1.4-5_amd64.deb
5269c2c0cc1154c81e6463d93a4b6971 318770 mail extra postfix-pgsql_3.1.4-5_amd64.deb
fd5220637424de2497d547691c297f1b 2460 debug extra postfix-sqlite-dbgsym_3.1.4-5_amd64.deb
3ab0d35c896b03d356f7ae146ff3a762 316780 mail extra postfix-sqlite_3.1.4-5_amd64.deb
72919fde208d45ec3885632c2d8261c0 10760 mail extra postfix_3.1.4-5_amd64.buildinfo
014085af175989a9300e6a76a0286bf9 1434078 mail extra postfix_3.1.4-5_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJZGgycAAoJEHjX3vua1Zrx3zsP/2/ODZdLe2R0nNv9qJEUqL8s
MY/4kcpP1W2MifkDg0m8PMzhfntjJKGji/hQXz/5iUvEkT1iBMRUT78fzD544U5P
Zr74rmXHMiUGG/qBc15hHdSxhL0W/J2emFUiU01Z4ZDnW1zMCjUTs8bAshoRIlTB
Va21WobaLMV0joNpbRXJx9Fp2gDLBY5Pm1cOfP/4vj57oD+WpgeCqbFQy8rMt4+Q
zRiTMMkqd0qekSP9abqmF8SmViWdetyGUy2T6NGGl5s8UTsTDB2gIl+F0fU0EWZ7
hu2WXXqVEjM3bGTMw3U08Fv58krN5c7OhziBQw1f72Lz4ABYgvOElxAuO1DSl1cx
o/8fyT8wxIa4fPXta+TCPEgCBOsLxDyy2LwQbqAWodVwjT2VxRzeGR5AOJbf8s/m
XhDDFlh/BPERX9pUA0JQF9+MyGEOmGebNlIAFeyMulUtiYyeXZb3vxIW5OxWrtjV
Z3P8wxUEZhD0JVT8bNBF+T14HbLZa88GyZKW1H+eDpE/x0nZT4y034ou7JWMo4vs
7LCnQr2o1ZBRCzwB8nuns3eqeKvvVR8zm9KW/TCaQtXrjUzcq+9pRQZ9vUEnXvYE
8fvzjeGlQRI84mBrsMPNNz7mxBIYphVvrkU0CxrVqPMCBG6UhO1vOzVpTVayfz/c
r836sXbWFO9LXFYmLrR3
=aqkh
-----END PGP SIGNATURE-----
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Tue, 16 May 2017 05:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Steve Langasek <steve.langasek@canonical.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Tue, 16 May 2017 05:03:03 GMT) (full text, mbox, link).
Message #112 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Scott,
Adding the Debian bug on Cc:.
On Mon, May 15, 2017 at 10:12:41PM -0000, Scott Kitterman wrote:
> On Monday, May 15, 2017 08:49:42 PM you wrote:
> > On Mon, May 15, 2017 at 06:45:21PM -0000, Scott Kitterman wrote:
> > > I'm getting close to uploading a fix for this to Debian, so you might wait
> > > for that.
> > It looks like you've implemented this using the network-online.target
> > approach, which as you mentioned might not DTRT for the localhost-only use
> > case. Did you decide that this is negligible?
> That was the advice I got from the Debian systemd maintainers (that the impact
> would be negligible).
Ok, the analysis on the Debian bug looks rather shallow to me:
> - The penalty of pulling in network-online.target is simply that for the
> local case postfix is started a bit later then necessary during boot.
There's no reason that this *should* be true for an intermittently-online
machine. The network-online.target is specifically defined so that services
are not started until the network connection is actually up; or put another
way, if a system is booted and can't get a network connection, those
services are not started. We don't just start them at some random point,
that would defeat the purpose.
So the case I described is still not handled here - a postfix setup that has
no dependency on the network interface bring-up (for binding), such as the
default config, will nevertheless be blocked from starting until there is a
network, including in cases where this is much more than a mere startup
timing distinction.
Now, you can't have a single unit config that simultaneously meets Russell's
request from the original bug report, to defer startup until a given bind
address is available, and the case I describe above, where you care about
postfix running even when the network is not up. I would argue that the
case I outlined is more important to get right out of the box, since it
requires no changes to the default postfix config whereas Russell's use case
does. But it's your decision as maintainer which to support as the default;
I just won't SRU the network-online.target change into any Ubuntu stable
releases because it would introduce a regression.
> > For the case of a server which always has a network connection, this works
> > fine. For the case of a standalone system with no configured network
> > connection, it probably also works fine. But for the case of e.g. a laptop
> > that sometimes has network and sometimes doesn't, if the system comes up
> > without network, postfix will not start and you will not have local
> > delivery. Is this the behavior you expect with your change?
> I tested this and if you're using NetworkManager at least there's some magic
> that happens which causes systemd to restart postfix once the network is
> available. Part of the reason I was having so much trouble replicating
> problems others were seeing was getting NM to quit 'helping' as the test
> system I was using also has a desktop installed.
Do you really mean that it restarts postfix when the network is available,
or is it starting postfix for the first time? The expected behavior is that
postfix doesn't start at all until the network is up. This is managed via
/lib/systemd/system/NetworkManager-wait-online.service in both Ubuntu and
Debian.
(FWIW in the process of confirming this, I have identified a bug at least in
Ubuntu, related to LP: #1569649, whereby NetworkManager-wait-online is not
enabled on some systems that have been continuously upgraded from Ubuntu
pre-releases. I'm working on fixing this now.)
> > Ultimately I want to SRU this into affected stable Ubuntu releases, so would
> > want a regression-free change.
> >
> > I see you are also setting After=nss-lookup.target. For the bug reported
> > here - which is about DNS resolution specifically - would it not suffice to
> > have postfix declare this After=nss-lookup.target, and for systemd-resolved
> > to be sequenced before it?
> According to the Debian systemd people, the systemd-resolved is superfluous.
> It's nss-lookup.target that I wanted all along.
Well, in theory yes, but in practice I see nothing - including
systemd-resolved - that's wired up to this target in Debian or Ubuntu. The
nss-lookup target does nothing:
$ systemctl status nss-lookup.target
● nss-lookup.target - Host and Network Name Lookups
Loaded: loaded (/lib/systemd/system/nss-lookup.target; static; vendor preset:
Active: inactive (dead)
Docs: man:systemd.special(7)
$ journalctl -u nss-lookup.target
-- No entries --
$
Oh, if you happen to also install bind, then you get this target. But
that's not the common case.
So your current unit deps work *only* because you are also depending on
network-online.target, and resolvconf handling happens before
network-online. The After=nss-lookup.target is a complete no-op. I think
we should fix that so that it's *not* a no-op, but that means touching a few
more moving pieces.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, LaMont Jones <lamont@debian.org>:
Bug#854475; Package postfix.
(Tue, 16 May 2017 05:51:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Steve Langasek <steve.langasek@canonical.com>:
Extra info received and forwarded to list. Copy sent to LaMont Jones <lamont@debian.org>.
(Tue, 16 May 2017 05:51:03 GMT) (full text, mbox, link).
Message #117 received at 854475@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Mon, May 15, 2017 at 09:59:22PM -0700, Steve Langasek wrote:
> > - The penalty of pulling in network-online.target is simply that for the
> > local case postfix is started a bit later then necessary during boot.
> There's no reason that this *should* be true for an intermittently-online
> machine. The network-online.target is specifically defined so that services
> are not started until the network connection is actually up; or put another
> way, if a system is booted and can't get a network connection, those
> services are not started. We don't just start them at some random point,
> that would defeat the purpose.
So, I just noticed that NetworkManager-wait-online uses --timeout:
ExecStart=/usr/bin/nm-online -s -q --timeout=30
which means this delays services at most 30 seconds at boot.
And you can ignore my blather about this preventing services from running.
Sorry!
(I'm not convinced that having a timeout is actually sensible behavior, but,
well, it's what's implemented.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Wed, 14 Jun 2017 07:27:55 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Wed Jan 10 10:57:51 2018;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.