http://bugzilla.opensuse.org/show_bug.cgi?id=1123699 http://bugzilla.opensuse.org/show_bug.cgi?id=1123699#c34 Reinhard Max <max@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mt@suse.com) --- Comment #34 from Reinhard Max <max@suse.com> --- @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/ . -- You are receiving this mail because: You are on the CC list for the bug.