I don't think there's been sufficient analysis of the root cause here to start changing start conditions on any of the standard jobs.
/etc/init/resolvconf.conf is:
start on mounted MOUNTPOINT=/run
and /etc/init/udev.conf is:
start on virtual-filesystems
The 'mounted' event is a hook, not a signal; mountall will not continue processing mounts, or emit any other signals, until all jobs depending on 'mounted' have finished.
This means that the resolvconf job is *guaranteed* to create the /run/resolvconf/interface directory before udev is started. And until udev is started, there should be no 'net-device-added' events, so no instances of /etc/init/network-interface.conf.
So something else is going on here. I don't see any bugs in resolvconf.
I don't think there's been sufficient analysis of the root cause here to start changing start conditions on any of the standard jobs.
/etc/init/ resolvconf. conf is:
start on mounted MOUNTPOINT=/run
and /etc/init/udev.conf is:
start on virtual-filesystems
The 'mounted' event is a hook, not a signal; mountall will not continue processing mounts, or emit any other signals, until all jobs depending on 'mounted' have finished.
This means that the resolvconf job is *guaranteed* to create the /run/resolvconf /interface directory before udev is started. And until udev is started, there should be no 'net-device-added' events, so no instances of /etc/init/ network- interface. conf.
So something else is going on here. I don't see any bugs in resolvconf.