As of today, 7-9-2014, we're suspending activity on this project until further notice. We feel at this time, the s6 package is not fully understood well enough to go for a mass deployment as we did with Runit. In time, we may return to the project, or we may not.

All members of the LFS-Runit team have unanimously voted to suspend the project, so at this time no further discussion will take place in this topic.

If you wish to discuss this, we may do so in private, but officially the project is suspended until further notice.

The official releases by our team regarding Runit may be found here:

http://www.linuxquestions.org/questi...se-4175506569/

With ongoing discussion and developments taking place here:

http://www.linuxquestions.org/questi...sv-4175503653/

Thank you.

Just cleaned some space on my machine and have started building the tools ( I like to build the tools from scratch when stating a new project after that I use the tarballed tools )

I made some minor changes to the build script as I don't like absolute paths and I use the 'make install DESTDIR=xxxx' method to install as I use a package manager.

Will post back when the main system is in and running.

A repost of a part of the message that I wrote in the previous announcement thread:

---
I'm currently thinking about converting my build system to a more standard configure-make-make install one, to remove the small amount of policy contained in s6: slashpackage - the system layout I use - is a good thing and I can only encourage people to adopt it, but a piece of software is not the place for advocacy, so the build system will be as flexible as can be in the future.
---

IOW: don't let the build system discourage you, it will be going away soon.

Guaranteed absolute paths for system tools are the only way to get a certain kind of reliability and reproducibility, and I swear by them for my machines' administration. I wish there were a distribution that actually used and enforced a slashpackage-like way of setting up software. But I realize that it's a policy decision, and a distributor's or sysadmin's choice to make; so the software must support them, and take advantage of them when it's installed that way, but must not depend on them.
It's already possible to install s6 wherever you want in a FHS-like way; it's just a bit quirky. The quirkiness will disappear at some point.

2 members found this post helpful.

This is highly positive news.

Laurent, I would advise a possible flag for the configure script, --slashpkg="Boolean", to allow a true or false argument to switch between FHS and Slash-Package. This would give lots of flexibility to packagers and administrators.

The next step we're facing is writing the initial and system agnostic init stage-1 script in BASH. Because Bash is the default system shell for LFS, writing code in BASH is the best solution. We also will need reboot and shutdown handling scripts to make calls to the system control binary.

I'm planning to use the example init stage-1 script to at least get a working sample up that can be used out of chroot. I asked Patrick Volkerding in a PM how he implemented his bsdinit to get some ideas and pointers. No word back yet, but I'm certain we can proceed regardless. We need to formulate all the standard start up scripts of LFS into stage-1, but this time without passing them to external scripts as we did with Runit. I'm certain we can draft a script that meets any distributions needs including LFS.

For now I've imported the example directories into LFS to establish an initial boot to see if it works.

I was thinking that if there's a chance it can be done Laurent, would it be plausible to duplicate s6-reboot, s6-halt, s6-shutdown, and such from s6-portable-utils and s6-linux-utils to formulate a more thorough and complete init handling system? Utilities like those feel more geared for init rather than an external util package... but that's just my opinion.

Edit:

After several attempts at getting the init script to recognize the FHS paths system for /command, updating ld.conf for /library and /library.so, I couldn't get the system to boot up. The kernel paniced with an error stating it tried to kill init. Not certain what that was about other than my own shortsightedness.

I'm going to pour over the script, compare and contrast it to several others, like those used by Slackware, and see if I can reformulate it to Bash, and then re-assign the packages out of /package to the proper directories.

I'm fairly certain that the future FHS layout will more than likely be more akin to this:

I'm uncertain if we'll need the static libs from the packages, but I'll edit them in a revised install script soon enough if this FHS layout works.

Edit 2:

I took some time and did a VERY ROUGH draft of a possible init script, but I'm uncertain to if it will work for s6 and LFS. I borrowed HEAVILY from Slackware almost to the point of plagiarism to get an idea on paper of what we can at least attempt in a single script. I'm not sure if it even will work, so I advise NOT to try using it until someone can help me clean this thing up to hell and back. I'll post it here anyway, but please don't use it by all means.

