Re: [systemd-devel] /etc/systemd/system/darkice.service
On 25 July 2013 17:37, Colin Guthrie gm...@colin.guthr.ie wrote: These targets are effectively static synchronisation points. The problem here is that you're trying to map a very dynamic concept (networks coming and going) to a static one (targets being reached). Well I'm happy just with coming. ;) I expecting network-online.target to depend on pingtest.service. pingtest.service exits 0 and network-online.target is then triggered reached. Hope this explains it to you a little. Thanks for taking the time to explain Colin. I do agree daemons need to handle this it sucks darkice doesn't. So I need a hack without going the NetworkManager-wait-online.service route. ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 26 July 2013 04:17, Lennart Poettering lenn...@poettering.net wrote: We generally generate warnings about invalid lines and proceed. Aftre we parsed everything we then do a couple of checks whether a unit still makes sense with the stuff that was correctly parsed, and only if the unit does't pass that check we will fail it. I managed to see a foobar.service lacks ExecStart setting. Refusing. if I put ExecStart under [Unit] but if I do something like put Description under [Service] I don't get a warning. Maybe it's just me that finds it hard to know which stanzas belong under which heading. Is there a Unit validator? Does it work if you run it from the command line? Oh I figured it out http://lists.freedesktop.org/archives/systemd-devel/2013-July/012250.html They usually use exponentially increasing intervals, to avoid flooding. Despite what's said here on http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I do think it might be handy if there was a simple (systemd provided) API to know whether we're online or not (in the 8.8.8.8 sense). Thanks for your help. I think I got where I wanted to with pingtest.service. However the naming of my USB mic issue as mentioned at the bottom of http://lists.freedesktop.org/archives/systemd-devel/2013-July/012292.html is still an issue for me. Darkice daemon assumes network and the hw:1,0 (as defined in my /etc/darkice.cfg) device else it bombs out. Can systemd instead perhaps check for hw:1,0 instead for the crazy long device name that changes depending on what port is plugged into? Thanks again, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
Am 28.07.2013 11:06, schrieb Kai Hendry: On 26 July 2013 04:17, Lennart Poettering lenn...@poettering.net wrote: We generally generate warnings about invalid lines and proceed. Aftre we parsed everything we then do a couple of checks whether a unit still makes sense with the stuff that was correctly parsed, and only if the unit does't pass that check we will fail it. I managed to see a foobar.service lacks ExecStart setting. Refusing. if I put ExecStart under [Unit] but if I do something like put Description under [Service] I don't get a warning. Maybe it's just me that finds it hard to know which stanzas belong under which heading man systemd.unit man systemd.service look at a existing unit /usr/lib/systemd/system/avahi-daemon.service as example _ [Unit] Description=Avahi mDNS/DNS-SD Stack Requires=avahi-daemon.socket [Service] Type=dbus BusName=org.freedesktop.Avahi ExecStart=/usr/sbin/avahi-daemon -s ExecReload=/usr/sbin/avahi-daemon -r NotifyAccess=main [Install] WantedBy=multi-user.target Also=avahi-daemon.socket Alias=dbus-org.freedesktop.Avahi.service signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
'Twas brillig, and Kai Hendry at 25/07/13 06:22 did gyre and gimble: Going back to the timeout, I started the PI without a network. Waited a minute or two. Then I started pingtest.service manually. I was surprised that network-online.target doesn't turn active. I had to manually start it. http://ix.io/6RD These targets are effectively static synchronisation points. The problem here is that you're trying to map a very dynamic concept (networks coming and going) to a static one (targets being reached). You could turn such a thing into something more dynamic by writing a deamon which actively monitors the network status and starts/stop the network-online.target accordingly. Service units could then Requires network online and be automatically stopped when it was stopped. But this creates a lot more problems. Units would have to be changed to have WantedBy=network-online.target (as opposed to the more common multi-user.target) and to also have a Requires=network-online.target as mentioned above. This seems like it might be good at first, but the problem is you lose all state information. If you stop several enabled services manually (and deliberately) then at some point later the network has a blip and the target is stopped (stopping all services that require it) but then comes back again, then *all* enabled services will be started again, including the ones manually stopped by the administrator. There are several other problems that arises here too. Such as the definition of what network up actually is. Different daemons work on different definitions and thus we'd have to have a whole bunch of targets with fine-grained names to capture all the combinations and have monitoring daemons for each. Then there are some services that only care about one interface working, not the whole network so you need targets and monitors for that too. Some daemons only want a local network and not a public internet so you add another factor to the combinations with that too. Before long (and long before this point) it becomes obvious the whole things is just totally unmanageable like this. Really the network-online.target is just a hack. It represents a best effort point in time that was also provided (equally badly) by previous init systems. The only *real* way to fix this problem is for the daemons themselves to properly deal with networks coming and going. Only the daemons with their config files can know what is important to them, which interfaces matter, whether an external network is needed or whether this is a purely local one etc. etc. The services themselves need to behave properly in a dynamic environment and not assume it's static. See the What does this mean for me, a Developer? section on this page which basically says exactly this: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Hope this explains it to you a little. 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Mon, 22.07.13 17:48, Kai Hendry (hen...@iki.fi) wrote: On 19 July 2013 01:29, Lennart Poettering lenn...@poettering.net wrote: 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 grasp. What happens in the range of error cases when a user puts a Wants= line under the (wrong) [Install] heading? We generally generate warnings about invalid lines and proceed. Aftre we parsed everything we then do a couple of checks whether a unit still makes sense with the stuff that was correctly parsed, and only if the unit does't pass that check we will fail it. I tried it and network-online.target was loaded inactive dead, so it failed IIUC. No warning that Wants= line is in the wrong place. This sucks quite a lot imo. loaded inactive dead does not indicate any error, just that the thing didn't get started. I enabled the above as pingtest.service and added Wants=network-online.target under the [Unit] heading in darkice.service. Still I don't understand how pingtest.service can fail here with exit 2 and even more confusingly network-online.target is reached!? http://ix.io/6Nv Does it work if you run it from the command line? WantedBy= means that a unit is pulled in but it is not relevant whether it succeed to reach a target. There's also RequiredBy= which is the stronger option where that does matter. Generally, for robustness reasons we suggest people to use WantedBy rather than RequiredBy, but it's up to you. This will timeout after 60 seconds. Isn't this better controlled by systemd itself? And not be a command line switch in the exec? We currently don't support Timeouts on type=oneshot services, but we should fix it. It's hacky, generates awful traffic, and has quite some latency, but it should do what you asked for... Awful traffic? One successful ping and we continue IIUC. Well, you still bombard the local network if the internet connection is sewered far away... This doesn't really scale to more than a few sysem. A lot of routers IIUC do a heart beat type ping to ensure it's up. And if not it would switch to another route or something. If routers are doing this, why can't my device? Is it really that expensive?? They usually use exponentially increasing intervals, to avoid flooding. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 22 July 2013 23:56, Andrey Borzenkov arvidj...@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. :/ 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? Kind regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
'Twas brillig, and Kai Hendry at 24/07/13 08:10 did gyre and gimble: On 22 July 2013 23:56, Andrey Borzenkov arvidj...@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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
В Wed, 24 Jul 2013 15:10:01 +0800 Kai Hendry hen...@iki.fi пишет: On 22 July 2013 23:56, Andrey Borzenkov arvidj...@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. :/ Do you really want all your services that depend on network being up to fail if your AP is busy and needs 61 seconds to establish connection? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 25 July 2013 00:56, Andrey Borzenkov arvidj...@gmail.com wrote: Do you really want all your services that depend on network being up to fail if your AP is busy and needs 61 seconds to establish connection? Firstly I use a PI with a wired connection with netctl ifplugd. I don't know if there is a sane replacement for ifplugd / network hotplug, but anyway it takes alarmingly about 10secs to get an IP. http://ix.io/6RA There should be only *one* darkice.service, that depends on network-online.target atm. Though if you take a look at http://ix.io/6Rz you can see `systemctl show -p Requires network-online.target` does not work for some reason. I was expecting it to say darkice.service. I probably just don't understand how dependencies work in systemd. Nightmare. Without being pedantic, I would be happy to make pingtest.service run continually until it gets the first taste of the Internet. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 24 July 2013 20:26, Colin Guthrie gm...@colin.guthr.ie wrote: 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...) Ah, that was the problem. I had to disable and enable it again to have my s,Wants,Requires, change to work. Crikey, systemd has some gotchas. Putting stanzas under wrong headings and this sucked hours from my life. 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?) I would prefer to rely on the `systemctl -t device --all --full | grep net`. It's a bit sad I can use a wildcard, or some logical OR statement in BindsTo IIUC=. I find /etc/udev/rules.d a bit gnarly to say the least! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 25 July 2013 12:55, Kai Hendry hen...@iki.fi wrote: Though if you take a look at http://ix.io/6Rz you can see `systemctl show -p Requires network-online.target` does not work for some reason. I was expecting it to say darkice.service. I probably just don't understand how dependencies work in systemd. Nightmare. Oh the problem here as Colin earlier pointed out is that I had to disable and `systemctl enable pingtest.service` for the requires symlnk to properly written. Going back to the timeout, I started the PI without a network. Waited a minute or two. Then I started pingtest.service manually. I was surprised that network-online.target doesn't turn active. I had to manually start it. http://ix.io/6RD ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 19 July 2013 01:29, Lennart Poettering lenn...@poettering.net wrote: 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 grasp. What happens in the range of error cases when a user puts a Wants= line under the (wrong) [Install] heading? I tried it and network-online.target was loaded inactive dead, so it failed IIUC. No warning that Wants= line is in the wrong place. This sucks quite a lot imo. Wouldn't it be simpler if systemd ignored the headings? Anyway, it's just a comment. I am still trying to figure darkice starting out. I figure you could try this with a service like the following (untested): [Unit] Before=network-online.target [Service] ExecStart=/usr/bin/ping -nq 8.8.8.8 -w 60 -c 1 Type=oneshot StandardOutput=null [Install] WantedBy=network-online.target 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. I enabled the above as pingtest.service and added Wants=network-online.target under the [Unit] heading in darkice.service. Still I don't understand how pingtest.service can fail here with exit 2 and even more confusingly network-online.target is reached!? http://ix.io/6Nv This will timeout after 60 seconds. Isn't this better controlled by systemd itself? And not be a command line switch in the exec? It's hacky, generates awful traffic, and has quite some latency, but it should do what you asked for... Awful traffic? One successful ping and we continue IIUC. A lot of routers IIUC do a heart beat type ping to ensure it's up. And if not it would switch to another route or something. If routers are doing this, why can't my device? Is it really that expensive?? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
В Mon, 22 Jul 2013 17:48:11 +0800 Kai Hendry hen...@iki.fi пишет: I enabled the above as pingtest.service and added Wants=network-online.target under the [Unit] heading in darkice.service. Still I don't understand how pingtest.service can fail here with exit 2 and even more confusingly network-online.target is reached!? 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. http://ix.io/6Nv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /etc/systemd/system/darkice.service
Hi guys, http://sprunge.us/SLSF is the service file I have currently. I'm running http://archlinuxarm.org/ on a Rpi with systemd 204-3. I'm having issues creating a service file for darkice a audio streamer that depends on: * a network connection * a microphone sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device First scenario, microphone unplugged: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 2013-07-18 17:49:41 SGT; 5min ago Process: 279 ExecStart=/usr/bin/darkice (code=exited, status=255) Jul 18 17:49:41 pihsg systemd[1]: Started DarkIce audio forwarder. Jul 18 17:49:41 pihsg darkice[279]: DarkIce 1.1 live audio streamer, http://code.google.com/p/darkice/ Jul 18 17:49:41 pihsg systemd[1]: darkice.service: main process exited, code=exited, status=255/n/a Jul 18 17:49:41 pihsg systemd[1]: Unit darkice.service entered failed state. I expected systemd to deny the start with sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device loaded inactive dead sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago Process: 121 ExecStart=/usr/bin/darkice (code=exited, status=255) journalctl -b | grep -i dark reveals DarkIce: TcpSocket.cpp:226: gethostbyname error [0] So the network wasn't ready even when depending on nss-lookup.target. I did try tweaking restart interval settings to 20, but that didn't help either. Any tips? The network is brought up by netctl-ifplugd@eth0.service Many thanks, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: Hi guys, http://sprunge.us/SLSF is the service file I have currently. I'm running http://archlinuxarm.org/ on a Rpi with systemd 204-3. I'm having issues creating a service file for darkice a audio streamer that depends on: * a network connection * a microphone sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device First scenario, microphone unplugged: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 2013-07-18 17:49:41 SGT; 5min ago Process: 279 ExecStart=/usr/bin/darkice (code=exited, status=255) Jul 18 17:49:41 pihsg systemd[1]: Started DarkIce audio forwarder. Jul 18 17:49:41 pihsg darkice[279]: DarkIce 1.1 live audio streamer, http://code.google.com/p/darkice/ Jul 18 17:49:41 pihsg systemd[1]: darkice.service: main process exited, code=exited, status=255/n/a Jul 18 17:49:41 pihsg systemd[1]: Unit darkice.service entered failed state. I expected systemd to deny the start with sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device loaded inactive dead sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2:1.0-sound-card1.device You need an After= here for the device, too. Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? Process: 121 ExecStart=/usr/bin/darkice (code=exited, status=255) journalctl -b | grep -i dark reveals DarkIce: TcpSocket.cpp:226: gethostbyname error [0] So the network wasn't ready even when depending on nss-lookup.target. I did try tweaking restart interval settings to 20, but that didn't help either. Any tips? The network is brought up by netctl-ifplugd@eth0.service See: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? Yeah, the RPi does not have an RTC. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, Jul 18, 2013 at 02:27:09PM +0200, Lennart Poettering wrote: On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: Second scenario, microphone plugged in: [root@pihsg ~]# systemctl status darkice.service darkice.service - DarkIce audio forwarder Loaded: loaded (/etc/systemd/system/darkice.service; enabled) Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08 SGT; 43 years 6 months ago The timestamp looks weird. Does the device have no RTC or so? RPis have no RTC. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On 18 July 2013 20:27, Lennart Poettering lenn...@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. 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. :/ Not sure I like the suggestions here: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I despise NetworkManager. Hasn't someone written a simple service that say pings 8.8.8.8 and if that's OK, says the network is up? That's how even enterprise routers work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, 18.07.13 14:34, Tom Gundersen (t...@jklm.no) wrote:
On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote:
[root@pihsg ~]# systemctl status darkice.service
darkice.service - DarkIce audio forwarder
Loaded: loaded (/etc/systemd/system/darkice.service; enabled)
Active: failed (Result: exit-code) since Thu 1970-01-01 07:30:08
SGT; 43 years 6 months ago
The timestamp looks weird. Does the device have no RTC or so?
Yeah, the RPi does not have an RTC.
Which reminds me that people suggested we should maybe add a simple
logic to systemd that during shutdown we should invoke
utimensat(clock_gettime(CLOCK_REALTIME)) on some file in /var/, and
during boot-up we should set the realtime clock from that if it is set
to a date earlier than that or so... That way time will monotonically
increase even across reboots, and even without network around, which is
useful in particular during boot up, and not constantly restart from
1970 again on each boot. For machines that are more often on than off
the accuracy might be good enough so that NTP never has to resort to
making the time jump abruptly.
If somebody wants to work on this: this should probably take inspiration
from the random seed service which is started after /var is up and
stopped before /var goes down. I figure embedded devices are the most
likely to use a split off /var (because of read-only /), so this
ordering is a must to ensure that we check for the file at the right
time.
In the cases where /var is not split off it might be a good idea to
apply the jump even earlier, from PID1 before the first unit is forked
off, so that userspace outside of PID 1 *never* has to see weird 1970
dates. Hence it would be a good choice to do the threshold-based RTC
jump logic twice: once in PID 1 in some code like
src/core/{hostname,loopback,machine-id,mount}-setup.c and once in that
random-seed-like unit that runs after /var is found. The threshold logic
should make sure we do not make the time jump twice. And of course if
the file is not found then this should not cause an error but should be
silently ignored.
A nice side effect of this is that even on systems which have an RTC
we'd always correct them at least to the date the OS image you run was
created at.
The stuff of course should be compile-time optional.
If somebody wants to work on this, I'd be happy to take the patch. If
figure this should be 50 lines or so.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/systemd/system/darkice.service
On Thu, 18.07.13 21:11, Kai Hendry (hen...@iki.fi) wrote: On 18 July 2013 20:27, Lennart Poettering lenn...@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 grasp. 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: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ I despise NetworkManager. Hasn't someone written a simple service that say pings 8.8.8.8 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): [Unit] Before=network-online.target [Service] ExecStart=/usr/bin/ping -nq 8.8.8.8 -w 60 -c 1 Type=oneshot StandardOutput=null [Install] WantedBy=network-online.target 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 -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
