The start-stop-demon example given should not include the --quiet option and is quite basic. Here is something with more meat. Both --exec and --pidfile should be used in --start and --stop for system robustness. If the daemon does not create a pidfile then use --make-pidfile if possible (test if it works), otherwise don't use pidfiles. Here are some examples start() { start-stop-daemon --start --exec /path/to/daemon \ --pidfile /path/to/pidfile } stop() { start-stop-daemon --stop --exec /path/to/daemon \ --pidfile /path/to/pidfile } NOTE: Don't use the --quiet option unless the daemon is uncontrollably chatty. Use of it may hinder debugging the reason why the daemon did not start. WARNING: Ensure that --exec actually calls a daemon and not just a shell script that launches daemon(s) and then exits - that is what the init script is supposed todo.
Might also be an idea to say something like this If the daemon needs to write to local disks, then it should need localmount and if it puts anything in /var/run such as a pidfile then it should after bootmisc depend() { need localmount after bootmisc }
Created attachment 96227 [details, diff] hb-working-rcscripts.xml.patch Here's what is hopefully a nice patch as you requested. I took the liberty of rearranging things into a better flow (more readable and logical) as well as adding ebegin & eend to the stop() example. UberLord, what do you think? Is this acceptable?
Looks good. You may also want to note that if you're calling a script (bash, perl, python) that becomes a demon and changes it's name to "foo" then you may need to use --name foo in the s-s-d line too. See bug #143951 for why.
(In reply to comment #3) > Looks good. > > You may also want to note that if you're calling a script (bash, perl, python) > that becomes a demon and changes it's name to "foo" then you may need to use > --name foo in the s-s-d line too. See bug #143951 for why. > I'm working on this, which I will attach in just a bit, but I'm not sure that this should be documented -- it seems a little out of place; maybe unnecessary even for "power" users? After all, you did just mention "ensure that --exec actually calls a daemon and not just a shell script that launches daemon(s) and then exits" -- surely this is what calling a python script (for example) does, in which case, maybe it really should be in the user's bashrc, rather than using Gentoo's s-s-d framework. I don't see how you could avoid this improper bevahior in your script if you actually write a service that launches that script.
Created attachment 96255 [details, diff] hb-working-rcscripts.xml.patch + calling external scripts
(In reply to comment #4) > (In reply to comment #3) > > Looks good. > > > > You may also want to note that if you're calling a script (bash, perl, python) > > that becomes a demon and changes it's name to "foo" then you may need to use > > --name foo in the s-s-d line too. See bug #143951 for why. > > > > I'm working on this, which I will attach in just a bit, but I'm not sure that > this should be documented -- it seems a little out of place; maybe unnecessary > even for "power" users? > > After all, you did just mention "ensure that --exec actually calls a daemon and > not just a shell script that launches daemon(s) and then exits" -- surely this > is what calling a python script (for example) does, in which case, maybe it > really should be in the user's bashrc, rather than using Gentoo's s-s-d > framework. I don't see how you could avoid this improper bevahior in your > script if you actually write a service that launches that script. Ah, but in this instance the script IS the daemon, so we're OK. I was talking about scripts that are NOT daemons themselves. BTW, your new patch looks good
Fixed in CVS. Thanks for taking the time to go over this, UberLord. :)