Attached Files

stage-1_sample.txt (15.0 KB, 40 views)

Having just spent a day and a half trying to get this 'quirky' build system to install in proper locations, I gave up and tried installing it 'as is' which does install with no errors but scatters folders all over the root system, this is just not acceptable to me, the work needed to shoehorn this into a 'normal' system is going to be HUGE, until the developer converts this to a more acceptable build system 'configure,make,make install' or at least something on the lines of the kernel's or mozzila's use of a config file, I think we are on a hiding to nothing, as it stands I can't see it even being considered for LFS let alone any mainstream distro, this is one case where it seems to be 'art for arts sake'.

I am going to bail on this one though I will keep an eye on the discussion and if I can help I will of course do so, but frankly I just haven't got the time at the moment for what looks like a fairly major piece of development work.

Are there any working distros out there that actually use this that could be used as a template?

Reading the documentation would have saved you much time and frustration.
http://skarnet.org/software/conf-compile.html, which is linked from http://skarnet.org/software/s6/install.html, advises you to delete conf-compile/flag-slashpackage and edit the conf-compile/conf-install-* files if you want a FHS-like installation. I don't think it takes a day and a half to do that.

I'll have a look at James' script tonight when I get more time.

1 members found this post helpful.

Actually I did look at this but couldn't find any reference to conf-compile/flag-slashpackage maybe I missed it, but I did work it out eventually, and it doesn't actually compile properly when this file is removed, around about the network bit. Also having to constantly remove this file form all the builds and edit all the conf-compile/conf-install-* was really just too much like hard work, even using sed and a BASH script, you shouldn't have to repeatedly edit the same config files ( yes I know they are in different packages but they are the same config files none the less ) for something as simple as the install location, when this package is a bit more mature and the build system is a bit easier to use it may be worth the work until then I think not, and please don't take this personally or as a criticism of your coding skills.

I forgot the flags to delete those files. This is a learning process since there aren't any ready-to-use work done with s6. I apologize for that oversight.

I am redoing some work to use the FHS design now.

Shouldn't be too bad. Maybe I can draft a cat generated compile sequence of files to write everything before compile-time.

Keith:

If you got a build error, please send me the exact error message with the package name and version. I usually test Linux builds (at least) before releasing; s6 is production-quality, not alpha software, and builds correctly for a lot of people. I will take precise bug-reports and constructive criticism; "you should make the build system more standard" is constructive criticism and I will act on it, but "the current build system does not work" is not, and is most likely untrue.

My bet is that you used shared libraries and did not configure your dynamic linker to find them at the location you installed them. (Shared libraries suck, basically, and I should never have used them in the first place.) Admittedly, the non-standardness of my build system makes it too easy to overlook things, but having to go through the same configuration steps every time is no different from having to give the proper --enable-foobar flags to several configure scripts. Distributions make things easy for users; building distributions is the part that requires method.


James:

About s6-linux-utils: it's a collection of Linux-specific utilities, while s6 is portable. s6 compiles and runs on every POSIX system, and I want it to remain that way. It's the reason why I haven't provided stage-1 and stage-3 scripts in s6: those stages are way too system-dependent. s6-linux-utils is really the place for system-dependent things to reside.
Sysvinit doesn't make much sense alone, you also need a shell, initscripts, util-linux, and so on, in your base image. Same thing with s6, it won't make a base image on its own. Adding s6-portable-utils and s6-linux-utils is not heavy at all; but if you don't want to use s6-linux-utils, "reboot -f" and "poweroff -f" from sysvinit or busybox will do the same thing as s6-reboot and s6-poweroff respectively. Of course, they won't work without -f.

