[Resolvconf-devel] Bug#700846: Service file

Cameron Norman camerontnorman at gmail.com
Sun May 4 21:24:38 UTC 2014

On Sun, May 4, 2014 at 9:16 AM, Martin Pitt <mpitt at debian.org> wrote:
> Hey Cameron,
> Cameron Norman [2014-05-04  8:19 -0700]:
>> What were the specific complaints? I noticed the Upstart job for
>> resolvconf has quite a strange start on event, "mounted
>> MOUNTPOINT=/run". Correct me if I am wrong, but I believe this blocks
>> mountall from mounting anything else until resolvconf has started,
>> since mounted is a hook event.
> I don't think it does. For that the job had to add a condition to
> start before mounting something else (and I don't think that even
> exists in upstart).

Yes, it looks like it does, from man:mounted(7):

  mountall(8) will wait for all services started by this event to be
running, all tasks started by this event to have finished and all jobs
  stopped by this event to be stopped before emitting any other events
related to this filesystem or continuing with other filesystems
  depending on this one.

/run is part of virtual-filesystems and both local-filesystems and
remote-filesystems are always emitted after that, and filesystem is
emitted after those. udev is also started after virtual-filesystems.
Therefore, resolvconf is started before network-interface, networking,
and pretty much everything else on Upstart systems. The point taken
from this is that the issues you are hitting may be because resolvconf
needs to start before more than just network-manager, and it does so
(accidentally) on Upstart systems.

> This is mostly there to ensure that it can
> actually write anything into /run. It's not necessary to translate
> this to the systemd unit as /run is mounted before systemd runs any
> unit.

I understand why it was put there, but its placement has unintended
consequences. Some of those consequences may explain why you are
hitting issues with the systemd service that you never had with the
Upstart job. I can not know that, though, because I do not know the
issues you have been told about the resolvconf service.

Cameron Norman

More information about the Resolvconf-devel mailing list