LFS with Runit (without SysV)

Keith Hedger · 05-12-2014, 02:57 PM

Chances are the PATH was exported earlier by something else, but even so I have found that sometimes what you think will get passed to child scripts doesn't and what you assume won't does, ah the joy of bash scripting!

As for the dependency thing the only snippet I found on it was to use the sv status command to test if a dependent service was running and if not just exit the script runsvdir will then try again later and so on.

j_v · 05-12-2014, 09:38 PM

Quote:

Originally Posted by stoat

P.S.: I have seen the documentation on how to force one service to start before another. It's this "automatically" thing I am wondering about.

Is this the documentation you are referring to: http://smarden.org/runit/faq.html#depends? It seems simple enough, but I will have yet to play with it more to be sure I am understanding it right.

stoat · 05-13-2014, 09:55 AM

I built a new base LFS system from scripts modified not to install SysVinit and only selected parts of lfs-bootscripts. It booted okay with Runit first time.

stoat · 05-13-2014, 10:11 PM

I'm still interested in the claim that Runit automatically resolves service dependencies in stage 2. I was reading through some ten year old mailing list banter about runit and user requests for dependency handling.

http://thread.gmane.org/gmane.comp.s.../276/focus=277

Now I think I understand what Gerrit Pape meant by "Service dependencies are resolved automatically".

Quote:

Originally Posted by Gerrit Pape on 1/12/2004

All a service needs to do if another service it depends on isn't available, is to fail.

All it means is that if runsv starts a service and it fails because another service that it needs is not running, then runsv will try again and again. Eventually, the other service will be running and the failing one will then start. I guess that's automatic enough.

I imagine shutdown time is a different matter. Service dependencies can be in play then, too. But stage 3 shuts down everything listed in /var/service with a wildcard.

For me, everything is working fine, and this is only a curiosity to me. In SysV I used to carefully work out these service dependencies for booting and shutdown. So this aspect of Runit just left me feeling like I should be doing something more regarding this matter. But there doesn't appear to be.

j_v · 05-13-2014, 11:33 PM

From the runit FAQ:

Quote:

How do I make a service depend on another service
I have a service that needs another service to be available before it can start. How can I tell runit about this dependency?

Answer: Make sure in the ./run script of the dependant service that the service it depends on is available before the service daemon starts. The sv program can be used for that. E.g. the cron service wants the socklog-unix system logging service to be available before starting the cron service daemon, so no logs get lost:

$ cat /etc/sv/cron/run
#!/bin/sh
sv start socklog-unix || exit 1
exec cron -f
$

stoat:

Doesn't the 'sv start socklog-unix || exit 1' line in the above script describe the fail policy? Am I just being a knuckle head about this?

stoat · 05-14-2014, 07:12 AM

But that's not automatic. You have to type those lines in a run script for that. It's the claim of automatic dependency handling that I have been wondering about.

Keith Hedger · 05-14-2014, 07:46 AM

I think it's just a badly phrased sentence as far as I can see there is no automatic dependencies per se unless you check them your self, then if the dependencies are running the service will be triggered, its sort of automatic but it still has to be in the service script, after all unless you tell runit about wanting another service to be running before a particular service is started it can't know about them, like anything else that handles dependencies you still have to inform the application of what dependencies you need, so in that sense nothing really handles dependencies automatically.

stoat · 05-14-2014, 07:57 AM

Here is an example of a runit/3 script that will print pretty-ish success/fail indicators on the console at shutdown time. The redirects to null for the commands are to keep their output off the console screen. These kinds of things are very unlikely to fail, but it does work if that happens. It tried this script in a system that didn't have alsa installed and a failed message scrolled past. The sleep 3 command at the end provides a short moment to look at that stuff. Otherwise, it flashes by too fast to see at all.

Code:

#!/bin/sh
exec 2>&1

PATH=/sbin:/bin:/usr/sbin:/usr/bin

LAST=0
test -x /etc/runit/reboot && LAST=6

