LFS with Runit (without SysV)

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

Certainly for deamons that keep running like mysqld the finish script was necessary to take the service down/up manually. I haven't tried a one off script yet like ntp, that is on my todo list, I guess at the moment it's on a case by case instance.
Looking at the man page if you issues a 'down' command via sv it should exit the run command and then run the 'finish' script but the documentation is not good, I assume that if something is set as a service and it goes down ( a once off script for instance ) it will try to restart it unless you use manually shut it down.

Maybe your alsa and ntp scripts should be run by the level 1/3 script ( as you only want them at start up and shutdown ) and not as services which as I understand it runit will try to bring back up if/when they go down?

My head hurts

stoat · 05-07-2014, 11:38 AM

Quote:

Originally Posted by Keith Hedger

Maybe your alsa and ntp scripts should be run by the level 1/3 script...

A good idea. I should have thought of that.

Keith Hedger · 05-07-2014, 01:41 PM

Glad I could help, I have been trying to wrap my head around this whole run/finish script bit especially with ntp, and I gather it goes like this: ( at least this is working for me )
If you want/need a sercvice that will come back up if it dies, the run script is used to start it , when it dies the finish script, if it exists is run, this should be used to do any clean ups before the service is restarted , removing stale locks etc, ntp needs this script if you take it down it to remove the stale lock pid otherwise it keeps trying to rerun.

This ntpd script goes up and down properly:

Code:

mkdir -vp /etc/sv/ntpd

cat > /etc/sv/ntpd/run << "EOF"
exec /usr/sbin/ntpd  --nofork -g -u ntp:ntp
EOF

cat > /etc/sv/ntpd/finish << "EOF"
kill -9 $(pidof ntpd)

rm /var/run/ntpd.pid

EOF

chmod +x /etc/sv/ntpd/{run,finish}

cd /etc/runit/runsvdir/default     
ln -sv /etc/sv/ntpd ntpd

So as you have already done with the alsa scripts, anything that you want to run just once at boot should go in the level 1 script, stuff you want to be kept running should go in /etc/sv/...

The lack of --no-fork switch to ntpd is the bit that caused me a load of problems as the run script exited and run the finish script an then the run script and so on...

Well that makes it all as clear as mud

stoat · 05-07-2014, 03:04 PM

Quote:

Originally Posted by Keith Hedger

This ntpd script goes up and down properly:

I just recently got ntpd working, too. I am using that exact same run script. I will add your ntpd finish script to mine.

Keith Hedger · 05-07-2014, 04:11 PM

Great minds think alike!

The more of these service scripts I write the easier it gets and I think they are actually a lot simpler to write and easier to follow than the sysv scripts.

ReaperX7 · 05-07-2014, 08:07 PM

I too noticed that about a lot of the scripts. They're very "human" in terms of how they are scripted. Easy to read and follow scripts are always helpful.

I'm hoping to get some more work into this effort and get my hint updated soon, but recently something came up so I might be delayed a week.

Keith Hedger · 05-08-2014, 02:53 PM

Tidied up your network script (stoat) and added it to the install-* scripts on dropbox, worked OK.
Added install-apache to the install-* scripts on dropbox.

stoat · 05-08-2014, 04:55 PM

If you need them, here are my Fcron and Postfix scripts. Or really, my scripts that create the Runit run, finish, and log scripts. You know what I mean. Anyway, the scripts work. Today I received email via Postfix from RKHunter and Tripwire which were scheduled to run scans in Fcron.

Code:

#Fcron...

mkdir -pv /etc/sv/fcron
tee /etc/sv/fcron/run << "EOF"
#!/bin/sh
#Start fcron.

exec fcron -f

#End /etc/sv/fcron/run
EOF

tee /etc/sv/fcron/finish << "EOF"
#!/bin/sh
#Stop fcron.

kill -9 $(pidof fcron) > /dev/null 2>&1
rm -f /run/fcron.* > /dev/null 2>&1

