You are not logged in.
Hello everyone,
I'm setting up an environment and have a number of server daemons that I would like to automate the startup of, so I'd like to write some rc.d scripts for them. Now, I could just go ahead and roll my own but I thought I should try to learn the correct way of doing this.
I have already read the wiki page (https://wiki.archlinux.org/index.php/Wr … .d_scripts) and have used the example there as a starting point, I have a working script that starts a daemon. However I have some questions...
How do I handle the case where the daemon's name differs from the running process? Once case I have is to start up a web server for ruby documentation. The process I need to start is "gem server" but what is listed in ps is "ruby ... gem server". Starting works just fine, but when trying to stop it the rc.d script uses "pidof gem" to locate the daemon which fails because there is no such process (it's ruby) so stopping the daemon fails.
My second query is how to handle multiple daemons that differ only in their arguments. I don't think the rc.d script can handle this. I would like to run several of these "gem servers" for different trees of development.
I may be better off in this case just writing my own thing to do it.
Any help and advice appreciated...
Offline
locate the daemon
They're supposed to write a pidfile in /var/run, or actually /run is the bleeding-edge (i.e. Arch) location.
I may be better off in this case just writing my own thing to do it.
That's what I recommend - having it *work*, for you, is the most important thing. It's also a good learning experience.
Offline
They're supposed to write a pidfile in /var/run, or actually /run is the bleeding-edge (i.e. Arch) location.
The files in /run/daemons are empty files with the name of the daemon (e.g /run/daemons/sshd). They are empty (0 byte) files so don't contain the pid. Should I be looking somewhere else for other files ?
Offline
Yeah, look elsewhere.
find / -name \*.pid
Edit: an example:
PIDFILE=/var/run/named/named.pid
It's in a subdirectory, so that the user that BIND runs at, has permission to create and remove the pidfile from that directory.
One thing to bear in mind, when stopping a daemon, is that it might not stop immediately. E.g. lighttpd, when asked to do an orderly shutdown with:
kill -TERM $(pidof -s /usr/sbin/lighttpd) 2>/dev/null
Cannot be immediately checked in the initscript. My erm, workaround for that is to just assume that it got the message
Last edited by brebs (2012-03-07 13:49:17)
Offline
Well I've written a script and it works for me. http://pastebin.com/m5RNS4Ex
What I didn't bother with is writing pid files to /run or /var/run. I don't know if it matters that I don't do that. I think the only thing is I can't 100% guarantee that the processes I stop are the ones I start, but I'm making the assumption that I won't be starting exactly the same daemons with exactly the same arguments outside of this script. It works for me
Offline
restart)
$0 stop
sleep 1
$0 start
That's doomed to be unreliable. No guarantee that 1 second is sufficient to stop - depends whether e.g. the hard drive is already busy syncing.
Rather than unreliable code, I would prefer a "stop and then start yerself" kinda message.
Offline
That was copied directly from the wiki page I referred to in my original post and that I used as a starting point. I agree with you it isn't perfect but it works fine for me and I am unlikely to just "restart" anyway. I must say I 99% of the time use "start" followed by "stop" by default because not all scripts provide a "restart" option. Cheers.
Offline
Have you considered using systemd instead of initscripts? IMHO systemd service files are easier to create and read than rc.d scripts By default, they are very consistent across different daemons and platforms.
Last edited by Da_Coynul (2012-03-22 11:25:17)
Offline
If the Arch way of doing init scripts changes then I'll go with the flow but I don't really want to deviate from what the core Arch configuration does as that is set up and well tested by lots of people
Offline