I'm fortunate to announce after weeks of work to fine tune everything and get things to where they are needed, the official release of the new and modernized Runit Hint and Script installer for LinuxFromScratch.

This work has been the effort of many people with main contributions from myself, Stoat, and Keith Hedger here at LinuxQuestions, with references used from the original Build-with-Runit hint for LFS courtesy of Richard Downing.

This release however redoes and updates Richard's original and later works and reformulates the LFS installation around Runit-2.1.1 rather than sysvinit-2.88dsf at Chapter 6.64.

This release is Version 0.1 - 2014-05-30

To use, rename setup-runit.txt without the .txt extension to setup-runit and make it executable.

Thank you, and we hope you support our efforts to provide a clean, modern, viable, and stable alternative to traditional sysvinit for LFS.

=====================================================================
Just a quick FAQ:
=====================================================================

1. What is Runit?

Runit is Gerrit Pape's UNIX init schema that is meant to work with a variety of systems.

2. Does Runit replace sysvinit?

Yes and No.

Yes, in practice it replaces sysvinit with it's own tools and custom scripts and recycles several existing LFS bootscripts from sysvinit for it's own purposes.

No, in that Runit does not actually replace sysvinit in fundamental terms. Runit is offered ONLY as a clean, viable, stable, and useable alternative to sysvinit that does not intrude heavily into the system, nor does it create a dependency core within the system all packages must build around, or perform actions an init system should NOT perform.

3. Does Runit have Runlevels.

By default in our implementation, Runit uses a default runlevel and an emergency superuser login mode if the boot process fails for any reason. So, in effect it has the sysvinit equivalent of 1 and 3 by our default and design.

4. Where do I get run, log, and finish files for Beyond Linux From Scratch services?

Some services like dhclient, dhcpd, and dhcpcd use system execution scripts rather than sysvinit scripts to operate, so you'll find them in the BLFS-Bootscripts package (make sure you read the makefile located in the blfs-bootscripts-<version> folder for clues as to what is a sysvinit script and what is a system execution script), however things like dbus, iptables, fcron, etc. you'll have to get from Keith Hedger's dropbox tarball located here:

https://www.dropbox.com/sh/forvgrr15...Kd5FqiCZQQ9rha

The current supported run files are few, but more are always being added and worked on. If you need a service script set, please feel free to inquire about one so we can add it.

5. How do I reboot or shutdown using Runit if I don't install sysvinit?

The setup-runit script provided here creates several scripts to shutdown and reboot the system.

halt - symlink to shutdown
shutdown - executes /sbin/init 0
reboot - executes /sbin/init 6

By their respective commands, you can use both init 0 and/or 6 for these purposes.

Currently we are still experimenting with work through X.org sessions like Xfce which has it's own shutdown, reboot, and sleep features, but the current installed scripts should work with those. If you have issues, please let us know ASAP.

=====================================================================

Attached Files

	runit-alt-hint.txt (10.5 KB, 88 views)
	setup-runit.txt (6.0 KB, 76 views)

Just had a quick look at the hint and the script, the script looks ok and I will test it properly early next week, the hint seems to end very abruptly ( compared to the original ), has the file been truncated?.

Yes, I put the hint as the installation method only with all the post installation done by the setup script. I trimmed out several run scripts that were a bit repetitive such as the dhcp{cd,client,server}, and eth-0 scripts and returned to the service execution scripts instead. Everything is still geared to install to LFS with some extra gearing for chapter 3 of BLFS.

I did move the runsvdir back to the default /service directory and eliminated the pseudo-runlevels.

Otherwise everything is fairly the same.

Very nice hint. Now to Bruce, I guess.

I thought for a while before deciding to mention the alsactl command in the stage 3 script. Even though it tests for the existence of alsactl before running it, I wonder if the stage 3 script would look better without it at this point. ALSA is a BLFS package. Not everybody will install it. And for people that do install it, they would need to edit stage 1 to restore the alsamixer volumes. So we may as well wait 'til then to put the alsactl store command in stage 3. Just an opinion.

The setclock command will be run twice at boot time since that 55-lfs.rules thing in a standard base LFS system makes udev run it, too. It does no harm the way it is, but some people may wonder about it. One way to deal with it without messing up the simple for-do loop in stage 1 is to omit the link to setclock in stage1 and call the LFS initscript directly in stage3 (or run the hwclock command in stage 3). Just another thought and opinion.

Overall, you did an excellent job on this project.

I might leave setclock as is for the time being. Because udev is more or less an option for some people not everyone will require the rule. The rule seems to serve as a backup.

Also, I did notice the run scripts might need some minor re-formulation to install to /etc/sv and re-link to /service.

No problem really.

As far as Bruce... I'll submit the completed hint and script set soon enough, but I want to make sure we have a complete replacement for all of the sysvinit scripts (minus the system service scripts and the recycled bootscripts) for BLFS just to be safe. The hint has to be 100% on this effort, unlike eudev which was more or less a conservation effort. Eudev had some issues, but with an init system, better safe than sorry.

Just a couple of points the script is putting stuff in /service instead of /var/service, before we were using /var/service is this a typo or is there some reason to change this directory?

Second the delay at the start of the script is a good idea but can be annoying as you HAVE to wait 10 seconds how about something likeUsing the above pressing any key will continue, pressing CTL-C will abort and waiting 10 seconds will continue.

