Re: networking.service: start operation timed out [SOLVED]

[Ross Boylan <rossboylan@stanfordalumni.org>]

The bind9 script I created in /etc/resolvconf/update.d executed
      systemctl reload named
near the end (if systemd is active, which it is for me).  Adding set
-x to the script showed that this was where the process of bringing up
the interfaces hung up.

named is obviously not active when the network is coming up; I thought
it would just fail.  But, probably because named.service says
After=network.service (network, not networking, but I assume they are
related), it blocks.  The solution was to test first:
    systemctl -q is-active named.service && systemctl reload named >
/dev/null 2>&1 || :
The stuff after the reload command was there all along.

Tracing this back the chain, because the script blocks the resolvconf
-a invocation in /etc/network/if-up.d/000resolvconf,  that was the
last script showing on my earlier posts.  resolvconf -a is only
invoked if there was some dns information in the interface stanza,
which is why removing dns- lines from ethlan allowed the network to
come up, and why bringing up ethworld automatically failed.

Now everything just works.

Thanks again to everyone.

There are probably some general lessons, though I'm not sure what they
are.  Clearly the systemd semantics tripped me up; it's kind of an odd
beast.  I understand one of its major goals was to allow startup to
proceed in parallel, which is pretty asynchronous.  But it has to
assure that certain things happen in a certain order, which results in
some things being synchronous and blocking.  I'm surprised that a tool
intended for use from the command line (systemctl) is blocking.

Ross