lennart at poettering.net
Thu Jul 18 10:29:33 PDT 2013
On Thu, 18.07.13 21:11, Kai Hendry (hendry at iki.fi) wrote:
> On 18 July 2013 20:27, Lennart Poettering <lennart at poettering.net> wrote:
> > You need an After= here for the device, too.
> Thanks this fixes the first scenario: http://sprunge.us/LiQF
> I must say needing After & BindsTo is a bit confusing. I also don't
> see the need for different sections. Never quite know under which
> heading a stanza should go.
It is certainly surprising at first, but it makes a lot of sense. In
systemd ordering deps and requirement deps are truly orthogonal. This is
useful in many cases, because sometimes you just want to pull something
else in, but not imply any ordering, sometimes you want to order without
actually pulling it in, and often you want to do both. Of course, not
all deps make sense in all combinations, but I think it's easy enough to
> > The timestamp looks weird. Does the device have no RTC or so?
> no RTC, so does that mess up the retry interval code I wonder? Because
> I don't mind if systemd just retries it every so often. But that
> doesn't work. :/
All time-based logic in systemd uses CLOCK_MONOTONIC wherever that makes
sense, so we should be fairly safe on that.
> Not sure I like the suggestions here:
> I despise NetworkManager.
> Hasn't someone written a simple service that say pings 22.214.171.124 and if
> that's OK, says the network is up? That's how even "enterprise"
> routers work.
I figure you could try this with a service like the following (untested):
ExecStart=/usr/bin/ping -nq 126.96.36.199 -w 60 -c 1
Then, install and enable this service, and pull in network-online.target
from the service that you want to wait for the network to be around.
This will timeout after 60 seconds.
It's hacky, generates awful traffic, and has quite some latency, but it
should do what you asked for...
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel