[18:12] <KjetilK> I got a bit further with my problem yesterday, but I could use a hand in translating this init.d-script to an upstart job: http://dolot.kipdola.com/wiki/Install_SASC-NG#Init_script (BTW, if anyone is in doubt, what I'm doing is legal here)
[18:18] <KjetilK> there is the runsasc script, which I suppose I could just exec
[18:19] <KjetilK> (the runsasc script is elsewhere on the same page)
[18:21] <KjetilK> there is a lot of additional complexity in there though, with timeouts and stuff, that is quite magical to me, and also I don't know if its needed under upstart, and also if there are better ways to deal with the insertion of the dvbloopback kernel module
[18:24] <ion> Is the module related to hardware? If yes, udev should autoload it. If not, it could be loaded with modprobe in a pre-start script.
[18:25] <ion> Something like this should work for starters:
[18:25] <ion> exec runsasc  # no forking here
[18:25] <ion> post-start script
[18:26] <ion>   until [ -e /tmp/SASC_COMPLETE ] ...
[18:26] <ion>   (if timeout occurred) exit 1
[18:26] <ion> end script
[18:27] <ion> Based on that, Upstart should handle the stopping when needed.
[18:27] <ion> Remember to rm -f /tmp/SASC_COMPLETE in pre-start script.
[18:27] <KjetilK> ion, ok, nice!
[18:29] <KjetilK> the module is only loosely related to hardware, in that it sets up a loopback device for a video stream that comes from hardware
[18:29] <KjetilK> so, I guess pre-start is better
[18:30] <KjetilK> hmmm, loading the driver is a large part of what runsasc does
[18:30] <KjetilK> perhaps I should try to do everything in the upstart job
[18:32] <KjetilK> hmmm, or perhaps not...
[18:40] <ion> Instead of the polling for the file, it might be better to use e.g. inotify. Incidentally, i wrote <http://github.com/ion1/wait-for-file> a couple of years ago, but that doesn’t support a timeout. OTOH, is the timeout really necessary?
[18:40] <ion> If runsasc fails, won’t it just return with a non-zero exit value?
[18:47] <KjetilK> I have no idea why they are using the timeout, this is too magic for me...
[18:47] <KjetilK> hmmm, it seems runsasc kills itself if it fails...
[18:49] <KjetilK> hmmm, perhaps I should try to write a minimal upstart job first, not looking too much at what runsasc does
[18:49] <KjetilK> and if that doesn't work, go from there...
[18:56] <KjetilK> runsasc has a lot of sleeps, is that a workaround for not having a proper event-based startup system?
[18:56] <KjetilK> i.e., something that could be done better with upstart?
[19:05] <ion> If it does any amount of preparation and then finally execs a single, independent server, there’s no need to split it. If it runs two independent services, it would be a good idea to create two jobs.
[19:06] <KjetilK> AFAICS, it just inserts a module, then starts a single daemon
[19:07] <KjetilK> but it seems to sit around and wait for things to come up
[19:07] <KjetilK> looks like those who wrote this had some problems they solved by doing this, but I don't know...
[19:08] <KjetilK> anyway, bbiab, gotta put the kid to bed :-)
[23:42]  * cwillu_at_work drops a hint about how he'd like to be able to run scripts as a user via "user <foo>" :p