#End /etc/sv/fcron/finish
EOF

chmod -v +x /etc/sv/fcron/{run,finish}
ln -svf /etc/sv/fcron /var/service

#NOTE: The BLFS book configures syslogd to direct Fcron's log output to
#/var/log/cron. It can be left that way, or a Runit log script can be 
#created for svlogd to filter and handle Fcron log output.

Code:

#Postfix

mkdir -pv /etc/sv/postfix
tee /etc/sv/postfix/run << "EOF"
#!/bin/sh
#Start the Postfix mail system.

exec /usr/lib/postfix/master

#End /etc/sv/postfix/run
EOF

tee /etc/sv/postfix/finish << "EOF"
#!/bin/sh
#Stop the Postfix mail system.

kill -9 $(pidof /usr/lib/postfix/master) > /dev/null 2>&1

#End /etc/sv/postfix/finish
EOF

chmod -v +x /etc/sv/postfix/{run,finish}
ln -svf /etc/sv/postfix /var/service

#NOTE: Postfix uses the syslogd mail facility for logging. 
#Syslogd is configured by LFS to log mail facility messages 
#to /var/log/mail. It can be left that way, or a Runit log 
#script can be created for svlogd to filter and handle 
#Postfix log output.

ReaperX7 · 05-08-2014, 08:31 PM

There was no real issues with SysVinit at all, but it was getting to the point where the usage of symlinking everything between directories was a bit too much and often complex and complicated.

SysV however was a mature init system, stable as a rock, and did it's job well, but it needed a successor worthy to pass the torch and banner onto that was founded on the same principles of SysV. Stability, simplicity, and ease of usage.

Runit might not be the perfect solution, but it has the stability, simplicity, and ease of usage that SysV had, and stays true to the UNIX Philosophy, isn't bloated, doesn't create a dependency hell, works with pre-existing SysV scripts without problems, and works on many non-Linux platforms including BSD.

However, Runit is a step in the right direction as opposed to the other direction.

We will eventually get the init system Linux needs, but it needs to be a step, as Runit and S6 are, in the right direction.

stoat · 05-08-2014, 09:50 PM

My Runit run and finish scripts for smartd (Smartmontools S.M.A.R.T. daemon). Tested and working...

Code:

#Smartd

sudo mkdir -pv /etc/sv/smartd
sudo tee /etc/sv/smartd/run << "EOF"
#!/bin/sh
#Start the S.M.A.R.T. daemon.

exec /usr/sbin/smartd -n  -p /run/smartd.pid  -q never -l local3

#End /etc/sv/smartd/run
EOF

sudo tee /etc/sv/smartd/finish << "EOF"
#!/bin/sh
#Stop the S.M.A.R.T. daemon.

kill -9 $(pidof /usr/sbin/smartd) > /dev/null 2>&1
rm -f /run/smartd.pid > /dev/null 2>&1

#End /etc/sv/smartd/finish
EOF

sudo chmod -v +x /etc/sv/smartd/{run,finish}
sudo ln -svf /etc/sv/smartd /var/service

By default Smartd uses the syslogd daemon facility for its log output. The LFS book configures syslogd to send all daemon facility log output to /var/log/daemon. See the smartd man pages about changing its log output to another facility (e.g., that -l local3 option above) and then configuring syslogd to send it to a folder for Smartd like this...

Code:

sudo tee -a /etc/syslog.conf << "EOF"
# Begin smartd addition to /etc/syslog.conf

local3.* -/var/log/smartd.log

# End smartd addition
EOF

Or, a Runit log script can be created for svlogd to filter and handle Smartd log output.

ReaperX7 · 05-08-2014, 11:15 PM

I think, eventually, but not exactly now, we're going to need an installation script set at least for this in the level of a Makefile for the base LFS system, and a Makefile with specific triggers such as B/LFS's Boot scripts package.

If I have some time tomorrow before I head out and will be away, I'll try and draft a complete installation shell script at least for the LFS base system.

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

