Hi,
I was affected by the same bug and found that resolvconf.service, while
loaded, was actually never run by systemd (jessie). Now I know nothing
about systemd and the bizarre maze of targets and services it comprises,
but it appeared to me that network.target might not be the ideal target
to use - it seemingly never triggers here. Maybe that's related to
NetworkManager (which stays absent from my system).
Trying to make sense of dns-clean.service as something that operates in the
same ballpark I came up with the following:
hopper:~# diff -u /lib/systemd/system/resolvconf.service
/etc/systemd/system/resolvconf.service
--- /lib/systemd/system/resolvconf.service 2014-05-08 13:58:57.000000000
+0200
+++ /etc/systemd/system/resolvconf.service 2014-06-01 10:05:04.181671200
+0200
@@ -2,6 +2,9 @@
Description=Nameserver information manager
Documentation=man:resolvconf(8)
DefaultDependencies=no
+Before=network-manager.service systemd-networkd.service networking.service
+After=local-fs.target
+Requires=local-fs.target
[Service]
RemainAfterExit=yes
@@ -11,4 +14,4 @@
ExecStop=/sbin/resolvconf --disable-updates
[Install]
-WantedBy=network.target
+WantedBy=multi-user.target
After a gracious "systemctl reenable resolvconf", the old symlinks were
gone, the new ones were present, resolvconf was now present in the
dependencies of multi-user.target and, after the next reboot, the local
resolver came back to life again.
Please be aware that this is not the recommended fix, I just monkey
patched the service file until it behaved. It may be all wrong and
the correct solution might have been to find out why network.target
was entirely ignored here (and elsewhere) and fix that. I'm running
a pure ifupdown environment (including wpa-roam) which is working
exactly as it should, for more than half a decade, and I'd like it
to stay that way in jessie and later. So consider that as a data
point in finding the proper systemd unit to mimick resolvconf's
behavior under all the possible sysv-init setups it used to work
with, but not the final solution.
As an aside: Are there setups where the current systemd service (as
of 1.75) does actually work? I expect it was tested, so what is special
on the systems where it did actually start? That information might
point towards the real fix.
Thanks & HTH,
Andre.
--
Cool .signatures are so 90s...
-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
