Postfix cannot resolve DNS if network was unavailable when it was started, such as on a laptop

Bug #1519331 reported by Erik Auerswald on 2015-11-24
100
This bug affects 16 people
Affects Status Importance Assigned to Milestone
postfix (Debian)
Fix Released
Unknown
postfix (Ubuntu)
Low
Unassigned
Yakkety
High
Steve Langasek
Zesty
High
Steve Langasek

Bug Description

[SRU Justification]
Race condition between resolvconf and postfix on startup leaves postfix with a different DNS server configuration in its chroot than is used on the host system, which may cause it to experience DNS resolution errors.

[Test case]
1. Install postfix on a machine or container (not chroot) in the default configuration.
2. Run 'sudo mkdir -p /etc/systemd/system/systemd-resolved.service.d ; echo -e '[Service]\nExecStartPre=/bin/sleep 20' | sudo tee /etc/systemd/system/systemd-resolved.service.d/lp1519331.conf'
3. Reboot
4. Confirm that /etc/resolv.conf and /var/spool/postfix/etc/resolv.conf differ.
5. Install postfix from -proposed
6. Reboot
7. Confirm that /etc/resolv.conf and /var/spool/postfix/etc/resolv.conf match.
8 Run 'sudo rm -f /etc/systemd/system/systemd-resolved.service.d/lp1519331.conf && sudo rmdir -p /etc/systemd/system/systemd-resolved.service.d'

[Regression potential]
Because we are changing the order of service initialization at boot, if there are other packages which have undeclared dependencies on postfix (or generically, on a running SMTP server), these services may now fail a race with postfix startup where they succeeded before. This is highly unlikely, as a hard dependency on an SMTP service is unusual.

Because the postfix service will now depend on network-online.target, if the system fails to reach this target postfix will not start, which would be a serious regression. Analysis shows that network-online.target should always be reached at boot, regardless of whether using ifupdown, network-manager, or networkd, and the only difference is that postfix startup will be delayed a short while until the network is fully configured.

[Original report]
Every now and then postfix installed on my laptop stops delivering mails. I detect this problem after wandering about no answers to my emails, or by checking the current mail queue, which should be empty when I am at the office.

I use postfix to deliver all sent mail to the company SMTP server. The local postfix does not receive outside mail.

The mail queue shows errors of the type:

(Host or domain name not found. Name service error for name=XXXXXXXX type=AAAA: Host not found, try again)

When I manually check host name resolution, it works fine. It seems, postfix either does not retry name resolution, or somehow name resolution fails for postfix, but not other programs. Network connectivity is fine when this problem occurs (I read my mail via IMAP w/o local message body cache from the same server used as smart host, use SSH to other hosts, and surf the web -- I never noticed network problems when the postfix mail delivery did not work).

To remedy the situation I can just restart postfix and flush the mail queue. But I need to detect the problem, and postfix should™ recover on its own.

I am using IPv6 privacy extensions (Ubuntu default) in a dual stack IPv4 and IPv6 network. Both local (company) and remote servers are accessible via IPv6, thus I am actively using IPv6 for many connections. I have no idea if this is related to the problem, but the error shows a failure to resolve a quad A record.

Mandatory information:
1)
$ lsb_release -rd
Description: Ubuntu 14.04.3 LTS
Release: 14.04

2)
$ apt-cache policy postfix
postfix:
  Installed: 2.11.0-1ubuntu1
  Candidate: 2.11.0-1ubuntu1
  Version table:
 *** 2.11.0-1ubuntu1 0
        500 http://ftp.uni-kl.de/pub/linux/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.11.0-1 0
        500 http://ftp.uni-kl.de/pub/linux/ubuntu/ trusty/main amd64 Packages

3)
I expected postfix to deliver the queued mail. If there was a (temporary, perhaps very short) network problem, postfix should recover automatically after the problem was resolved.

4)
Postfix stopped delivering mails.

Erik Auerswald (auerswal) wrote :

I might have found the reason for this behaviour:

1) Without network connectivity, the file /etc/resolv.conf does not contain any useful information (just two comment lines).

2) After establishing network connectivity, the file /etc/resolv.conf contains 127.0.1.1 and a correct search path as received via DHCP.

3) Postfix copies the file /etc/resolv.conf to /var/spool/postfix/etc/resolv.conf upon startup. If postfix is started before the network is up, this file will not allow name resolution. Every other application uses /etc/resolv.conf and works fine.

Perhaps Network-Manager could restart postfix upon connection-up events? Can this be configured?

