My primary dns lookup server is installed locally (djb's dnscache) and is managed by svscan. The problem is that other apps fired up at boot time (ntp, spamd, ...) rely on dns queries but are started before svscan ... thus they fail staring. Maybe starting svscan right after network interfaces are up ad running could be a solution?
Please submit to whoever maintains, or have actually commited most to the package.
daemontools-0.76-r2 has been added to portage with an updated svscan which is a "feeble" :) attempt at getting the script to start earlier. Optimally the script should be starting immediately after net... but i am not sure if we can accomplish this through depend()... some other ordering has to be possible. But for now, please check it out and let me know if it helps out in it's current state of more strict startup. The ebuild is marked unstable as the updated svscan needs much more testing.
I believe that svscan *should* be started before net. svscan is a general facility for starting long-running programs. There is no requirement that any networking be involved. For example, I've got a laptop that sometimes doesn't have any (external) networking, and in those cases, the init system fails to start net.eth0, so it won't start svscan, and thus won't start things that run under svscan. qmail-send is something that can work just fine if the ethernet is down (doing local deliveries). If dependencies are needed for service foo, then touch /service/foo/down so that it svscan doesn't start it automatically and create an init script for foo and set dependencies there. portmap is another program that shouldn't need net in it's init script. portmap works just fine running on the loopback and is used by things like fam, which is used by nautilus, which itself does not require a network connection.
mr robbat, you might want to check this one out as well... i'm not sure how to pursue this one any further... it seems like too much of a kludge right now.
starting svscan after networking is not reasonable. I've got plenty of cases where I have stuff in svscan (monitoring usually), that I want started as soon as possible on boot (before networking). I'm tempted to have a radically different approach here. svscan comes up, with NOTHING running by default (eg everything is 'down'). then there are init.d scripts that tell it to bring items up (and checks a few moments later to ensure they are up properly) or take them down again. this however adds a layer of complexity over svscan that I am not sure is warrented. on the plus side however, it allows you to use the depend/after/use/before stuff in our init scripts for each svscan service seperately, which would solve your problem. opinions?
I like your idea but I'd simplify it a little bit: I'd start svscan as soon as possible (before net), but I would not take any steps to ensure that the services start in the down state. Also include an init script with appropriate dependencies for each service that simply does svc -u /service/foo /service/foo/log for each service foo. Now the admin has two options: a) Let the service start automatically when svscan starts (default, I would do this for almost everything) b) Start/stop using the init script system, i.e.: # touch /service/foo/down # service starts in the down state # rc-update add foo default # init system starts service/puts in up state Even if the service is added to the runlevel without creating the down file, the service start with init won't hurt anything if the service is already running: svc -u only tells supervise to bring the service up if it is not running. Effectively the init script is a no-op. Or you could use svstat to see if it is already running.
Any thoughts on this? It's been six months since the last comment.
i haven't had time to do anything with it, i've been too busy with other things. if you've got free time and want to code up a generic solution like i mentioned with your modifications. make it a switch in the /etc/conf.d/svscan file to control that behavior between the two options. so two parts to write: - modifications to svscan init.d - generic init.d script for a svscan service (that can be modified per-service)
Created attachment 45911 [details] generic svc script /etc/init.d/svc Here is a generic script for controlling svscan services via the runscript system, if you want to do that sort of thing. For any given service, make a symbolic link to this script with the correct name. For example: # cd /etc/init.d # ln -s svc qmail-send # rc-update add qmail-send default depends() calls svc_depends(), which should be defined in /etc/conf.d/${SVC}. For qmail-send, a suitable function would be: svc_depends() { need net after net } Finally, to ensure that svscan does not automatically start the service when it starts up: # touch /service/qmail-send/down This causes it to start it in the "down" state. In my local version of /etc/init.d/svscan, depends() is simply "before net". I don't think most services that run under svscan really need an init script, but it does have the advantage of making all the services consistent. One thing that could be done as a policy is create all services with the down file so that they are not automatically started by svscan, and then add the individual services to runlevels using rc-update. (I am not recommending this, just pointing it out.) Note that the attached script uses svc -d and not -dx as in the svscan script, since -x would cause supervise to exit, and it would then be immediately respawned by svscan.
rather than a function, depend() does support variables. so in /etc/conf.d/$SVC svc_need="net" svc_after="net" ... (for all possible variables) then in the init.d depend() { after svscan ${svc_after} need svcan ${svc_need} }
Yeah, I was just noticing that the rebuilding the dependency cache didn't go so well with using the function. Otherwise, what do you think?
the concept is good. I'm wondering if we can hack something up like net.* so we can just have a bunch of symlinks to a single script.
Yes, this is what I did in my example. You should be able to make them all (qmail-send, qmail-smtpd, tinydns, etc.) symlinks once the dependencies are moved into /etc/conf.d/${SVC}
What's the status here?
*** Bug 93309 has been marked as a duplicate of this bug. ***
Hmmm....
(In reply to comment #16) > Hmmm.... Yeah, hmmm. I think between attachment #45911 [details] and comment #10, all the pieces are here for a single script that you use as a symlink base for all the services you want to manually start but still manage with daemontools. The two scenarios are: 1) Start service automatically when svscan starts: Do nothing, that's what we have now. 2) Start services as required by dependencies: # touch /service/${SVC}/down # cd /etc/init.d # ln -s svc ${SVC} # svc is attachment #45911 [details] + comment #10 suggestions # cd /etc/conf.d # echo "svc_need net ..." >>${SVC} # as per comment #10 # rc-update add ${SVC} default Since /service/${SVC}/down exists, svscan will still start a supervise process for the service, but it will be in the down state and not running the service. The init script will then bring the service up or down as requested.
Is this bug still relevant? Just trying to see what old bugs can be cleared. :)
(In reply to comment #18) > Is this bug still relevant? Just trying to see what old bugs can be cleared. :) Apparently not :)
