. . . . . A 66 FAQ document
Is 66 different than s6 or an alternative to it?
NO! 66 is a layer of software on top of s6 that makes s6 easier and more understandable to users with little or no experience in unix-system-administration. 66 takes bundles of complicated s6 commands and scripts and simplifies them into 66 commands that help you customize and optimize your system just the way you need. Experienced enterprise lever administrators are not limited by 66 in any way, it only makes monitoring their systems easier and quicker.
How is Skarnet’s S6 altered in Obarun or by 66-software?
It isn’t. s6 and its related libraries are ported into arch-linux from Skarnet unaltered. Any questions, bugs, detailed documentation about s6 employment should be directed to skarnet. In detail references to s6 documentation are concentrated here: 66 software
Where does s6 start and end and where does 66 begin?
s6 is there from the initial instruction of the boot loader till the system shutsdown. 66 makes s6 work, it manages s6 so you don’t have to. The standard recommended setup in Obarun, or anywhere 66 is implemented, begins with a bundle of initial services that is called boot-tree (it is the first tree on standard Obarun installation, but it can be called anything and re-written. The important part of this tree is that it is the first tree that is active when the system boots). A tree is a bundle of services, daemons, procedures, that you can customize. Unless you become proficient in s6 it is recommended to leave boot-66serv alone. boot-66serv replaces the previously used s6-boot. Check table_1 below for what boot-66serv tree includes. Also note the classification of services as one-shot, classic, longrun, which should give you a clue of what this terminology means. For example, the second step after defining the root of the filesystem within the disk is to set the hostname. This is not a service that should continuously run, the hostname is set and it is done with. tty12 is set as the minimal tty available to the physical user of the system at all times, so it is labeled as a classic service. When nothing else works tty12 (Ctrl-Shift-F12) should be available to correct any situation. For security reasons tty12 is set to not allow direct root login. You can login as a user and if the user has privileges to do administrative work it can, or if not blocked su (superuser) can login from the user account. It is an added layer of security to password cracking assaults coming from the network. Everyone knows there is a root user in a linux based system, guessing the correct user name and password is a little harder.
What happens after boot procedure is complete?
The default minimal 2nd tree, as you may see in the obarun-live-systems is root. Root, in an obarun installed system, is the second tree that is enabled and it begins when boot-tree has successfully been completed. If you install obarun from scratch, from a minimal arch base system, you may have installed everything from s6-suite (most likely this will become 66-suite after June), there is no active tree in the system. You have to install the boot tree (boot-66serv) or make a boot tree on your own. Then you can make a root tree (a 2nd tree) or install root-66tree (you can choose other names, boot and root are not mandatory in any way). You can call your tree bubba or anything you like, as long it contains the services you need to start your system. By default root-66tree only enables two more tty’s (tty1 and tty2). The template for creating ttys is tty@-66serv. To get a login screen after boot you need tty1. If it doesn’t come up you can try tty12 and it will be there. If on tty1 you log in and start X, you are automatically thrown to tty2, leaving tty1 available to kill the X server if something has gone wrong.
It is important to understand here the distinction about boot tree and second tree. If on the second tree (root in Obarun live) you mess something up and you reboot the system, you are not locked out, as you still have a system that booted but got stuck on a later stage. Unless you mess boot-tree up, tty12 will always be there to access the system. You login as user, jump into su, and fix what is broken.
# 66-enable -t root -S tty@tty3 this command adds tty3 to tree root and starts it. After issuing it you can press Ctrl-Shift-F3 and see a login screen.
If your installation is intended for a server you only access through ssh for security reasons you can disable ttys or even a second tree of services. You can add sshd and a network service to boot (1st tree) and let it run what it is supposed to run. You may have a root tree with enabled services but unless you use 66-all to start the services in this tree nothing will run automatically.
Do you need network configured after boot? You can use dhcpcd, connmand, network-manager, wicd, wpa-supplicant for wifi, you add them to your root tree. Most desktops and some of their applications require dbus running at the root level, you add it there, and if you use a display-manager such as sddm, you add this as well. For a current list of service scripts available see table 2 near the end of the article. Your command to create, enable, and initialize the tree named root is as follows:
# 66-tree -cnE root
To add services to this empty root tree and start them:
# 66-enable -t root -S tty@tty1 tty@tty2 dbus dhcpcd wpa-supplicant sddm ntpd
See examples (Table_4) of what information you can get running 66-info ( -T for tree and -S for service)
What if you want to use services at the user level, available to the specific user and started only if this user logs in?
The previous procedures were all at the root level. This means that even if nobody has logged in to the system yet, after boot is complete, all the services at root level are started. In other words if you need the system to be a file server using ssh you enable sshd at the root tree and your server is up and running without physical login. A couple of users in the Obarun forum wanted to install and run KDE-plasma. They followed different approaches and both succeeded. One of the requirements by this desktop is to have dbus running as a user, separately from the root level dbus.
To have user level services run the procedure is similar as for the root. Only for s6 to supervise users services /run/66/scandir should have a directory created with your user number (default first user is 1000 while root is 0). To have this proper directory structure created after the system is booted you should have at least one user tree active and current that includes xdg-user-dirs-66serv and also run 66-scandir -cu which will begin the scandir (scanning for service scripts to run and supervise in the user directory.)
. For example (you run these commands as user, not root):
% 66-tree -cnE plasma-tree % (66-scandir -cu ) & % 66-enable -t plasma-tree -S xdg-user-dirs dbus-user % 66-info -T plasma-tree
The first command creates a tree named plasma-tree, enables it, and makes it current and active. The second command enables the xdg-user-dirs and dbus (user level) in user tree named plasma-tree and also immediately starts them (-S, optional). The third command begins a user level scanning of service supervision. The fourth command verifies that those two services are active.
If later you wanted to shutdown one or more user services either at the next login or immediately you issue the following:
$ 66-stop -t plasma-tree dbus-user ## or $ 66-disable -t plasma-tree -S dbus-user ## disables dbus-user and stops (-S) it immidiately $ 66-info -S dbus-user ## this shows you the status of a particular service $ 66-info -T plasma-tree ## shows you the status of your user tree
if you no longer need a tree you created, simply issue:
$ 66-tree -R plasma-tree
Compared to other systems, or the previous version of Obarun service management script, is 66 using more system resources?
If you check on your task monitor, or run pstree, while your system is running you will see there is no trace of 66. 66 tools run momentarily, fast, and effective, set s6 to do what it does best. All 66 tools run so fast you will hardly ever see them run. What is running in the background is s6-svcscan and s6-supervise. Both are very light and efficient and use very little of your machine’s resources. They are exactly what you would find on any system running s6, including all the servers at skarnet.org
If s6 and 66 are so good why aren’t more distros adopting them yet?
There are many good things in this world that are not promoted, financed, and marketed by large corporations and banks, so many people do not know of them. Many of the people who do know about s6 and are part of the decision process in any distribution, understand how superior s6 is, but fail to invest enough time to learn and understand it. They escape to simpler or more familiar systems (such is the case with the aging sysV). Systemd advocates in most cases conveniently disregard the existence of current and modern alternatives and pretend that the choice is between sysV and systemd.
One developer (of a nameless distro) told me that part of their effort was to “keep it simple” and although s6 is good it is too complex. When I countered this by saying that 66 makes s6 simple and manageable, for both distro-designers and users, he responded with an unreasonable-argument. that “66 is a set of binaries and they would rather stick with the simplicity of “scripts“.
This is really a fallacious arguments because :
1) All files of s6 service are kept as they were and used at /var/lib/66/system/<tree>/servicedirs/{svc,db}/<service> . So the frontend is just a wrapper around the original s6,s6-rc file services declaration. One file that deals with all files from s6,s6-rc but the result is written physically on the hard disk and can be audited by the sys-admin. One file to deal with is even more simplistic than a ton of files to review and rewrite.
2) s6-rc service uses binary mode. Yes services are compiled on a binary database. So at the base s6-rc uses binary mode. This is completely transparent for an user/admin with 66 because it deals with it automatically.
Very few desktop users would get into learning how to modify scripts to set their system up. So they settle for a “one size fits all” type of solution that distro-designers create for “the average user“. They end up with an inefficient system, having too many services running, because those are what “many people” need.
For example you install a popular disto and you have Cups (a printer server) run all the time, even though you don’t own a printer or plan to ever print. This also separated the system experts from the users, and this gap is only widening. People make great careers and earn money modifying scripts, some do it for decades. Users don’t ever get to modify them in enterprise systems and “script modifiers’ careers are safe”. In many cases you get an enterprise server grade system to use as personal computer. Only if you were able to install the same desktop on Mint, Ubuntu, Manjaro, Antergos and compare with the same running on Obarun, see the disk space and ram used as soon as your desktop opens up. Only then you will realize the waste in resources involved by many “popular” linux systems.
So expect 66, and s6, to meet resistance at various levels but eventually it will shine. s6 and 66 are not intrusive into your system. They are designed and limited to start the system, manage services you need running, and be able to safely shut the system down when you want to. 66 doesn’t extend its limps into other layers of the system as the hydra of init systems, systemd, does.
Are these all of the 66 tools, or are there more?
You can see all the tools currently in this cumulative document about 66 which will eventually be moved into the wiki. Currently as s6-boot (init) and s6opts is being deprecated but still current till mid-June, it would be confusing to have both on the wiki.obarun.org. So all documentation for 66 is on http://web.obarun.org/software/ The list of all 66 tools can be found on Table_3. There may be more tools coming soon to simplify various tasks even more, as is backing up tree structure and configuration of services as well as restoring a previous setup. The tools used on the examples above are the most common and needed for a user to modify their system. If you install Obarun by the obarun_install script on the live image your system will boot and run without you needing to execute any 66 command.
Table_1
# 66-info -T boot boot Initialized: yes | Current: no Contains: | Enabled: no ├─(0,Enabled,oneshot) filesystem ├─(0,Enabled,oneshot) hostname ├─(0,Enabled,bundle) 00 ├─(0,Enabled,oneshot) rofs-kernmod ├─(443,Enabled,longrun) udevd-udev ├─(0,Enabled,oneshot) udevd-udevadm ├─(0,Enabled,bundle) rofs-Udevd ├─(0,Enabled,oneshot) checkfs-btrfs ├─(320,Enabled,classic) tty12 ├─(0,Enabled,oneshot) checkfs-dmraid ├─(0,Enabled,oneshot) rofs-cgroups ├─(0,Enabled,oneshot) rofs-console ├─(0,Enabled,oneshot) rofs-hardclock ├─(0,Enabled,oneshot) checkfs-lvm ├─(0,Enabled,oneshot) checkfs-fscheck ├─(0,Enabled,bundle) rofs-Checkfs ├─(0,Enabled,oneshot) rofs-modules ├─(0,Enabled,oneshot) rofs-swap ├─(0,Enabled,oneshot) rofs-kernruntime ├─(0,Enabled,bundle) all-Rofs ├─(0,Enabled,oneshot) rwfs-fsrw ├─(0,Enabled,oneshot) rwfs-random ├─(0,Enabled,oneshot) rwfs-tmpdir ├─(0,Enabled,oneshot) rwfs-iptables ├─(0,Enabled,oneshot) rwfs-ip6tables ├─(0,Enabled,oneshot) rwfs-loopback ├─(0,Enabled,oneshot) rwfs-nofilesystem ├─(0,Enabled,oneshot) rwfs-localtime ├─(0,Enabled,oneshot) rwfs-logfiles ├─(0,Enabled,oneshot) rwfs-end ├─(0,Enabled,oneshot) rwfs-dmesglog ├─(0,Enabled,oneshot) rwfs-66local ├─(0,Enabled,oneshot) rwfs-tmpfiles ├─(0,Enabled,bundle) all-Rwfs ├─(0,Enabled,oneshot) boot-extra └─(0,Enabled,bundle) All
Table_2 (the following are service scripts that must be installed as packages and are available for 66 to use, they will not be enable services unless you tell 66 to do so)
acpid-66serv 0.0.1-1 boot-66serv 0.0.1.5-3 (base s6-suite) connmand-66serv 0.0.2-1 consolekit-66serv 0.0.2-1 cupsd-66serv 0.0.1-1 dbus-66serv 0.0.3-2 dhclient-66serv 0.0.1-1 dhcpcd-66serv 0.0.2-1 dmraid-66serv 0.0.1-1 haveged-66serv 0.0.1-1 networkmanager-66serv 0.0.1-1 nfs-utils-66serv 0.0.2-1 nginx-66serv 0.0.1-1 ntpd-66serv 0.0.2-1 pgsql-initdb-66serv 0.0.1-1 php-fpm-66serv 0.0.1-1 postgresql-66serv 0.0.1-1 prosody-66serv 0.0.1-1 root-66tree 0.0.2-2 sddm-66serv 0.0.1-1 sshd-66serv 0.0.1-1 tty@-66serv 0.0.1-1 wicd-66serv 0.0.1-1 wpa_supplicant-66serv 0.0.1-1 xdg-user-dirs-66serv 0.0.1-1
Table_3
Admin tools
User tools
execline tools
Table_4
# 66-info -T root root Initialized: yes | Current: no Contains: | Enabled: yes ├─(807,Enabled,classic) tty1 ├─(808,Enabled,classic) ntpd-log ├─(19753,Enabled,classic) ntpd │ └─(808,Enabled,classic) ntpd-log ├─(811,Enabled,classic) dhcpcd-log ├─(810,Enabled,classic) tty2 └─(812,Enabled,classic) dhcpcd └─(811,Enabled,classic) dhcpcd-log # 66-info -S -p 8 ntpd ### -p 20 would print 20 lines of the log file ntpd on tree : root status : Enabled, up (pid 19753) 322 seconds type : classic description : ntpd daemon source : /etc/66/service/ run at : /run/66/scandir/0/ntpd dependencies └─(808,Enabled,classic) ntpd-log scripts start script : foreground { if -nt { s6-test -d ${RUN_DIR} } s6-mkdir -p -m 0755 ${RUN_DIR} } execl-cmdline -s { ntpd ${CMD_ARGS} } environment !CMD_ARGS=-d -s !RUN_DIR=/run/openntpd logger logger associated : ntpd-log log destination : /var/log/66/ntpd log file 2019-04-30 11:18:19.472897500 reply from 138.201.28.101: offset 0.001178 delay 0.115184, next query 31s 2019-04-30 11:18:21.729488500 reply from 82.193.117.90: offset -0.072065 delay 0.254361, next query 31s 2019-04-30 11:18:25.891679500 reply from 212.227.158.163: offset -0.035401 delay 0.157935, next query 30s 2019-04-30 11:18:29.997926500 reply from 192.33.214.47: offset 0.001311 delay 0.102090, next query 30s 2019-04-30 11:18:29.997945500 reply from 2a01:4f8:1c0c:6707::1: offset 0.005458 delay 0.102046, next query 32s 2019-04-30 11:18:29.997946500 reply from 217.79.179.106: offset -0.004038 delay 0.102029, next query 32s 2019-04-30 11:18:33.171296500 reply from 37.120.184.82: offset -0.040383 delay 0.170075, next query 32s
systemd-free linux community 
Thank you for the information. I’ve been interested in S6 for some time, do you recommend converting a distro like Void to S6 or starting out with Obarun or Adélie? And my last question have you used Alpine/Adélie’s apk tools to build a package from source?
LikeLike
Hi, I have been avoiding dbus too 🙂
Beyond studying the documentation for s6 I believe you will find the archives of the two discussion lists hosted at skarnet interesting.
I can’t recommend anyone in trying to convert Void to s6 using void’s pkgs, as I failed myself. The story as I understood is that someone took an interest out of an ongoing debate about runit and s6 to build s6, s6-rc, and libraries, for void. A void user took it upon himself to contribute porting 66 into void as well. By just installing what is available in the void repositories you will not get a bootable system. Further modification is necessary. Using pacman to install Obarun’s s6/s6-rc/66 as well as an arch kernel you get a bootable system. Trying it with a void kernel image hasn’t worked for me yet. Running one system with two disconnected/independent package managers is a pain in the neck.
I haven’t touched alpine in a long while, I basically installed it and wrote a review a while ago. Adelie is interesting but uses a mix of OpenRC and S6, the later is used for supervision. I haven’t tried much more on it, apk seems overly simplified. If I am missing something since I have a Void-musl installation on the next partition, I run void software, make links of missing libraries, and use them on Adelie. It beats building my own.
If you want a stable system to play around and learn s6 and 66, install Obarun and you will have a running system right away to explore. Void has a different way in building the kernel image and the system is structure to accomodate runit and this will not change. So s6 has to be modified extensively around an existing system and must substitute what runit does. This is an added complexity.
Void is also too complex to change its ways. Think of the combinations that everything has to work on. 32b/64bit x all those different architectures x glibc/musl
So, I expect to see you in the Obarun forum 🙂
LikeLike
trying to understand how Artix is different from obarun. Looked in those two forums but really didn’t find any clues. Thanks if you can shed some light here
LikeLike
Obarun begins as Arch, takes systemd/libsystemd (systemd libraries) out, replaces it with s6. Substitutes the systemd functionality of logind with consolekit2, for those who want to use software that require such functionality. Then it rebuilds a few software that “are packaged” in Arch having systemd functionality that don’t need to, and in general those that the Obarun community is interested in using.
Artix took arch, replaced systemd with OpenRC, and made a substitute libsystemd and elogind, for software to depend on. Then takes most common software that require systemd and rebuilds them and places them on its own repositories. About half the Arch software don’t require systemd running or present. So they remain available directly from arch repositories. Then artix added runit and made it possible to choose at any time between OpenRC or Runit. The transition is pretty simple. Artix aims to completely dissociate itself from Arch in the future. It is a move dependent on manpower and infrastructure. This means that pretty much anything that you find on Arch you will find in Artix, maybe more. There has been several cases that software has been dropped from arch repositories (core, extra, community) but can still be found on Artix.
Despite of Artix being the only one I know (there may be others) that provides full functionality and ease of switching between two init systems, there is recently a trend to force those two on the user. This means that you can not easily employ your own init system in artix, as key packages force the choice of Runit/OpenRC. To me that is a step towards the wrong direction.
Obarun claims it is not really a distribution, it is a layer of arch, in a Gentoo fashion, it is a modification of arch so you can utilize the power of S6. Although it is getting harder and harder to run such a distribution without systemd due to lazy developers upstream relying on systemd’s pseudo services (instead on more common basic linux services), and catering to RH, debian, arch.
I hate polarizing this response though to Obarun and Artix as being the only Arch without systemd, there are others. Hyperbola for one thing is a very respectable project. Hyperbola is FSF approved and a strictly libre distribution. I believe it still is available for 32bit systems when everyone else has abandoned this architecture. At some point I will work on a hybrid between Obarun and Hyperbola. Parabola and ArchBang have taken the easy mainstream path of systemd. One should not try to escape prison with prison guards as allies. Parabola is taking the pseudo-neutral direction of MX. For that reason you will not see a Parabola or an MX review here.
LikeLike