Erik Auerswald (auerswal) wrote :

In light of the above the bug seems to be cause by interaction of the packages postfix, resolvconf, and network-manager by using postfix on a portable desktop machine as opposed to a server with static network configuration.

Since I am using mutt as mail client, I need a local MTA. Postfix seemed a valid choice, especially with the simple configuration using a smart host for all mail delivery. But it seems desktop GNU/Linux does not support this classic setup any more. :-(

Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Importance -> Low since this doesn't affect the primary use of Postfix as a server MTA, but only with network-manager on a desktop machine.

FWIW, I use msmtp. I can't queue mails when offline, but otherwise it works fine for me.

It might be worth checking what the situation is on Debian for this use case. There may be a valid bug in Debian as well, and it would be better to follow what Debian do in this case I think.

summary: - Mail delivery fails until restarting postfix
+ Postfix cannot resolve DNS if network was unavailable when it was
+ started, such as on a laptop
Changed in postfix (Ubuntu):
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in postfix (Ubuntu):
status: New → Confirmed
Marius Gedminas (mgedmin) wrote :

Curiously, I never saw this problem on my laptop in Ubuntu versions up to and including 16.04 LTS. I'm seeing a lot of this problem ever since I upgraded to 16.10 LTS.

Scott Kitterman (kitterman) wrote :

In the postfix service file (/lib/systemd/system/postfix.service), if you change:

After=network.target

to:

Requires=network-online.target
After=network-online.target

does that solve your problem?

Note: this is not a general solution as it breaks setups that only interface with localhost.

Marius Gedminas (mgedmin) wrote :

I'm currently testing the following workaround:

    --- /usr/lib/postfix/configure-instance.sh.orig 2016-11-14 09:24:03.832342133 +0200
    +++ /usr/lib/postfix/configure-instance.sh 2016-11-14 09:19:20.336826008 +0200
    @@ -120,6 +120,8 @@
          if [ -f /${file} ]; then rm -f ${file} && cp /${file} ${file}; fi
          if [ -f ${file} ]; then chmod a+rX ${file}; fi
      done
    + # an empty resolv.conf is useless -- ubuntu bug LP: #1519331
    + grep -q nameserver etc/resolv.conf || echo nameserver 127.0.1.1 >> etc/resolv.conf
      # ldaps needs this. debian bug 572841
      (echo /dev/random; echo /dev/urandom) | cpio -pdL --quiet . 2>/dev/null || true
      rm -f usr/lib/zoneinfo/localtime

It seems to work for me.

Robie Basak (racb) on 2016-11-28
tags: added: needs-upstream-report
Scott Kitterman (kitterman) wrote :

This is about how we integrate postfix and networking in Debian (and thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-report tag.

tags: removed: needs-upstream-report
Erik Auerswald (auerswal) wrote :

I like the solution proposed in message #7. :-)

Robie Basak (racb) wrote :

> This is about how we integrate postfix and networking in Debian (and thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-report tag.

By "upstream", I meant Debian. I'm not aware of a separate bug tag for that. What should I be using instead of needs-upstream-report when it needs to go to the Debian BTS?

On Monday, December 19, 2016 08:58:24 AM you wrote:
> > This is about how we integrate postfix and networking in Debian (and
>
> thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-
> report tag.
>
> By "upstream", I meant Debian. I'm not aware of a separate bug tag for
> that. What should I be using instead of needs-upstream-report when it
> needs to go to the Debian BTS?

In this particular case, at least one of the Debian postfix maintainers reads
Ubuntu bugs, so it's not needed.

pataluna (pantaluna) wrote :

>@Marius Gedminas (mgedmin)
>Curiously, I never saw this problem on my laptop in Ubuntu versions
>up to and including 16.04 LTS.
>I'm seeing a lot of this problem ever since I upgraded to 16.10 LTS.

I experienced the same issues when deploying Ubuntu 16.10 to a new MiniPC (opposed to Ubuntu 14.x that worked fine).

I have finally found an automated solution for this: enable the NetworkManager-wait-online.service and deploy a custom script that restarts the postfix service +-5 minutes after the machine has booted (assuming that the wireless connection is active by then).

A. Enable this.
It is a generic approach that might be beneficial for other service than Postfix as well so I keep it in the script.
````
systemctl enable NetworkManager-wait-online.service; systemctl status NetworkManager-wait-online.service;
````

B. Add a customer Systemd timer + service
@info The timer will start ONCE, {x} minutes after the machine was booted.
````
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.timer
    [Unit]
    Description=(timer)mjd-restart-postfix-after-wlan-connected
    [Timer]
    OnBootSec=5min
    [Install]
    WantedBy=timers.target
````
````
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.service
    [Unit]
    Description=mjd-restart-postfix-after-wlan-connected
    [Service]
    Type=oneshot
    ExecStart=/bin/sh -ec "systemctl restart postfix; systemctl status postfix; uname -a | /usr/bin/mailx -s \"Server (`hostname`): postfix was restarted.\" <email address hidden>"
````

````
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl enable ${MYTIMER}; systemctl status ${MYTIMER};
systemctl list-units --all | grep "${MYUNIT}"
systemctl status ${MYUNIT}
````

C. Restart
````reboot
````# wait 5 minutes

D. Check
````
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl status ${MYTIMER}
````

If the contents of these 2 config files (one of Resolve and one of Postfix) are not the same then the issue is PROBLEMATIC (Postfix started before LAN/WLAN gets connected).
cat /etc/resolv.conf
cat /var/spool/postfix/etc/resolv.conf

E. Info
@doc https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331
@doc https://wiki.archlinux.org/index.php/Systemd/Timers
@doc qshape deferred
@doc cat /var/log/syslog | egrep "NetworkManager|postfix"

Scott Kitterman (kitterman) wrote :

It would be nice if someone who is having this problem could test 3.1.4-2 or later on Zesty to see if the problem is fixed (I think it is).

Which package was updated to fix this problem in Zesty? I could try to upgrade it only (I'm not ready to upgrade the whole distro).

Scott Kitterman (kitterman) wrote :

On Monday, January 30, 2017 09:33:36 PM you wrote:
> Which package was updated to fix this problem in Zesty? I could try to
> upgrade it only (I'm not ready to upgrade the whole distro).

postfix

Mark C Davis (davismc) wrote :

Just tried this with Zesty and Postfix 3.1.4-4. I have ipv4 dhcp, ipv6 static and resolv.conf. After reboot /var/spool/postfix/etc/resolv.conf did not have any addresses in it.

In case it helps other people, here is the workaround I use, in /etc/rc.local:
=============================
while ! grep -q nameserver /etc/resolv.conf
do
  sleep 30
done
cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
/etc/init.d/postfix restart
=============================

Ross Patterson (rossp) wrote :

FWIW, I tried a bunch of different combinations of After, BindsTo, PartOf, and ReloadPropagatedFrom in /lib/systemd/system/postfix.service and none of them addressed the issue.

Ross Patterson (rossp) wrote :

The only workaround I could get to work was to restart postifx on network up by adding `/etc/network/if-up.d/999local` with the following contents:

```
#!/bin/sh -e
# Called when a new interface comes up
# Local workarounds

# Fix postfix boot up issue:
# https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331
service postfix restart >/dev/null 2>&1
```

Erik Auerswald (auerswal) wrote :

As I see it, the only reliable methods found to date are described in message #7 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/7), message #17 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/17), and message #19 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/19).

I like the idea of using a standard resolv.conf unless a more specific one is found on Postfix startup, as proposed in #7, but that is a hack and might lead to problems for "non-standard" DNS configurations, or changes in the Ubuntu way of configuring DNS.

A _reliable_ way of restarting on every change of /etc/resolv.conf to pick up the change would be the "right thing to do." AFAIU that should be done by placing a script in /etc/resolveconf/updated.d/. That script could possibly look just like that from message #19. I am going to try something like that, perhaps it works. I hope resolvconf still exists in the systemd world...

Thanks,
Erik

Erik Auerswald (auerswal) wrote :

I am using the following script saved as /etc/resolvconf/update.d/postfix:

```
#! /bin/sh

# restart Postfix whenever resolv.conf changes, because Postfix creates
# a local copy of the file for use from inside its chroot

/usr/sbin/service postfix restart

```

That works reliably when changing network connectivity, e.g. going from cabled Ethernet to WLAN or vice versa. It does not always work during boot.

I use Ubuntu 14.04 LTS (and I do not dare to update my work notebook to 16.04 LTS, because it needs to actually work...).

Bill Duetschler (bikergeek) wrote :

Can confirm that this bug exists on Zesty. It occurs on my desktop machine which has network available at boot time via cabled ethernet.

Eugene Crosser (crosser) wrote :

I experience this on Zesty, on an always-on machine, that however relies on DHCP for network configuration.

I would argue that this is an upstream bug, or if you want a design flaw.

It is perfectly normal for resolv.conf to change at arbitrary moments. Examples are VPN and alternative redundant connectivity for a host. It seems wrong for a server to rely on a static snapshot of network configuration, because that configuration may change with time.

hambling (hambling) wrote :

Had the same problem before Zesty and used some of the fixes described here to have postfix restart through rc.local file after waiting a few minutes. The bug is still persistent for me after upgrading to Zesty. What does fix it for me though is adding the "After" line to the Unit: /lib/systemd/system/postfix@.service

After=network-online.target

Note: it did not work to make this change to the postfix.service unit.

gil (gilbert-laycock) wrote :

Another confirmation that this bug is still present in Zesty, and that the solution in #24 has worked fine for me so far.

pdecat (pdecat) wrote :

Same issue here on zesty, empty /var/spool/postfix/etc/resolv.conf after reboot.

Applying solution from #24 works it around:

```
# printf "[Unit]\nAfter=network-online.target\n" | sudo SYSTEMD_EDITOR=tee systemctl edit postfix@-.service
```

Current working configuration:

```
# systemctl cat postfix@-.service
# /lib/systemd/system/postfix@.service
[Unit]
Description=Postfix Mail Transport Agent (instance %i)
Documentation=man:postfix(1)
PartOf=postfix.service
ReloadPropagatedFrom=postfix.service

[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/usr/lib/postfix/configure-instance.sh %i
ExecStart=/usr/sbin/postmulti -i %i -p start
ExecStop=/usr/sbin/postmulti -i %i -p stop
ExecReload=/usr/sbin/postmulti -i %i -p reload

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/postfix@-.service.d/override.conf
[Unit]
After=network-online.target
```

Steve Langasek (vorlon) wrote :

I am seeing this issue on Ubuntu 17.04.

/var/spool/postfix/etc/resolv.conf is pointing at 192.168.122.1, which is the IP of my libvirt bridge - this is a result of dnsmasq interfacing with resolvconf, so that the host system can resolve local hostnames of guests on the bridge.

It's fine that 192.168.122.1 is listed (aside from the part where I've killed the dnsmasq there for unrelated reasons), but this differs from the host resolv.conf, which points to 127.0.0.53 first. We should *always* be pointing to 127.0.0.53 (systemd-resolved) on Ubuntu 16.10 and later. The fact that we aren't means postfix is racing systemd-resolved at boot.

I think it should be a sufficient fix for this bug, on 16.10 and later, to have /lib/systemd/system/postfix.service declare After=systemd-resolved.service.

Scott Kitterman (kitterman) wrote :

I'm getting close to uploading a fix for this to Debian, so you might wait for
that.

Steve Langasek (vorlon) 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?

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?

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?

--
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/
<email address hidden> <email address hidden>

Scott Kitterman (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).

> 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.

> 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.

There's a very helpful (at least for me) discussion in the last few entries in
the Debian bug. Reviewing that would be better advice than I have for what's
safe/not as I cribbed from Michael Biebl's suggestions after just enough
research to be able to convince myself I wasn't cargo culting.

Scott K

Steve Langasek (vorlon) wrote :
Download full text (5.2 KiB)

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 a...

Read more...

Steve Langasek (vorlon) wrote :

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/
<email address hidden> <email address hidden>

Erik Auerswald (auerswal) wrote :

Hi,

I see two problems to solve to enable using Postfix on laptops with changing network connectivity:

1. Copy a working /etc/resolve.conf on initial Postfix start-up
2. Adjust Postfix's copy of /etc/resolv.conf in /var/spool/postfix/etc/resolv.conf

Part 1 seems to be tackled with waiting for networking to come up. A static default using 127.0.1.1 as DNS server might work as well, at least for Ubuntu 14.04 LTS.

Part 2 can be solved similar to my comment #21, i.e. restarting Postfix whenever the system resolv.conf changes by using the appropriate infrastructure for this. Just copying the new file to the change root might suffice and might be nicer.

My use case is well described by by Steve Langasek as "intermittently online" machine. I want Postfix to store e-mails if there is no network connectivity, and send them out, when network connectivity is available.

Back in the day this just worked. There was a static /etc/resolv.conf and Postfix used the system resolv.conf file. Later enhancements made /etc/resolv.conf dynamic and Postfix moved to a change root with a local copy of an /etc/resolv.conf snapshot. Those two changes do not work together correctly.

BTW, the current status on 14.04 LTS is that Postfix often copies /etc/resolv.conf before this file is created correctly. Disabling and then enabling the network (e.g. unplug cable, wait for NetworkManager to notice, plug cable back in) resolves the issue iff a hook in /etc/resolvconf/update.d/ picks up the change and updates Postfix. I use the simple, but heavy-weight script described in comment #21 for this.

Thanks,
Erik

Erik Auerswald (auerswal) wrote :

I have just added something to the file /etc/resolvconf/resolv.conf.d/base to try to have a useful /etc/resolv.conf all the time:

```
# workaround for broken interactions with Postfix:
# fall back to the local name server 127.0.1.1
nameserver 127.0.1.1
```

Let's see how this plays out...

Thanks,
Erik

Erik Auerswald (auerswal) wrote :

Adding the local recursive name server to /etc/resolvconf/resolv.conf.d/base (see comment #34) solved the problem of having an unusable /etc/resolv.conf at the time postfix copies it during boot. Together with restarting postfix whenever /etc/resov.conf changes solves my problems.

I would be happy to see a solution that works as well as my manual fixes added to the postfix and resolv.conf packages.

Thanks,
Erik

Steve Langasek (vorlon) wrote :

Marking this high; racing /etc/resolv.conf setup at boot is not just a desktop issue.

Changed in postfix (Ubuntu):
status: Confirmed → Fix Released
Changed in postfix (Ubuntu Yakkety):
importance: Undecided → High
Changed in postfix (Ubuntu Zesty):
importance: Undecided → High
Changed in postfix (Ubuntu Yakkety):
assignee: nobody → Steve Langasek (vorlon)
Changed in postfix (Ubuntu Zesty):
assignee: nobody → Steve Langasek (vorlon)
Changed in postfix (Ubuntu Yakkety):
status: New → Triaged
Changed in postfix (Ubuntu Zesty):
status: New → Triaged
Changed in postfix (Debian):
status: Unknown → Fix Released
Steve Langasek (vorlon) on 2017-06-03
description: updated
Steve Langasek (vorlon) on 2017-06-03
Changed in postfix (Ubuntu Yakkety):
status: Triaged → In Progress
Changed in postfix (Ubuntu Zesty):
status: Triaged → In Progress

Hello Erik, or anyone else affected,

Accepted postfix into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.1.4-4ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postfix (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-zesty
Changed in postfix (Ubuntu Yakkety):
status: In Progress → Fix Committed
tags: added: verification-needed-yakkety
Andy Whitcroft (apw) wrote :

Hello Erik, or anyone else affected,

Accepted postfix into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.1.0-5ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-yakkety to verification-done-yakkety. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-yakkety. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

pdecat (pdecat) wrote :

Proposed package installed on zesty, workaround removed (/etc/systemd/system/postfix@-.service.d/override.conf) and rebooted.

So far so good :)

I've installed the proposed the package (on zesty), removed my workaround in /etc/rc.local, rebooted and it seems to work. Thanks!

Steve Langasek (vorlon) wrote :

Ran through the full test case on zesty and confirmed that this works as expected.

tags: added: verification-done-zesty
removed: verification-needed-zesty
Steve Langasek (vorlon) wrote :

Test case confirmed also on yakkety.

tags: added: verification-done-yakkety
removed: verification-needed-yakkety
tags: removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postfix - 3.1.0-5ubuntu1

---------------
postfix (3.1.0-5ubuntu1) yakkety; urgency=medium

  * Use correct service dependencies in postfix@.service, to avoid racing
    systemd-resolved at boot. LP: #1519331.

 -- Steve Langasek <email address hidden> Sat, 03 Jun 2017 13:00:35 -0700

Changed in postfix (Ubuntu Yakkety):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for postfix has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Aaron Peromsik (aperomsik) wrote :

Anything in particular holding the release of this fix for Zesty?

Łukasz Zemczak (sil2100) wrote :

The reason for it not being released for zesty before was that it seemed to have 3 undefined autopkgtest failures for sbuild. After looking into those now, it seems that the sbuild autopkgtests seem to be constantly failing for those 3 archs for all packages - so, (most likely) unrelated to the postfix upload. I would say that's enough for me to get it released.

On it now.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postfix - 3.1.4-4ubuntu1

---------------
postfix (3.1.4-4ubuntu1) zesty; urgency=medium

  * Use correct service dependencies in postfix@.service, to avoid racing
    systemd-resolved at boot. LP: #1519331.

 -- Steve Langasek <email address hidden> Sat, 03 Jun 2017 00:35:57 -0700

Changed in postfix (Ubuntu Zesty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.