About the layout. I'm not a fan of FHS über alles, but if you're going for it, I would advise something like this:
- Put all the shared libraries into /lib(64). The binaries must be available at init time, before the filesystems are mounted; /usr might be on a different filesystem. / is for packages your system cannot properly function without; /usr for all the rest.
- I would build the execline and s6 binaries with conf-compile/flag-allstatic anyway, i.e. link them against the static version of skalibs. This reduces the amount of critical files on the system, and reduces dynamic linking overhead. (I also usually link them statically against the libc, but that requires a suitable libc - you cannot do that with the glibc - so it's a project on its own.)
- Put the s6 binaries in /bin, not /sbin. Users may want to run those, they are not sysadmin-only. The only binary that justifies /sbin is s6-setuidgid, because only root can use it anyway.
- execlineb makes little sense without the rest of the execline binaries. Either put all the execline binaries into /bin or do not use execline at all (and maybe patch s6-log to use /bin/sh instead, but of course I do not recommend that). "if" and "cd" binaries do not hurt: shells never look up their keywords in the filesystem.
- You can put the static libraries in /usr/lib. They're development files, they have no place in /lib. Just as headers reside in /usr/include, not /include.
- You cannot run s6-svscan on /var/service, because /var may, and should, be on a different filesystem than the root. For s6-svscan to run as process 1, it needs to run in a tmpfs. If you absolutely cannot create a tmpfs on something like /mnt/tmpfs or /service, enforce devtmpfs use and hide stuff into a subdirectory of /dev. It's really hideous, but it will work.
- If services reside in /etc/s6-init/s6-sv, then you will have to create (potentially dangling) symlinks "supervise" and "event" pointing to writable directories that you will have to create at boot time in the tmpfs. s6-supervise needs writable access to the supervise/ and event/ subdirectories of its service directory, and you cannot rely on the root filesystem being writable (most of the time it should not be). This is doable, you just need to keep it in mind, and the directory creation has to be done in stage 1.

About your script:
- You do not exec into anything, so of course you're getting an "attempted to kill init" error at the end. /sbin/init should exec into s6-svscan.
- If you're using slashpackage, do not add /library to ld.conf. /library is for static libraries, not dynamic ones.
- I realize you haven't trimmed it yet, but your script is extremely heavy for a stage 1 script. Bear in mind that stage 1 has no fallback and should be as short, simple and failproof as possible. Most of the functionality in your script can, and should, be moved into a stage 2 script that runs once the supervision tree and the basic logging infrastructure are in place and you have a small set of vital services to fall back to (mostly udevd and a getty). Stage 1 should just be "do the absolute minimum that is necessary for s6-svscan to run, then fork a stage 2 script, and hand off process 1 duties to s6-svscan".

Cheers,

Okay, so the question I need an answer is, do I need to install sysvinit to provide the core init program and then reroute /etc/rc.d/init.d/rc to s6-svscan? This is where I'm a bit lost.

With Runit we could effectively close the book on sysvinit, or use Runit with sysvinit as a backbone for utility work as other distributions had, but with s6 that not very clear. Runit had runit-init which effectively replaced sysv's init executable. With s6, I'm uncertain as it lacks an init executable.

Btw... Need to report that I had a severe crash today due to an aging hard drive so LFS is being rebuilt at the moment.

No, you don't need sysvinit. I only mentioned sysvinit for the "reboot -f" and "poweroff -f" utilities, sorry if it confused you.
s6 works just like runit, except that the 1, 2 and 3 scripts run as process 1 instead of being directed by runit-init.
All runit-init does is fork /etc/runit/1, then /etc/runit/2 when 1 has finished, then /etc/runit/3 then 2 has finished. s6 does without it - it's not needed.

As a first approximation, you can:
* Concatenate /etc/runit/1 and /etc/runit/2 from LFS-runit and use it as /sbin/init for LFS-s6
* Replace "exec runsvdir" with "exec s6-svscan -t0" in /sbin/init
* Use /etc/runit/3 from LFS-runit as /service/.s6-svscan/finish for LFS-s6
and you will have something that's close to working. runit and s6 use the same basic idea, but runit babysits your 1, 2 and 3 scripts whereas s6 does not.

Sorry if I'm still lost Laurent, but what do we use for init if we don't have runit-init or sysv-init (init) binary executables?

This is where I'm a bit lost at things, so forgive me if I'm not following or understanding. If we link /sbin/init to a binary executable which binary of s6 do we use to bind init=/sbin/init to to gain a functional init executable binary that is recognized as a binary to load the system?

Stage-1 for Runit was a system agnostic configuration script to work with runit-init to direct the method of execution in what to load, how to load it, and then execute out to stage-2 to load the /var/service directory run files. We formulated out our stage-1 script from examples used by ArchLinux, Debian, etc. Runit-init once initialized passed to runit which loaded stage-1 and then after loading the one-shot scripts/executions, passed those off to stage-2 in which runsv took over loading the stage-2 run scripts.

Is the stage-1 script for s6 exactly the same working as a configuration for a binary of s6 that's symlinked to /sbin/init?

You said s6-svscanctl was used to shutdown, halt, and reboot the system, but what exact binary, not a script, is the init program?

Let's clear up the confusion here.
I use "/sbin/init" as the name of the program, on the filesystem, that is run by the kernel at boot time.
I use "process 1" to refer to the entity that is created by the kernel at boot time, and that stays alive until the machine is shut down.
Those only have to be the same thing at boot time. They do not have to be the same thing later on.

/sbin/init is nothing special. It can be any executable or script, or symlink to an executable or script. The only peculiarity of /sbin/init is that it is run as process 1, so it must not die, or the machine crashes. But process 1 does not have to be a binary, or the same binary at any given time. The executable that is running as process 1 can execve() into another one, and this will work, provided the new executable doesn't die either.

Try this:
-----
mv /sbin/init /sbin/init.real
cat >> /sbin/init <<EOF
#!/bin/sh
echo "I'm in ur init, writin to ur consoel"
sleep 3
exec -a 'My Little Init: Scripting Is Magic' /sbin/init.real
EOF
chmod 755 /sbin/init
-----

When you next boot your system, process 1 will be a shell script, that will print a message to /dev/console, then sleep for 3 seconds, then exec into your "real" init system. Which could also be a script for all you know and care, as long as it does not die. As a bonus, if your "real" init system is a binary, it will now display a fancier name in ps (unless it changes its argv[0] itself, which would be a shame).

Traditional init systems, as well as runit, have a unique binary that the kernel can run as process 1, and that stays running for the whole machine lifetime. But it's a choice of those systems, it's not a Unix requirement.
s6 makes another choice. There is one long-lived program, s6-svscan, that runs as process 1 for most of the machine lifetime; but the kernel does not boot on it. /sbin/init, what the kernel boots on, is a script, that performs a few actions and then execs into s6-svscan, which will handle process 1 duties until you tell it (via s6-svscanctl) to shutdown. /sbin/init is very similar to the above script, except it does actual stuff instead of sleeping for 3 seconds, and execs into s6-svscan instead of /sbin/init.real.

You have to write the /sbin/init script by hand because what to do before running s6-svscan is system-dependent and policy-dependent, so it's not s6's place to enforce it - just as the runit distribution does not include a stock /etc/runit/1 script. The best I can do is provide an example, which the s6 package does. If you need it, we can go through the example line by line when I get more time.

Please read http://skarnet.org/software/s6/s6-svscan-1.html again, and please tell me what is unclear and how I could word things better for it to be easier to understand.

I think it deals on part with understanding execline's syntax versus shell scripting syntax. After that, because our formulations work on developing a system based on these designs:

1. Using a single partition, or root+boot dual partition scheme. We avoid using the broken down quota scheme.

2. System must retain some ability to be backwards compatible with sysvinit scripting from the stage-1 process line for one-shot scripts or scripts requiring continual handling.

3. Package must be, to a point, system agnostic to where it can be mass deployed, even with the loss of some aspects of features to promote a viable alternative to sysvinit, rather than a replacement, or a custom-fit-per-installation init and service manager package.

Because we had a Debian, ArchLinux, Gentoo, and other examples based on shell scripted syntax to develop off from, transitioning to Runit from SysV was rather painless.

Laurent, I know this may sound like it's asking a lot, but could you post a tarball containing your own s6-init script set? I'd like to see how your system loads and handles everything so we can get an idea of how our system and services can be utilized.

The suspension of the project confirms what I was suspecting: accessibility and ease of installation are definitely the most important issues of s6 right now. Improvements on those aspects is my first priority.