Good deal Keith. Sorry for my absence in this, but I've been dealing with things. I'm at the library ATM, so I can't get any work done, but I have been reading over the work steadily off a 2G connection that comes and goes.

Yes, Keith is correct about the dependency loading. You have to have the daemon script trigger set to look for that service's execution state, prior to it's execution. If it's not loaded it perpetually waits and rechecks.

The dropbox is a great idea, and eventually, we can release a gzipped or bzipped tarball publicly if necessary.

Okay, update:

I'm back, finally, at my workstation, so I'm going to be fairly much working all afternoon to redraft the hint using Keith's dropbox files, as well as posted efforts, so Stoat and Keith, if you guys have made any changes to any of the scripts, run files, etc. posting them here will be of great help so I can get WIP version 3 drafted and posted.

If we're close to an official release, I'd like to discuss in Private Message if and when we can consider contacting Bruce about an official version 1.0 Release to Mainstream.

I built my entire usual BLFS system without ever having any parts of SysVinit, Systemd, or Udev installed (only Eudev and Runit). Everything is okay.

Same here I am about to give it one more test and then I think I'll go over to using runit/eudev as my main system.
All the dropbox files have been synched ( i Hope! ) so they should be alright, If you want I will tarball all the install scripts into one to make it easier to download, the same with the startup scripts.
I think every one who contributed to both this thread and the original eudev thread deserves a pat on the back.

I never wanted anything, not even a thank you.

For me, this is only a sigh of relief that I proved a point I meant a while back. GNU/Linux needs to not be taken over by corporations with agendas, but by average users like you and me wanting simple, sane, and stable software.

While I feel Eudev being re-added was a mere coincidence, but our work with Runit is different. Bruce even questioned me on why we wanted to try it, and honestly, I'm not even sure my answer was the right one. My only hope is, our work can spark interests, open eyes, and maybe, if we're fortunate enough, to make at least one distribution out there trying to find a new solution, see our work, and see there are choices.

Yes, a tarball would be useful. I'll post my main install script, and we can roll it all together.

Edit:

Released here is a painstakingly compiled Runit setup script if you follow the provided installation hint included. The Installation script will install all basic functionality scripts applicable to LFS only, not BLFS. If you wish to add BLFS scripts please use Keith's dropbox, or wait for the official tarball release.

You'll have to rename the .txt file to a .sh or non-extension file to make it executable.

Attached Files

setup-runit.txt (7.3 KB, 24 views)

Here are the links for the tarballs:

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

Tarballs:
https://dl.dropboxusercontent.com/s/...ervices.tar.gz
https://dl.dropboxusercontent.com/s/...scripts.tar.gz

Well, here's one anyway. Thank you.

This all happened in the exact middle of the LFS experiment with the SysVinit-Systemd "combo book". They were experimenting. We were experimenting. We didn't need no stinking reason.

Yes, but regardless, last night the first boot under pure Runit went perfectly. Dhclient, gpm, and all scripts I use worked perfectly.

Yes we didn't need a reason, but our reason was we wanted a choice that not only was sane and sound, but stable and simple as well. However the boot time was fast enough for my pickiness, and isn't a brain stumper to figure out.

BTW, I just noticed this in the stage 3 script that we are lacking several things. The virtual file systems are not being properly dismounted and the partition dismount keep spitting out an error saying it can't properly dismount the hard drive, and as a result when I checked the partition in Slackware using chroot, when I attempted to mount the drive it said their was a problem.

I did notice ArchLinux used the SysVInit scripts for Halt, SendSignal, and Reboot in their /etc/runit/stop folder, but those are only for the sysvinit tools.

You mentioned that earlier. I still am not seeing this. I confess that I am not exactly following the hint or using the setup-runit script. The Runit and Eudev stuff has been incorporated into the scripts that I use to build my entire BLFS system without ever installing SysVinit, Udev, or any part of Systemd. And I still am using a custom runit/3 script that does not call the LFS initscripts (since they aren't there), but it has the same commands that are in several of the LFS initscripts that are run at shutdown by a traditional SysV LFS system. The runit/3 file is attached just for reference.

I have rebooted my newest system numerous times without seeing console warnings of failure when the commands to unmount the non-virtual partitions and remount / ro are run. And I can run fsck -f on the partition from another system and mount it there with no problems reported.

Attached Files

runit3.txt (1.9 KB, 20 views)

I thought I was the only one with this problem as it hadn't been mentioned on this forum before, usually I have had to remove the bit in the init script about not un-mounting virtual file systems (notmpfs,nosysfs,nodevtmpfs,noproc,nodevpts), but not on this build (7.5) or on the eudev/runit build, seems to be an odd problem that affects some builds but not others, though when you think about it, surely before you can't remount the root system read only ready for shutdown you cant have anything mounted in root otherwise the umount will fail because there are folders in use ( as mountpoints for /dev,/sys etc ).
This:Is the stop command from my old (7.4) LFS and as you can see I had to umount the virtual filesystems as well, otherwise / would not unmount properly and I was getting an fsck virtually every boot.
But oddly ( I had not given it any thought ) this time (7.5) I didn't need to make this change and kept:Does it hurt to umount the virtual files systems?

Stoat, I'll test your stage 3 script tonight to see if it works better. If so, it might become the default, and I'll update the script accordingly. I'm also reworking the LFS-Bootscripts to be copied to /etc/runit under directory /init.d/ rather than /start/ to eliminate the need for the default Bootscripts if at all possible.

The next setup script should reflect the new changes.

Try changing to a tty console and shut down manually by stepping through those commands in the scripts that are run at shutdown time. Maybe you will get some information back about what is happening that is wrong. Another idea is to remove the redirects to null in those LFS scripts and then try shutting down. Maybe something useful will scroll by on the screen.

Some comments about the setup-runit script...

runit/1 runs the LFS setclock script at startup. The hint is aimed at people with LFS systems that have SysVinit installed and want to try or convert to Runit. Those systems will have a udev rule (55-lfs.rules) that runs setclock at startup.

runit/1 runs the LFS network script. So the setup-runit script shouldn't need to create that stage 2 network script at the end. Or, if the stage 2 script is wanted for the service supervision it provides, then the stage 1 script probably shouldn't start the network.

runit/3 needs the stop argument for setclock.

The "if" test for alsactl in runit/3 should have -x inside the test brackets.

The sleep 10 at the end of runit/3 may be too long.

I think its /dev/pts because when I manually ran the shutdown it kept saying /dev/pts was busy which caused /dev to be busy along with /(root). At least JFS is really resilient again data loss or I'd be in a serious pickle.

Obviously I can't know what is wrong, but I wondered if maybe something is being shutdown by sv in runit/3 in an untidy way. Is there a service without a finish script that maybe could use one?

The only services I have are GPM, IPtables, and OpenSSH currently but do they need Finish scripts?

I removed Eth-0 and DhClient due to the fact that by using the network script from SysVinit I can use the dhclient handler from the BLFS-Bootscripts, which is not technically a sysv scripts, but a system handler script.

I'm actually considering removing several things from the Runit setup as well, such as Runlevels as technically they really are bothersome and complex to deal with and with Keith's stage 1 we already have a readied sulogin for Runlevel 1 available. I might re-add them back later, but for now, I'm reassigning /service as the default service management directory for runsvdir. This will only be for testing purposes to ensure reliability for now. It would also serve to be easier to remove the kdm symlink for B/LFS to enable/disable runlevel 5 in a less complex way.