[systemd-devel] /etc/systemd/system/darkice.service

Colin Guthrie 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
> 8.8.8.8 && exit; sleep 1; done; exit 1'
> http://sprunge.us/KbUZ
> 
> 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
editing too.

Also as the previous enable would have written the .wants symlink, ti's
probably work doing a "rm -f
/etc/systemd/system/network-online.target.wants/pingtest.service" to
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
one...)


> 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:
> http://ix.io/6Ql
> 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?)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/



More information about the systemd-devel mailing list