systemd - standard place to run stuff after the network is up?

Dan Williams dcbw at
Thu Oct 20 18:08:19 UTC 2011

On Thu, 2011-10-20 at 07:46 -0400, Matthew Miller wrote:
> On Mon, Oct 17, 2011 at 07:10:04PM +0200, Lennart Poettering wrote:
> > In general doing something like this is a bit backwards since networks
> > come and go and come and go in todays world, and we also don't want to
> This seems like a very desktop-focused view of things. I appreciate that
> that's important, but please keep the server room in mind as well. In our
> environment, the network is like electricity -- if it's down, nothing is
> running. Having the software designed to be robust against unexpected
> network glitches is very useful, but if design decisions are constantly made
> with the assumption that networks are a random transient resource, we'll end
> up conceding our place in the data center in exchange for an incredibly tiny
> slice of the desktop pie.

If you architect a system that accounts for networking changing states,
then it works for *everyone*.  If you depend on networking always being
there, then it only works for some subset of users that have one type of
installation.  Having one architecture and one codebase (that handles
both cases) generally means easier maintenance, feature addition, and
fewer bugs.

It's certainly  not a desktop view of things; many desktops stay on a
desk and are always connected to a network.  It's more a view that tries
to account for more use-cases than static networking scripts ever did.
But that doesn't mean it compromises the always-connected-never-moving
case either.


More information about the devel mailing list