Comment # 34 on bug 1123699 from Reinhard Max

@James, I was rather thinking of putting nss-lookup.target as a synchronisation
point between wicked creating the resolv.conf file and dnsmasq consuming it,
but that might lead to a hen and egg problem, because dnsmasq itself might be
considered a service that has to be up before nss-lookup.target can be reached.

But I think I've found a different solution for the dnsmasq part of the
problem: It is not the lack of the resolv.conf file itself that causes dnsmasq
to fail on startup, it's the lack of the directory containing that file. So,
/etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf, but
/var/run/netconfig does not exist when dnsmasq is being started and so it has
no place to put an inotify on to get triggered when the resolv.conf file
appears.

So, if we manage to create /var/run/netconfig early enough in the boot process
(maybe through systemd's tmpfile mechanism) dnsmasq should start successfully
even if resolv.conf does not yet exist.

@Marius, other packages/subsystems are already using the tmpfiles mechanism to
create their respective subdirs under /run, so what would you think of also
adding this for /var/run/netconfig to either wicked or sysconfig and see if it
happens early enough for dnsmasq to succeed?

For a quick test without touching any packages:

echo "d /run/netconfig 0755 root root -" > /etc/tmpfiles.d/netconfig.conf

When packaging this the file should of course go to /usr/lib/tmpfiles.d/ rather
than /etc/tmpfiles.d/ .