gmane at colin.guthr.ie
Wed Jul 24 05:26:03 PDT 2013
'Twas brillig, and Kai Hendry at 24/07/13 08:10 did gyre and gimble:
> On 22 July 2013 23:56, Andrey Borzenkov <arvidjaar at gmail.com> wrote:
>> network-online.target has no requirement for pingtest.service. All that
>> this configuration does is delaying network-online.target by at most 60
>> seconds, that's all. If network is not up at this point - too bad.
> That ping switch Lennart proposed, -w 60 or -W 60 doesn't actually
> wait if there is no network.
> So I've ended up with a shell script:
> ExecStart=/usr/bin/bash -c 'for i in `seq 60`; do ping -c 1 -nq
> 22.214.171.124 && exit; sleep 1; done; exit 1'
> Which seems to work, however I can't seem to make
> network-online.target depend on pingtest.service with
> `RequiredBy=network-online.target` in the pingtest.service file. So
> even if pingtest fails, network-online.target ends up being active. :/
I've not really played much with RequiredBy= stuff for targets (mostly
use WantedBy) so not sure if this is something that is misbehaving.
That said, the [Install] section is completely inactive unless you run
systemctl enable/disable etc. So I guess one question would be: have you
done that after editing the unit? You will also likely need to run
"systemctl --system daemon-reload" to make it reread the unit file after
Also as the previous enable would have written the .wants symlink, ti's
probably work doing a "rm -f
ensure it's cleaned out properly (in theory it shouldn't do any harm,
but perhaps an existing symlink here is somehow overriding the requires
> With the darkice service file, I ended up with http://sprunge.us/VXRU
> Restart=on-failure was needed since sometimes it would fail to start.
> No idea why. I can't confirm it was restarted in that cases since
> `systemctl status darkice.service` doesn't tell me this.
> Another problem is that if someone manages to connect the USB
> microphone in the wrong USB port, it fails to start:
> Not sure how to wildcard bind the USB GO Mic here. Any tips?
So this smells like something you should trigger via a udev rule
instead. Certainly the starting of it (you can specify SYSTEMD_UNIT= to
make it start a unit on hotplug).
Not sure how you'd handle the killing of it (unless the SYSTEMD_UNIT
property magically stops it too?)
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the systemd-devel