[Resolvconf-devel] Bug#749405: resolvconf: /etc/resolvconf/run/interface either does not exist or is not a directory

Beck, Andre beck at ibh.de
Sun Jun 1 14:24:33 UTC 2014


Package: resolvconf
Version: 1.75
Followup-For: Bug #749405

On Sun, Jun 01, 2014 at 10:59:00AM +0100, Edward Allcutt wrote:
> 
> Dear Maintainer,
> 
> I generally concur with Andre, with one exception.
> 
> I believe the WantedBy line should reference networking.service as that
> will be pulled in on any normal Debian system (whereas network.target is
> only pulled in in some configurations).

I did consider that, but when looking at the current structure of Wants
and WantedBys, it seemed to me that the intention of the design is to
have it ordered arount targets. They provide the well-known sequence
points in the boot order graph, and thus I chose multi-user.target
(as this choice seemed to be ubiquitous, as with dns-clean.service).

Pondering this a bit more, I've changed my copy in /etc/systemd/system
to now read

WantedBy=sysinit.target

as this is reflecting better where Debian has placed networking and
resolvconf traditionally - in rcS.d. According to systemd-analyze plot
it hasn't changed anything (and given I requested it to be executed
"Before=[...] networking.service" this is exactly what was expected),
it just feels more correct.

Again, I don't know anything about systemd nor about the intentions
of the Debian systemd maintainers when it comes to how targets,
services and other units should be named, aligned and ordered exactly
on our distro of choice. So the Maintainer should probably poll them
for their opinion prior to pushing a fix.

Regarding network.target that really seems to be a bad idea, as
pointed out by the documentation referred to by that unit

 http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

which states that it is considered an empty target to be filled out by
the local admin with their choice of a "the network is available"
kind of sequence point, mostly to order certain services after that.
It isn't even implemented by default, so clearly that is why it wasn't
triggering resolvconf to start.

HTH,
Andre.
-- 
                    Cool .signatures are so 90s...

-> Andre Beck    +++ ABP-RIPE +++      IBH IT-Service GmbH, Dresden <-



More information about the Resolvconf-devel mailing list