LFS with Runit (without SysV)

Keith Hedger · 05-09-2014, 08:51 AM

Trying to wrap my head around the logging bit myself, it will take a bit of work and co-operation from all of us to get the scripts/hints standardized, but that's what LFS is all about it's about the learning

ReaperX7 · 05-09-2014, 12:59 PM

Yep. I don't think all the daemons require a log, but they are helpful in diagnosing run script issues.

Note: I had a bad failure today which resulted in a somewhat locked file system that took a while to repair. Not sure what happened, but I think I have everything back under control for now.

I had to revert my stage 1 script back to the original version to test and repair the issue, so I'm not sure exactly what happened here.

I noticed today also that the Stage 3 script is NOT properly dismounting the drive(s), so that needs to be looked at as soon as possible.

stoat · 05-10-2014, 08:08 AM

I think I finished my Runit setup. It's working fine. I learned a lot of new stuff. I also got an education on logging yesterday. And since I wrote my own Runit stage 1 scripts, my Runit init system has no dependency on the LFS SysV init system being present (but it's still there).

Anyway, thanks to ReaperX7 for hatching this idea and driving it forward. Thanks to Keith Hedger for patience and for teaching. I think we should continue moving this forward to convert other LFS initscripts over to Runit scripts and test them.

stoat · 05-10-2014, 09:09 AM

Quote:

Originally Posted by ReaperX7

I noticed today also that the Stage 3 script is NOT properly dismounting the drive(s), so that needs to be looked at as soon as possible.

Some comments I have about the last version of the hint that I could find...

One is that swaps are deactivated before mountfs is run. The LSB standards section of the LFS mountfs initscript lists swap as "required stop" meaning swap should not be stopped before mountfs at shutdown. So one thing to try is to reorganize the order of the stage 3 script to match the order of /etc/rc.d/rc6.d in the LFS SysVinit system.

Another thing to consider is to convert stage 3 from calling the LFS initscripts to putting the commands directly in the stage 3 script. It probably doesn't really matter, but it's easy to do because at shutdown those are all simple one or two line things.

Lastly, and not related probably, is stage 3 in the hint has "network stop". Since the network is started in stage 2, Runit takes the network down automatically with all the other stage 2 stuff. It is my position that stage 3 doesn't have to deal with shutting down anything that has a symlink in /var/services and the eth-0 (or network) service does. Maybe some error is being thrown because of that call to the LFS network initscript by stage 3, and that is doing something unwanted.

ReaperX7 · 05-10-2014, 10:20 AM

On my phone so can't test until next Saturday but I think we probably should directly call things from Runit. It's good we can use the sysv scripts, but we really should see about a full native scripting for this. I had wondered about the swap, so that was my fault. However, the boot will need some retuning.

stoat · 05-10-2014, 10:33 AM

Quote:

Originally Posted by ReaperX7

...but we really should see about a full native scripting for this.

Good idea.

Keith Hedger · 05-11-2014, 07:43 AM

This should be read in conjunction with this post:
http://www.linuxquestions.org/questi...ml#post5167717

A number of apps like cups etc handle their own logging and so a log folder is not needed, however it is easy enough
to add a logger either for admin or debugging, like so:

Code:

mkdir -vp /tmp/testservice/log

cat > /tmp/testservice/log/run << "EOF"
#!/bin/bash

#stdin is connected to ../run stdout

while read
	do
#echo to console AND to logfile
		echo -n "message from log runscript ... "|tee -a /tmp/testservice.log
		echo "$REPLY"|tee -a /tmp/testservice.log
	done

EOF

Basically the input to log/run is connected to the output of run AND finish so anything either of these two scripts send to stdout
will be sent to log/run's stdin but ONLY if the log folder/files are present, if you want to capture stderr from the run/finish
scripts you should redirect stderr to stdout uncomment the line at the start of the run file 'exec ...'.

If you have set the service to keep restarting you will find that the log file and the console will pretty soon
clog up with repeat entry's, so be aware , the simple way to prevent unwanted duplicates in the log file is just to pipe it
to sort -u.

And that is simple logging with runit.

This an the previous howto on services can be downloaded from here:
https://dl.dropboxusercontent.com/s/...ices-howto.txt

stoat · 05-11-2014, 01:15 PM

Quote:

Originally Posted by Keith Hedger

Code:

if false;then
	echo "do somthing here with exec that doesn't finish"
	exec sleep 10d
else

Don't forget about the pause applet we created for the network script.

Keith Hedger · 05-11-2014, 02:01 PM

Didn't think of that but as long as it doesn't return straight away it doesn't really matter.

j_v · 05-11-2014, 09:21 PM

Finally, I'm catching up. Just booted freshly built LFS-7.5 (with eudev and runit, without sysvinit) with 3.14.3 kernel built using Slackware current huge config. Very little tested, but getty's/login work fine, as well as dhcpcd. I will report back as I progress with adding stuff. Once I get a few more services in place I will start a repo on my github account.

You guys are doing a great job. This is good stuff.

Keith Hedger · 05-12-2014, 10:56 AM

Quote:

Originally Posted by stoat

...

Code:

...
# Sync the hardware clock
exec hwclock --systohc --utc &>/dev/null

# 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
umount -a -d -r -t notmpfs,nosysfs,nodevtmpfs,noproc,nodevpts &>/dev/null
mount -o remount,ro / &>/dev/null

# Turn swapping off
swapoff -a &>/dev/null

# Bring down the localnet
ip link set lo down &>/dev/null

...

Just had a relook at this while I'm mucking about with start/stop scripts and I noticed something, everything after the line to sync the clock will be ignored because exec replaces the currently running process with the given command, just remove the exec should be OK.

Keith Hedger · 05-12-2014, 11:02 AM

Just to clarify open a terminal and run

Code:

xterm;xterm

close the 1st xterm and the 2nd will launch close that and you are back to your original terminal.
run

Code:

exec xterm;xterm

This time after closing the 1st xterm the 2nd doesn't run and the original terminal will close, using exec in scripts will NEVER run anything that comes after it ( the only exception is redirecting stdout etc via exec 2>&1 )

stoat · 05-12-2014, 02:26 PM

Okay thanks. I had already fixed that during general reviewing and tweaking, but I have to admit that I did not know the real reason it shouldn't there. It just looked unnecessary there, so I removed it. I also at the same time removed path prefixes such as /sbin/dd since a PATH variable is set at the beginning.

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

Quote:

Originally Posted by stoat

...I also at the same time removed path prefixes such as /sbin/dd since a PATH variable is set at the beginning.

Might be an idea to add "export PATH" after setting it so that any scripts/apps that might get called later on in the script will inherit the PATH variable, it does no harm to export it even if it is not used but does save having to set it repeatedly.

stoat · 05-12-2014, 02:38 PM

Okay. I will do that. But first, the stage 3 (and 2 and 1) script came with that PATH command that way. But also, that I did wonder about and test. That PATH variable written like that does get passed to called scripts.

Here's one lingering question that I have... The runit documentation states that runsv automatically takes care of service dependencies at both start up and shutdown time.

http://smarden.org/runit/dependencies.html

Okay, so how does it do that? Anybody know? I mean, I haven't seen any place for me to configure that. So does runit have some built-in database of Linux services so that it knows the best order to start and stop the stage 2 stuff? I don't think starting order really matters for my particular set of stage 2 services, just wondering. Starting and stopping order does matter for stage 1 and 3, but those things are sequentially listed in scripts. So I assume that runit deals with them it that order.

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.