I changed the directory back to the default because runsv wasn't properly detecting the status of services correctly in my tests. Not sure why. However with /service things work. Possibly a permissions error on my part perhaps, but again, uncertain.

I put in the timer to allow someone enough time to consider things, but its just for that. I'll edit it for the key click tonight too.

Update. Runit was complaining of too many symlink levels.

Well I've had a lot of silly problems with the new eudev/runit install but I,ve finally got them worked out, eudev does NOT like kmod 16/linux-3.13.x but with kmod 17 and linux -14.14.4, its all fine.

But ...

The changes to the install script from the development stage I feel is a step back, using symlinks instead of using real directory's does make it easier to switch to different run levels, putting every thing in /service just seems the awkward way to do it, OK if you are only going to have one run level and one set of services it may be justified but it does make the whole thing a lot less flexible, also of course all the install services scripts assume that you are using a 'default' folder eg install-gpm has as the last two linesAs do all the other install scripts ( except of course they aren't called gpm ), in the develoment stages /etc/runit/runsvdir/default was symlinked ( via 'current' ) to /var/service, so just changing the one symlink allowed switching to different run levels, very useful for debugging etc.

I am quite willing to change the install scripts to reflect the new changes but I would strongly recommend going the symlink way, but this is very much Reaper's baby so I will go with his final decision.

As an aside the setup script as it stands works fine, both installing in /service and /var/service, I just think it's a bit nicer to use /var/service, although on the runit website they use /service ( you must have had a corrupt symlink to get the 'Too many levels' error ).

Let me know if you are going to go with the setup script as it is and I will make the appropriate changes to the install scripts.

I won't rule out using runlevels in the future so expect them to return, but for now I'd like to give Runit a complete workout to make sure everything is up to the challenge. Besides adding a symlink to the GDM, XDM, or KDM in effect does effectively substitute desktop or runlevel 5. However, yes runlevels will be needed, but for now this should suffice to at least get it working.

Also Kieth, I keep getting a readout from OpenSSH that sshd is always in the down state and not the up or running state when I execute:

It says it starts but abruptly stops and shuts down.

AAAaaagghhhh!
Come on own up who moved the install location of svlogd?
No seriously it was being installed in /usr/bin it now goes in /usr/sbin so those services using it were playing up, I have altered the scripts and redone the tarball just re-down load and re-install ( or you can just manually change "exec /usr/bin/svlogd" to "exec /usr/sbin/svlogd" )

Tried sshd service and it works fine now.

Ah the headaches of a typ-o... Yes fixed here too.

And now onward and upward.

Not sure how it got switched to /usr/sbin, but I thought it always was in /usr/sbin with chpst, runsv, runsvdir, and runsvchdir. The runit and runit-init binaries were in /sbin.

Should we keep it as /usr/sbin?

I would leave it in /usr/sbin

Seems logical.

I'm currently building a new B/LFS installed based on (LFS)SVN-201400527 and (BLFS)SVN-20140602, but temporarily with sysvinit at the moment, but it is going to be reworked for Runit when completed with sysvinit uninstalled. I built it using a few of my scripts and so far I'm at the KDE installation following Chapter 3 Post-Install and the Xorg installs. This one was to experiment with a system that was completed and reworked to Runit rather than pre-geared for Runit.

I'm currently using the below mentioned LFS on my main system as a testing grounds for Runit. Works very well so far.

After reading through the BLFS and LFS books, I've more or less determined we'll be needing these run files for daemon management:

acpid (ported - completed)
alsa-utils (covered by stage 1- not required)
apache (ported - completed)
at (ported - completed)
autofs (uncertain, but may have to add an installer for the default configuration script in blfs-bootscripts.)
avahi
bind
bluetooth (ported - completed)
bridge-utils (system service script. Might be resigned to stage 1)
cups (ported - completed)
dbus (ported -completed.)
dhclient (covered by service script in stage 1 - not required)
dhcpcd (covered by service script in stage 1- not required)
dhcpd (dhclient server)
dovecot
exim
fcron (ported - completed)
gdm - (unneeded since GDM is part of GNOME which is now deprecated from BLFS)
gpm (ported - completed)
haveged
httpd - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated/external software.)
iptables (ported - completed)
ipx (system service script. Possible assignment to stage 1.)
lprng - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated/external software.)
kdm (ported - completed)
krb5
mysql (ported - completed)
netfs
NetworkManager
nfs-client
nfs-server
ntpd (ported - completed)
php-fpm
pppoe (uncertain as to how to implement it, but due to the fact it's a system service rather than an init script, it could be put into stage 1.)
postfix (ported - completed)
postgresql
proftpd
qpopper - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated software.)
random (assigned to stage 1 - not required)
rpcbind
rsyncd - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated/external software.)
samba (ported - completed)
saslauthd (may require an installer for the default configuration script in blfs-bootscripts somehow.)
sendmail
slapd (may require an installer for the default configuration script in blfs-bootscripts somehow.)
soprano
sshd (ported -completed)
stunnel
svn
swat - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated/external software.)
sysstat (assigned to stage 1 - not required)
unbound
virtuoso
vsftpd - (uncertain on implementation. No documentation in the current book on it exists. Possibly deprecated/external software.)
wicd
winbindd
wpa ( system service script. Will probably be assigned to stage 1.)
xinetd
xnmap
zenmap

The dbus run file still has an execution problem. Execution of
Complains the service is down and not working. Any thoughts?