echo 'Waiting for services to stop...'
sv -w10 force-stop /var/service/*
sv exit /var/service/*

# Save the alsamixer volumes
alsactl store > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error saving alsamixer volumes"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m alsamixer volumes saved"
fi

# Sync the hardware clock
hwclock --systohc --utc > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error synchronizing hardware clock"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m hardware clock synchronized"
fi

# Save the random number generator seed
dd if=/dev/urandom of=/var/tmp/random-seed count=1 > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error saving random seed"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m random seed saved"
fi

# Stop the system log daemons..."
kill -9 $(pidof klogd) > /dev/null 2>&1 || failed=1
kill -9 $(pidof syslogd) > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error stopping system log daemons"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m system log daemons stopped"
fi

# Unmount all non-virtual partitions & remount / rw
umount -a -d -r -t notmpfs,nosysfs,nodevtmpfs,noproc,nodevpts > /dev/null 2>&1 || failed=1
mount -o remount,ro / > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error unmounting non-virtual partitions or remounting root partition ro"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m non-virtual partitions unmounted"
   echo -e "\\033[1;32m  *  \\033[0;39m root partition re-mounted ro"
fi

# Turn swapping off
swapoff -a > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error turning off swaps"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m swaps turned off"
fi

# Bring down the localnet
ip link set lo down > /dev/null 2>&1 || failed=1
if [[ ${failed} == "1" ]] ; then
   echo -e "\\033[1;31m*****\\033[0;39m error bringing down loopback interface"
   failed=""
else
   echo -e "\\033[1;32m  *  \\033[0;39m loopback interface down"
fi
sleep 3

Keith Hedger · 05-14-2014, 09:00 AM

Nice, but .. (you knew there would be a but

), would it not be easier to maintain if the individual parts were separate scripts, a la sysv?
Here's how I have done it:

Code:

#!/bin/sh
exec 2>&1

PATH=/sbin:/bin:/usr/sbin:/usr/bin
export PATH

LAST=0
test -x /etc/runit/reboot && LAST=6

echo 'Waiting for services to stop...'
sv -w10 force-stop /var/service/*
sv exit /var/service/*

# Save the alsamixer volumes
/usr/sbin/alsactl store &>/dev/null

# Sync the hardware clock
/etc/runit/start/08-setclock

# Save the random number generator seed
/bin/dd if=/dev/urandom of=/var/tmp/random-seed count=1 &>/dev/null

# Unmount all non-virtual partitions
/etc/runit/start/10-mountfs "stop"

# Turn swapping off
/etc/runit/start/06-swap "stop"

# Bring down the localnet
/etc/runit/start/18-localnet "stop"

sleep 10

The sleep is just for testing so I can see the o/p.
The individual scripts are kept in "/etc/runit-init.d", with symlinks to "/etc/runit/start", those scripts that need a start/stop function have them, that way I can use the same scripts for starting/stopping and speaking as a programmer I have always found it easier to manage/maintain several small files rather than one big one.

I also have a small function file in "/etc/runit-init.d" that does pretty printing so I can keep all those weird echos in one place.

I don't have an alsa/random number init script yet hence they are set manually.

All my init files can be grabbed from here:
https://www.dropbox.com/sh/bky00dj8e...h0E38ZTwn-ihda
( you don't need a dropbox account )

stoat · 05-14-2014, 03:30 PM

Thanks. For me, that small amount of shutdown stuff is better all in one place. Even though it may not be common and efficient practice, for this Runit stuff I've been trying to get rid of calls to other scripts. But I did change all the "weird echoes" with the color escape codes to two variables at the head of the file like init-functions does. And I did do the run/1 script like you did, but it has a lot more to do. Anyway, I only wanted to bring up that Runit doesn't have to be so prosaic in appearance.

I hope the hint project has not run off the road. I still think that is a good idea.

Keith Hedger · 05-14-2014, 04:15 PM

I don't think its run off the rails we are all just trying slightly different approaches, which is fine.
In some ways I agree about the close down script it is quite small and there is no real need to call external scripts at the moment, I was just thinking ahead to where the shutdown gets more and more complex, its then that the benifit of a modular system really kicks in, the other thing of course is that every time you start a new process by running a new script a small amount of system resources are used up, an new instance of bash, a new process, etc all of which takes time, and of course bash itself needs to do a certain amount of startup preperation before it can begin to run a new script all of which takes a little time, so one script is easier on system resources compared to the modular system, it's swings and roundabouts really.

stoat · 05-14-2014, 05:43 PM

The last version of the hint that I saw looked about done. It should be simple and basic anyway. People can expand and embellish from there. It installs runit, creates basic stage {1,2,3} files, the Ctrl-Alt-Del handler, reboot and shutdown, and the getty scripts. It uses the LFS initscripts. That's enough to get going. If anything, the hint may have overshot in the area of stage 2 scripts. Maybe those should be pulled out of the hint (except for a couple like gpm to serve as examples) and put in the stash individually with the others you've collected. That way the hint would not be overladen with scripts that not everybody will need anyway. Eventually, your script collection might be stored in the ATTACHMENTS folder with the hint at linuxfromscratch.org.

Keith Hedger · 05-15-2014, 07:59 AM

Quote:

Originally Posted by stoat

...If anything, the hint may have overshot in the area of stage 2 scripts. Maybe those should be pulled out of the hint (except for a couple like gpm to serve as examples)...

I tend to agree but at some point ALL the LFS/BLFS start up scripts will need to re-written for runit to make this a viable alternative to sysv

stoat · 05-15-2014, 08:54 AM

Yes.

What I meant was that all those scripts don't need to be present in the hint itself. Just a few simple ones for the sake of example or a basic init setup, then the remainder in a sort of repository (say, the ATTACHMENTS folder for the hints) that the hint could refer readers to. Otherwise, the hint would be so huge that it would repel even the most determined reader. The last hint version seemed to be growing a script repo at the end. It's just a suggestion. The hint essentially could be finished right now except for cleanup and polish. All that would remain is finishing the collection of LFS Runit scripts.

Keith Hedger · 05-15-2014, 09:38 AM

Agreed.

I am probably going to go over to eudev and runit as my main system, and I am happy to translate scripts from svsv to runit and make them available via dropbox, ( I prefer to write from scratch though, translating stuff is soooooo duuuuulllllllll ).