stoat just a point about your scripts ( I hope you don't mind ), on the last line you link the service dir into '/var/service' which as it stands is a symlink to "/etc/runit/runsvdir/current" which in trun is a symlink to default -- phew! Anyway if you change 'run levels' by remaking the current symlink ie to go to single ( which shuts down every thing except a single tty - works I tried it ) and then run one of your install scripts following the symlinks it will end up being placed in single ( or whatever 'run level' you are in ) which is probably not what you want, so it may be good practice to set where the service is to be run from directly ie instead of:

Code:

ln -svf /etc/sv/smartd /var/service

Use:

Code:

cd /etc/runit/runsvdir/default     
ln -sv /etc/sv/smartd smartd

Or similar, just for consistency and so you know that the symlink has gone to the right place.

Keith Hedger · 05-09-2014, 05:53 AM

I have added

Code:

install-postfix
install-smartd
install-fcron
install-iptables

To the dropbox list for download.

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

I've been looking at some of the service scripts and the meager documentation for run it and I have found a problem with some of the run scripts, if for instance the postfix run script on line 17 '/usr/sbin/postfix check || exit 1' fails the script will exit with code 1, which should be the end of it and in a normal script would be, but sv will try to relaunch the postfix script continuously, the run script exits the finish script runs and exits and the run script runs again ...

To demonstrate how to either keep a service going up or to kill it permanently from either the run script or the finish script, do this:

Code:

mkdir -vp /tmp/testservice
cat > /tmp/testservice/run << "EOF"
#!/bin/sh

#uncomment the next line to redirect stderr to stdout
#exec 2>&1

echo "started run ..."

if false;then
	echo "do somthing here with exec that doesn't finish"
	exec sleep 10d
else
	echo "condition failed catastrophically"
	echo "Don't restart the service"
#comment out the next line to make the service keep restarting
	echo "d" > supervise/control
fi
EOF
cat > /tmp/testservice/finish << "EOF"
#!/bin/sh

echo "started finish ... "
echo "run exited with code $1"
#echo "d" > supervise/control
EOF

Start the service

Code:

cd /etc/runit/runsvdir/current
sudo ln -svfn /tmp/testservice testservice

As it is the test at line 5 fails ( false always fails ) the service is then instructed to stop by line 12, the finish script will run and the service will not restart, if you comment out line 12 and restart the service like so

Code:

cd /etc/runit/runsvdir/current
sudo rm /etc/runit/runsvdir/current/testservice
sudo ln -svfn /tmp/testservice testservice

The service will continuall try to restart.
Check the console to see the output.

As runit constantly checks the service folder every few seconds services can be started/stopped just by adding removing links, this also means you can add a service at any time just by adding a link, no need to reboot, pretty neat IMO, hope this mini howto helps.

stoat · 05-09-2014, 08:45 AM

I don't mind hearing about that symlink stuff. No worries. I got the way I did those from the hint. Several of the run and finish scripts in the hint are still that way now. Several others added near the bottom don't have the ln command at all. Eventually, all of that will need to be sync'd up for consistency. Also, I don't even have an /etc/runit/runsvdir directory. I skipped that runlevel paragraph in the hint because I don't really need multiple runlevels. And honestly, I was sensory overloaded at that time and didn't really understand that paragraph. Richard Downing's blog doesn't mention runlevels. But looking at the subject again today, it's more sensible. I probably should do that for consistency with everybody else.

Currently, I'm a little bogged down with understanding Linux logging in general and Runit svlogd in particular. Richard Downing's blog has a good page on that. Some services I've just continued using the standard Linux syslogd arrangement. My dbus and network scripts are set up for runit to handle logs. I don't really know what to do about logs at the moment, and my scripts submitted so far might not be totally right in that respect. I may have redirects to null that shouldn't be there, I need to learn sysvlogd, and so on. If you know how, then fix them for that, too. Instead of being offended, I will be appreciative. I want this to be right. I'm not looking for credit for anything.