On Tue, Dec 16, 2014 at 8:54 AM, Steve Litt <slitt_at_troubleshooters.com>
wrote:
>
>
> Thanks Avery,
>
> First of all, I eventually overcame these problems, so this email is
> pretty much confirmation of what you wrote.
>
Cool!
So now I've removed both systemd and sysvinit from the equation. My
> next task is to start moving stuff from openrc's sysinit and boot
> to /etc/runit/1 (and I don't know how to do this yet), and then start
> switching services from openrc's default to linked /service
> subdirectories (you know what I mean).
>
I may have a few helpful tips (please excuse the long post):
If you have a stable definition for a getty (and it sounds like you do),
then clone it and set up others, or use a tty multiplexer like tmux or
screen. That way, if you experiment on tty5 and have problems, you can
jump to another console and you're not locked out.
Enable handling of ctrl-alt-del in runit. Using this feature you'll get a
clean(er) shutdown of the file system, instead of pressing the hardware
reset button. Without it, in a lock-out situation you'll need a hard
reset, and a file system that needs a fsck. You can always disable it
later if you don't want this behavior.
When writing up services that could lock you out, go to the service
definition directory and do a "touch ./down", so if you reboot, it the
system will come up with the service down, and you're not stuck fixing a
"run loop". You can always start it manually with "sv start (service)" and
it will ignore the down file. If the service is faulty or locks you out,
you can ctrl-alt-del (as the above suggestion) and recover gracefully.
When the service is running smoothly, remove the down file, and it will
come up "normally" after reboot.
Doing a "touch ./down" only implies that the service isn't started **when
runsvdir starts**. It does not imply that the service will stay down if
you tell it to go down, and then ask it to come back up - the down file
will not block it from starting again.
You'll find that udev doesn't fit neatly into this arrangement because it
is a service that needs to be up before supervision starts, and down after
it stops. This is "The udev question - how do we handle this?" and it's
vexing for runit, because it needs to be handled in stage 1 and stage 3,
and the supervision tree is only up in stage 2. Some people don't bother
with it and just let it run separate of supervision - it doesn't hurt to do
this.
There are a few pre-made definitions for processes on github and
bitbucket. If you get stumped, you can see what others have done; many are
happy to share their efforts, so contact the authors and ask.
If a service keeps detaching from the process tree, it probably needs an
option passed to it that tells it not to background itself. The SysV
approach of "background the service at all costs" has pervaded the design
of just about all *nix services, so you'll encounter this a lot.
Lastly, the mailing list is fairly low-noise/high-content, and has lots of
older posts that may cover questions or issues you'll encounter. It's
worth looking back through and seeing the discussion that has been posted.
You can always see it here:
http://www.mail-archive.com/supervision_at_list.skarnet.org/
Good luck with your switch-over!
Received on Tue Dec 16 2014 - 21:49:11 UTC