* runsv and runsvdir problems @ 2008-10-27 17:12 Ciprian Dorin Craciun 2008-10-27 17:30 ` Alex Efros 0 siblings, 1 reply; 3+ messages in thread From: Ciprian Dorin Craciun @ 2008-10-27 17:12 UTC (permalink / raw) To: supervision Hello all! First of all I must say I like the runit suite very much, and for about half a year I use it to manage almost all my services (normal ones and personal ones) on my laptop. Usually it runs smoothly, without any big problems, with a few exceptions: * first of all I use runsvdir for all the system services (like udev, getty, etc.); * also I allow each user (my self for now) to have a special service that runs another runsvdir; * as my services I use anything, from the X server and client, bittorent client, to the music player; Something like -- runsvdir /services \-- runsv /services/udev \-- runsv /services/getty-1 ... \-- runsv -> runsvdir /services/ciprian \-- runsv x \-- runsv vpn \-- ... But there are a couple of problems with this setup (so I propose some feature requests): * first of all a lot of services are not started by default (by using the 'down' file), but this doesn't stop runsv to start the logger => could there be an option to start the loggers only when the server actually starts? * if I send HUP to runsvdir /services it sends TERM to runsv /services/ciprian, which in turn sends TERM to runsvdir /services/ciprian which breaks, and leaves all my services dangling... => could there be an option to actually pass the same signal down the chain? (for example if I send TERM to runsv or runsvdir, it should send TERM downpath, and so for any other signal, for example USR1, etc.) * if I want to stop the runsvdir /services it sends the signal to all its children, but exists immediatly, and this is a problem if I stop it from an rc.0 or 6 script, because it should wait for all the children to actually stop; for now it leaves them dangling, and the unmounting of the file systems breaks... => could there be an option to actually make runsvdir to wait for it's children? * if a process takes to long to terminate (when it receives TERM signal), it would be nice for runsv to actually send KILL, but this should be configurable, as I wouldn't like to have runsv kill runsvdir like this; * (a small annoyance) it would be nice to be able to combine runsv and runsvdir into a single command, as this would reduce the number of runsv processes, until I actually need to start a service; So I repeat that runit suite is a very good one, but I would be very happy to see these problems solved. Thanks all, and keep up the good work, Ciprian Dorin Craciun. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: runsv and runsvdir problems 2008-10-27 17:12 runsv and runsvdir problems Ciprian Dorin Craciun @ 2008-10-27 17:30 ` Alex Efros 2008-10-27 18:03 ` Ciprian Dorin Craciun 0 siblings, 1 reply; 3+ messages in thread From: Alex Efros @ 2008-10-27 17:30 UTC (permalink / raw) To: supervision Hi! On Mon, Oct 27, 2008 at 07:12:21PM +0200, Ciprian Dorin Craciun wrote: > * first of all a lot of services are not started by default (by > using the 'down' file), but this doesn't stop runsv to start the > logger => could there be an option to start the loggers only when the > server actually starts? why starting these loggers bother you? they doesn't hurt anything > * if I send HUP to runsvdir /services it sends TERM to runsv > /services/ciprian, which in turn sends TERM to runsvdir > /services/ciprian which breaks, and leaves all my services dangling... > => could there be an option to actually pass the same signal down the > chain? (for example if I send TERM to runsv or runsvdir, it should > send TERM downpath, and so for any other signal, for example USR1, > etc.) you can configure this behaviour - check CUSTOMIZE CONTROL in runsv(8) > * if I want to stop the runsvdir /services it sends the signal to > all its children, but exists immediatly, and this is a problem if I > stop it from an rc.0 or 6 script, because it should wait for all the > children to actually stop; for now it leaves them dangling, and the > unmounting of the file systems breaks... => could there be an option > to actually make runsvdir to wait for it's children? > > * if a process takes to long to terminate (when it receives TERM > signal), it would be nice for runsv to actually send KILL, but this > should be configurable, as I wouldn't like to have runsv kill runsvdir > like this; I usually do this: # Give a chance for all processes for clean exit. # This also will kill all 'runsvdir' and signal all 'runsv' to exit. killall5 -15 # ... some other de-initialization like hwclock --systohc sv force-stop /var/service/* &>/dev/null || : # ... more things to do while services stopping - save sound mixer # state, remember last random, shutdown network interfaces, etc. # Goodbye to everybody... killall5 -9 # unmount and reboot > * (a small annoyance) it would be nice to be able to combine runsv > and runsvdir into a single command, as this would reduce the number of > runsv processes, until I actually need to start a service; why starting these processes bother you? they doesn't hurt anything too really, having small annoyance each time you do `ps` and see a lot of small processes which do nothing useful except keeping all your system services running in reliable way - is fairly acceptable. and you always know how to run all your services in less reliable way with standard /etc/rc.d/* scripts to avoid this annoyance -- WBR, Alex. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: runsv and runsvdir problems 2008-10-27 17:30 ` Alex Efros @ 2008-10-27 18:03 ` Ciprian Dorin Craciun 0 siblings, 0 replies; 3+ messages in thread From: Ciprian Dorin Craciun @ 2008-10-27 18:03 UTC (permalink / raw) To: supervision On Mon, Oct 27, 2008 at 7:30 PM, Alex Efros <powerman@powerman.name> wrote: > Hi! > > On Mon, Oct 27, 2008 at 07:12:21PM +0200, Ciprian Dorin Craciun wrote: >> * first of all a lot of services are not started by default (by >> using the 'down' file), but this doesn't stop runsv to start the >> logger => could there be an option to start the loggers only when the >> server actually starts? > > why starting these loggers bother you? they doesn't hurt anything It does not bother me too much, except the fact that there are processes running, which do not do anything... And I usually like to keep a small number of active processes... (This also applies to the last question.) >> * if I send HUP to runsvdir /services it sends TERM to runsv >> /services/ciprian, which in turn sends TERM to runsvdir >> /services/ciprian which breaks, and leaves all my services dangling... >> => could there be an option to actually pass the same signal down the >> chain? (for example if I send TERM to runsv or runsvdir, it should >> send TERM downpath, and so for any other signal, for example USR1, >> etc.) > > you can configure this behaviour - check CUSTOMIZE CONTROL in runsv(8) I know about this settings, and this is how I do it (with an x file in the control folder)... But the problem is that the signal interface (if I can call it so) to the runsv and runsvdir are incompatible even though they should be used together... So I say that this is more a design issue... Also, as I said, it would be nice to have all the signals being passed down the hierarchy -- imagine I would like to implement with USR1 signal the functionality to reload all configuration files for all the services (where applicable). Also going a step further, maybe it would be nice to have custom signal handlers inside control folder (like usr1, alrm, just like normal command characters); >> * if I want to stop the runsvdir /services it sends the signal to >> all its children, but exists immediatly, and this is a problem if I >> stop it from an rc.0 or 6 script, because it should wait for all the >> children to actually stop; for now it leaves them dangling, and the >> unmounting of the file systems breaks... => could there be an option >> to actually make runsvdir to wait for it's children? >> >> * if a process takes to long to terminate (when it receives TERM >> signal), it would be nice for runsv to actually send KILL, but this >> should be configurable, as I wouldn't like to have runsv kill runsvdir >> like this; > > I usually do this: > > # Give a chance for all processes for clean exit. > # This also will kill all 'runsvdir' and signal all 'runsv' to exit. > killall5 -15 > > # ... some other de-initialization like hwclock --systohc > > sv force-stop /var/service/* &>/dev/null || : > > # ... more things to do while services stopping - save sound mixer > # state, remember last random, shutdown network interfaces, etc. > > # Goodbye to everybody... > killall5 -9 > > # unmount and reboot This could be a solution too, but it doesn't run out of the box... When I wanted to use runit, I had to spend a lot of time to tackle exactly these issues... So I would say it leads to a deployment problem... I ended up using a similar solution: kill -s HUP "${pid}" sleep 3 killall -q -s TERM runsv runsvdir sleep 3 kill -s KILL "${pid}" killall -q -s KILL runsv runsvdir But this seems like a hack to me... >> * (a small annoyance) it would be nice to be able to combine runsv >> and runsvdir into a single command, as this would reduce the number of >> runsv processes, until I actually need to start a service; > > why starting these processes bother you? they doesn't hurt anything too > > really, having small annoyance each time you do `ps` and see a lot of > small processes which do nothing useful except keeping all your system > services running in reliable way - is fairly acceptable. and you always > know how to run all your services in less reliable way with standard > /etc/rc.d/* scripts to avoid this annoyance I agree with you that it is much eassier to manage the services by using runit than the sys-v5 way of doing things, but what I am saying, is that there is just another small step to be taken in order to obtain a complete solution... The ultimate step would be to integrate somehow service dependencies in the entire design... Maybe a initialize script, that if it exits, it will not continue with the run script. I know that i could do this directly inside the run file, but so could we have done with the case of finish... > -- > WBR, Alex. Thank you for your feedback, Ciprian Craciun. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-10-27 18:03 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-27 17:12 runsv and runsvdir problems Ciprian Dorin Craciun 2008-10-27 17:30 ` Alex Efros 2008-10-27 18:03 ` Ciprian Dorin Craciun
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).