Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yes, we aren't alone. A lot of people are taking notice that alternatives are needed not just to sysvinit, but systemd, upstart, and OpenRC as well. Alternatives that are small, simplistic, and work with the system rather than making the system work with it. Plus the backwards compatibility between Runit and sysvinit is exemplary, as our work clearly shows. Last I heard systemd now removed sysvinit script compatibility and uses a parsing tool to take sysvinit scripts and auto-convert them to systemd unit files.
Upstart was never a viable option in my opinion, and OpenRC is too undocumented to be of any real usage.
Taking a little extra time to thoroughly check everything out, so I don't want to give an exact date on this.
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 (ported - completed) fcron (ported - completed) gpm (ported - completed)
haveged
httpd - (Apache httpd daemon) iptables (backported to stage 1 - not required)
ipx (system service script. Possible assignment to stage 1.) kdm (ported - completed)
krb5 mysql (ported - completed)
netfs
NetworkManager
nfs-client
nfs-server ntpd (ported - completed)
php-fpm postfix (ported - completed)
postgresql
proftpd random (assigned to stage 1 - not required)
rpcbind
rsyncd 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 - (was part of Samba initially, but seems to not be used any longer. Will remove if necessary.) sysstat (assigned to stage 1 - not required)
unbound
virtuoso
vsftpd
wicd
winbindd - part of samba.
wpa ( system service script. Will probably be assigned to stage 1.)
xinetd
xnmap
zenmap
Here are some service scripts that may need testing, I got a few from Runit's collection, some from VoidLinux, and others just from anywhere I found anything:
These are all the scripts I could find off-hand. The rest will either have to be created from the ground up, scavenged off other distributions and updated, or if necessary migrated into stage-1 using an if/elif/else trigger.
To be perfectly honest, Runit could be a major player in init for GNU/Linux, but only if enough advocacy would come forward for it, and distribution maintainers would design around it. It's a very stable init system, is fully compatible with sysv, and is fast, light, and simplified as a service manager.
How and why system designers never jumped on this, djbdts, perp, etc, really is confounding since they knew sysvinit and bsdinit would eventually need a successor. How the tools of Gerrit and Laurent never got mainstream (Runit and s6) just shows that there are too many people who have too many stigmas about trying new sound and sane software, and only look for quickie fix solutions regardless of how corrupting they are rather than anything sane.
I created a backwards compatible sysvinit run file as shown below. It's very crude and needs to be thoroughly tested. This is hopefully to cover enough services as possible, until a full set of scripts for these services can be designed.
I'm uncertain of the shutdown mechanics of the finish file, but hopefully, it will work.
Seems interesting that I keep finding more and more little known distributions running Runit. A lot of the work is heavily streamlined and easy to read.
The stage 1, 2, and 3 scripts from both Ignite and Void are a little more comprehensive than ours are. I may see about reworking them to fit out needs, and see about importing their Shutdown script.
I think that's to give an emergency Superuser shell in case something fails in stage 2. It's actually not a bad idea. I've been considering the aspect of moving more stuff into stage 2 and consolidating a more universalized stage 1.
I'm going to see the structuring of the Void and Ignite Runit stage 1 and see how it reflects against the LFS sysvinit scripts and see if I can rework the Void stage 1 into a usable bootscript for LFS.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.