The work of @ProwlerGr which we looked at in the topic
(and in several previous topics which can be found by search for ‘init diversity’)
has now been incorporated into an antiX official release. The beta release is now available, and there will be a final release of antix25 in a couple of months.
This is a major step for antiX , because it marks the incorporation of 4 modern non-systemd init systems into the one .iso.
I thought we might take a brief look at what it is like to setup one service in each of runit, s6-rc, s6-66, ad dinit. I chose to use ‘setting up an NFS sever’ as the task.
Installing antix25-beta1
As with most new distros, it is safer to start with a VM install. I used virt-manager in Void Linux, and I downloaded the antiX-25-beta1_x64-full.iso file. The download link is
It is 2.1GB. I checked the md5sum.
It boots in virt-manager . You see a screen as follows
then follows a screen offering choices of init system
I first chose ‘normal boot’, and it boots to the following screen
That is live antiX.
It installs smoothly. On reboot I get a grub screen,
the top line of the grun menu automatically boots whatever /sbin/init points to , in this case runit.
and then login manager screen
which is nearly the same as the previous live boot, onlty this is the installed artiX.
It is the IceWM Window Manager.
The /etc/ directory contains config files for all 4 init systems, and /sbin contains startup files for all 4 init systems, but the actual running init process is the default ‘runit’
If I go to antiX Control Centre → Choose Startup Services I get the ‘Runit Service Manager’
and you can see there are 10 services running.
If you wanted ‘runit’ , that Normal Boot install would be OK, but you can switch it to a different init system simply by altering a pointer
That symbolic link called ‘init’ points to runit. If you alter it to point to eg) dinit and reboot, you will get antiX with dinit as the init system.
In the ‘normal boot’ option, grub will always boot with the init system that the /sbin/init pointer points to.
Lets now see what happens if you choose a specific init system.
Installing with dinit init system
I use the same antiX-25-beta1_x64-full.iso but chose ‘Dinit’ instead of ‘Normal’ . From the live screen I ran the installer, and rebooted.
On reboot, I see that process No 1 is /sbin/init and that /sbin/init is a pointer to dinit. So it is running dinit. Strange , I expected process No 1 to be ‘dinit’, but it shows the pointer?
Lets try one of the commands
Yes, seatd is running and dinit can check its status.
Unfortunately the Control Centre → System-> Choose Startup Services menu item does not work for dinit. It works for runit. I guess this is on the ‘todo’ list.
One can always start and stop daemons using dinit commands from the CLI. We shall see an example below.
So there is not much difference from the previous ‘Normal’ install. One still gets all init systems with their config files, only the default this time is dinit instead of runit. The grub menu now defaults to dinit.
Small things
the antiX FAQ still shows antiX23
there is no GUI to Choose Startup Services for dinit or s6-66
in antiX the default value of $TERM is xterm . This does not work well with vi. The default should be gnome-256color. It can be set with /usr/bin/env TERM=gnome-256color /bin/bash
Bigger things
it is indeed a brave move by antiX ditching sysVinit, which was the only fully working init system. It means they will have a whole raft of ex antiX23 users who are forced to tackle a new init system at a time when the 4 init systems on offer are only partially configured in relation to the package system. There needs to be some good getting started documentation.
there is a choice ahead. Either go the way Artix did and introduce subsidiary packages for each service package to supply the required service files
or
invent some way of making servoice packages detect which init system is running and install the appropriate service files with the service package ( the way sysVinit does)
or
invent some new way unique to antiX.
I would bet on the latter.
some explanation of how the installer and grub setup the multiple init systems , and how the grub menu works, would help beginners. I tried to cover that here.
Next
We need to look at how to start a service in each of the 4 init systems… 2 cases
when the service package is installed and there are service files present
Just an update. Sysvinit will be available on the next beta release, but runit will remain the primary init - not that it makes a difference because every init system is interchangeable (Source: antiX-25-full-beta1 for public testing – Page 18 – antiX-forum )
I think that will save your regular users a lot of headeaches. Most people who merely want an antiX that works out of the box will choose sysVinit… same applies to Devuan
thanks a lot for this great introduction of antiX25. You clearly put a lot of time and work into investigating and trying it out.
Your effort is greatly appreciated.
I might be interested on running antiX as a daily driver. Not right now, as my present Linux Lite 6.2 is still supported until April 2027. But I´d like to plan well in advance.
So I´m looking for a light-weight distro.
Other candidates may be Debian stable or MX Linux.
But staying on the antiX topic:
For antix25, what would your personal preference of init software be
Any advantage of one over another? Simplicity, rubustness or effectiveness?
Hi Rosika,
For home use, I prefer dinit, because its service files are the easiest to construct, its commands are simple, and it boots fast.
Other good home options are sysVinit and runit.
For a server s6-66 will compete with systemd
I would not recommend s6-rc for anyone
You will see more when I do the comparison of init systems
If I may illustrate how AI might be used in an acceptable manner…
Googel AI says
" SysVinit is the most tested and has a simpler, sequential script-based approach, making it robust and easy for beginners. Runit offers better performance, especially on multi-core systems, and has a simple service management structure but requires users to manage log files separately. Dinit is a newer, very fast, and simple option with a single process for both init and service management, but it is less widely used and may have higher dependencies."
I dont quite agree with it. Dinit has the simplest and best structure for its service files in /etc/dinit.d. Runit’s service files are scattered. SysVinit’s service files are complex scripts.
thank you very much for your assessment.
That is great help indeed.
As I know you´ve been experimenting with different init software models I thought it might me wise to ask you about it. You´re quite the pro .
Great. This is a clear statement. I will look into it.
Thanks also for presenting an example of a good and accepted use of AI.
Your comments are very helpful too.
I also like the fact that you included the relevant links.
If you have not seen antiX before, you will notice a few things that are unique, especially in the UI.
You probably got the default runit init system … yes runit and dinit boot fast, because they parallelize the startup. In a VM, dinit is about 10 secs to startup.
Hi @ProwlerGr ,
This is becoming interesting.
In the beta1 release you seem to have divorced packages from service files … all the service files for all 4 init systems seem to have been installed by hand by the developers.
but
That is not the way sysVinit used to work in Antix. Its packages used to install service files. … like the way sysVinit works in Devuan.
I actually came across a residue of this using antiX25/dinit… I installed spice-vdagent package, and it put service scripts in /etc/init.d… ie for sysVinit.
What are you going to do.?
I think you have to keep the packages service-file-free, and supply a heap of pre-installed sysVinit service files?
Longer term there might be a better way.
Instead of following Artix, you could make one package that installed all the services files for one init system. That would only be 5 packages. … a bit like firmware packages.
I think that would be maintainable and extendable.
Just some thoughts.
I am slogging thru examples for each init system
I have no definitive answer for sysvinit (most likely will remain like debian/devuan), but for the new modern inits it will be a bit different but very simple & consistent for each init
If you want to install spice-vdagent for a specific (or your desired) init you will just need to run
for runit: apt install runit-service-spice-vdagent
for dinit: apt install dinit-service-spice-vdagent
for s6-rc: apt install s6-rc-service-spice-vdagent
for s6-66: apt install 66-service-spice-vdagent
apt will pull & install all relevant dependencies & service files for spice-vdagent on your desired init
Maybe test xrdp or samba as good examples (spice-vdagent may not be yet available at this beta stage)
Thanks.
You are going in the same direction as Artix. That will be excellent.
I am looking for good examples at the moment
I tried nfsd, but that is a rather complicated service with a kernel component and dependencies. … not a good one to start with .
Spice-vdagent is an important service for VM users… it enables cut and paste between VM and host. So keep it on your list. It is complicated too … there are 2 daemons, one starts at boot, the other starts whenever an X session is started.
Have nearly finished a set of examples where the service files are present. That is the easy case… people should start to learn there.
Starting and stopping services(daemons) when the init system service files are present
All init systems require one or more files ( called service files) which describe how to start and stop each daemon. The format and layout of these files varies greatly between init systems. Users of sysVinit will recall the files in /etc/init.dwhich are basically scripts... one script per daemon. Service files for the 4 init systems we have inartiX25` are located as follows
runit service files are in /etc/sv and /etc/runit and /var/service(or /etc/runit/runsvdir/default)
S6-Rc service files are in /etc/s6-rc and /etc/s6-linux-init
s6-66 service files are in /etc/66 (admin added files) , /usr/share/66 ( supplied system files) and ~/.66 (user added files)
dinit service files are in /etc/dinit.d (admin added files) , /usr/share/dinit (suplied system files) and ~/.config/dinit.d ( user service files).
In old fashioned init systems such as sysVinit service files typically came with the package that installed the service. So one simply installed the package and the service was started ( ie made to run) and enabled ( ie made to start at every boot).
That is only partly true for the 4 more modern init systems available in antiX25 beta release. Some packages ( eg sshd, cupsd, connmand, bluetoothd,…) have been provided ( preinstalled not with their packages) , but others ( eg vsftpd, nfsd, …) are not present, and the user is required to write service file(s) before attempting to start the service daemon.
Here we are going to look at the simplest case… how to start and stop a daemon in each of the 4 init systems, when the service files are present.
Runit service managenment
We will use sshd as an example, the package is installed, but sshd is not running at boot.
One needs to find the name of the service ( it is not necessarily the same as the name of the daemon). Look in /etc/sv…we see ssh not sshd … that is the service name. One can check with cat ssh/run … you will see the run script…yes the script starts sshd.
Next one needs to check in /etc/runit/runsvdir/current to see if the ssh service is currently controlled by runit. It is not. Another way to check is to use the Control Centre → Runit Service Manager GUI. It does not list ssh, but it can be used to add it.
then it appears in the list
and can now be seen as a file in /etc/runit/runsvdir/current ( actually it is a symlink pointing to /etc/sv/ssh
From here , one can either use the Runit Service Manager GUI to start/stop/enable/diable the ssh service, or one can use CLI commands as follows
To start or stop
sv up ssh
sv down ssh
To check its status
sv status ssh
To enable ( ie make it start at boot)
ln -s /etc/sv/ssh /etc/runit/runsvdir/default/
Yes runit uses links to enable services. Once a service is linked, it will automatically start immediately, it will always start at boot, and if it stops it will be restarted. That is called ‘supervision’ of services. Runit has supervision.
What we did adding a service with the GUI is equivalent to making the above symlink.
That is all there is to it. The biggest headache with runit is that every distro puts its service files in different locations. There is no standard layout.
To disable a service, remove the symlink.
s6-rc service management
s6-rc is the original S6 service manager.
We shall again use sshd as an example. The package is installed… it is the exact same package that we saw was installed using runit. AntiX separates packages from init system service files. So a package only needs to be installed once… it will work for all init systems. That is good design. Artix does that too.
As with runit, one needs to check what is the service name. Look in /etc/s6-rc/sv. We see two service files sshd-log and sshd-srv. S6 runs two supervisor processes called s6-supervise sshd-log and s6-supervice sshd-srv as well as the daemon itself. ( Contrast to runit which runs one supervisor process called runsv sshd plus the daemon). So the service name is sshd.
The s6-rc GUI is not in Control Center, it is in Applications → Preferences → s6-rc Dialogbox Manager.
In this case sshd-log and sshd-srv are in the GUI … we dont need to add them.
ps ax | grep sshd
259 ? S 0:00 s6-supervise sshd-log
274 ? S 0:00 s6-supervise sshd-srv
956 ? Ss 0:00 s6-log -d3 -b -- n3 s2000000 T /var/log/sshd
1015 ? Ss 0:00 sshd: /usr/sbin/ss e
So all we need to do is look at the service management commands
To start/stop sshd
s6-rc -u change sshd
s6-rc -d change sshd
the ‘u’ and ‘d’ stand for up and down.
Enabling a service in s6-rc is more complicated. You have to add it to a “runlevel” bundle. A bundle is a group of services. There is a bundle called ‘default’ which is useful for adding services which we wish to satart at boot time. To add sshd to it
s6-rc-bundle add default sshd
Then to ensure the change is loaded next boot
s6-rc-compile
Yes, you have to manually recompile the database.
To stop a service temporarily
s6-rc-bundle stop sshd
and you dont recompile , so after a boot the service will be back.
I am not sure how much of that can be done in the GUI. It seems to have add, restart, and stop buttons.
s6-66 service management
s6-66 is S6 with the original service manager replaced by 66.
We shall again use sshd as an example. The package in installed. The service files are in /etc/66 (admin added system files) and /usr/share/66/service (supplied system files) like sshd and ~/.66 (user service files). The service is running and it is a system service… if it was a user service the service files would be in ~/.66.
$ ps ax | grep sshd
786 ? S 0:00 s6-supervise sshd-log
787 ? S 0:00 s6-supervise sshd
877 ? Ss 0:00 /usr/bin/s6-log -d3 n3 s1000000 /var/log/66/sshd
926 ? Ss 0:00 sshd: /usr/sbin/sshd -D -e -f /etc/ssh/sshd_config [listener] 0 of 10-100 startups
Compared to s6-rc, s6-66 avoids compiling a database, and it has a ‘frontend’ file instead of an execline script. 66 has ‘trees’, which are like bundles, and it allows users to manage services, as well as root.
There is a global tree which is the default and is present at install time, and is always enabled ( ie it starts automatically at boot time). New services default to the global tree , unless another tree is specified.
There is a boot tree which contains various services needed when the system boots. There is a tree called ‘session’ which containes modules which setup an environment in which a user can manage services.
Other user-defined trees can be created. A service can only belong to one tree.
Any type of service can belong to a tree, even a module service.
There is a directory /run/66/scandir/… containing, for each user, the compiled version of the frontend for each running service, plus a number of status files. For root it is /run/66/scandir/0/…, for the first user it is /run/66/scandir/1000/… There is a special admin command to manage scandirs.
The root scandir is automatically created. A user scandir must be initialised with the 66 scandir … command, before any user services can be started.
We can look at the trees in the default setup ( as installed)
nevj@antix1:~
$ 66 tree status
Name : global
Current : no
Enabled : yes
Allowed : nevj
Groups : user
Depends : None
Required by : None
Contents : dbus@nevj-log dbus@nevj
A user can only see the global tree.
root@antix1:~# 66 tree status
Name : global
Current : no
Enabled : yes
Allowed : root
Groups : admin
Depends : None
Required by : session
Contents : seatd-log seatd dhcpcd-log dhcpcd acpid-log acpid cron-log
cron haveged-log haveged alsa-log alsa alsa-restore
dbus-log dbus sshd-log sshd ufw bluetoothd-log bluetoothd
connmand-log connmand slimski-log slimski cupsd-log cupsd
Name : boot
Current : no
Enabled : no
Allowed : root
Groups : boot
Depends : None
Required by : None
Contents : boot@system boot@system:system-hostname boot@system:mount-run
boot@system:mount-tmp boot@system:populate-sys
boot@system:mount-pts boot@system:mount-shm
boot@system:populate-dev boot@system:mount-cgroups
boot@system:system-sysctl boot@system:tty-earlier@tty12
boot@system:populate-run boot@system:populate-tmp
boot@system:mount-branch boot@system:system-hwclock
boot@system:system-random boot@system:udevd
boot@system:udevd-log boot@system:udevadm
boot@system:system-fontnkey boot@system:system-fsck
boot@system:system-branch boot@system:mount-rw
boot@system:mount-swap boot@system:local-loop
boot@system:local-sethostname boot@system:local-time
boot@system:local-authfiles boot@system:local-rc
boot@system:local-dmesg boot@system:local-branch
boot@system:runtime-branch boot@system:canopy
boot@system:tty-rc@tty2 boot@system:tty-rc@tty1
Name : session
Current : no
Enabled : yes
Allowed : root
Groups : admin
Depends : global
Required by : None
Contents : scandir@nevj:svscan@nevj scandir@nevj:svscan@nevj-log
scandir@nevj boot-user@nevj:mount-run@nevj boot-user@nevj
Root can also see the boot tree and the session tree.
Notice that sshd is in the global tree… therefore it will start at boot.
Here are some things we can do with 66 commands.
Start/stop a service immediately
66 start sshd
66 stop sshd
Enable a service ( this will put it in theglobal tree)
66 enable sshd
Disable a service ( this will prevent it starting at boot)
66 disable sshd
Show status of a service
root@antix1:~# 66 status sshd
Name : sshd
Version : 0.0.2
In tree : global
Status : enabled, up (pid 926 pgid 926) 2152 seconds
Type : classic
Description : ssh daemon
Part of : None
Notify : 0
Max death : 5
Earlier : 0
Source : /usr/share/66/service/sshd
Live : /run/66/scandir/0/sshd
Dependencies : sshd-log
Required by : None
Optional dependencies : None
Start script :
#!/usr/lib/execline/bin/execlineb -P
/usr/lib/execline/bin/foreground { if { test -e /etc/ssh/sshd_not_to_be_run } 66 stop sshd }
/usr/lib/execline/bin/foreground { bash -c "if id -u sshd >/dev/null 2>&1 ; then exit 0 ; else /sbin/useradd -r sshd -s /bin/nologin >/dev/null 2>&1 ; fi" }
/usr/lib/execline/bin/foreground { mkdir -p /run/sshd }
/usr/lib/execline/bin/foreground { chmod 0755 /run/sshd }
/usr/lib/execline/bin/foreground { /bin/ssh-keygen -A }
/usr/lib/execline/bin/foreground { touch /var/log/lastlog }
/usr/lib/execline/bin/foreground { chgrp utmp /var/log/lastlog }
/usr/lib/execline/bin/foreground { chmod 664 /var/log/lastlog }
execl-cmdline -s { /usr/sbin/sshd ${Args} }
Stop script :
None
Environment source : /etc/66/conf/sshd/0.0.2
Environment file :
environment variables from: /etc/66/conf/sshd/0.0.2/.sshd
Args=!-D -e ${ArgsConfFile}
ArgsConfFile=!-f /etc/ssh/sshd_config
Environment ImportFile : None
StdIn : s6log:/run/66/scandir/0/fdholder
StdOut : s6log:/var/log/66/sshd
StdErr : inherit:/var/log/66/sshd
Logger name : sshd-log
Logger file :
66-execute: info: Starting service: sshd
Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.
66-execute: info: Starting service: sshd
Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.
Status gives a mountain of information.
There is a lot more than that to s6-66. The concept of user-controlled services is new to me and I do not yet have a grasp of why one would need user-controlled daemons. The way to use trees to manage a large set of services in a server computer something I have not mastered.
Beware reading older web-sites on 66 . 66 is evolving and the command syntax has changed. Older sites may have 66-start <servicename>, but the modern form is 66 start <servicename> … ie it is now like git… 66 is the command and start is a subcommand.
We were fortunate to get some contributions and assistance on this forum from the developer of 66, @oberun (Eric Vidal). See this topic
66 has its own demonstration distro, called Obarun Linux
s6-66 is definitely easier to use than s6-rc, and it does not sacrifice any of the sophisticated service management abilities. S6 is definitely a competitior with systemd. Their capabilities are similar.
Dinit service management
Dinit is different to runit and S6. Dinit does not have separate supervising and logging processes for each daemon. Those functions are performed, for all daemons by a single process called dinit which also acts as process no 1 ( the init process). What you see running is
$ ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:00 /lib/dinit/dinit
2 ? S 0:00 [kthreadd]
.....
plus one process for each daemon. For example
601 ? Ss 0:00 /usr/libexec/bluetooth/bluetoothd
602 ? Ss 0:00 /usr/sbin/cupsd -f
603 ? Ss 0:00 /usr/bin/slimski -nodaemon -z -i
617 ? S 0:00 /usr/bin/dbus-daemon --system --nofork --nopidfile --
628 ? S 0:00 sshd: /usr/sbin/sshd -D -e -f /etc/ssh/sshd_config [l
There you see 5 daemons runnning.
In AntiX25 the daemon sshd starts at boot by default and its service file is in /usr/share/dinit/services… so it is a system wide service suplied with the distro. Its service file is simple
type = process
command = /etc/dinit.d/scripts/sshd
depends-on = loginready
No script at all, just a declaration… the binary to start is called sshd and it depends on a process called loginready.
The command that controls services in dinit is called dinitctl. It has subcommands like git.
To start/stop a daemon such as sshd …
dinitctl start sshd
dinitctl stop sshd
To check service status. Dinit in AntiX25 does not yet have a GUI service manager . You have to use CLI as follows to check on services.
dinitctl status sshd
To enable a service so it will start at boot
dinitctl enable sshd
That is all. Dinit is simple , but not without capability. It can bundle services, like s6-66, it allows users to setup services, it provides service supervision, it does parallel startup of services.
Discussion
I have tried to illustrate the simple task of starting and stopping services in each of the 4 init systems, and, I have added a few explanatory comments along the way.
The result is a messy article, but I hope it will help people to see that init systems are nothing to be afraid of.
There is far more to it , of course. We need to move on to what one needs to do if a service file is not available for a particular service
thank you very much for this great comparison of init systems.
I can´t even begin to imagine how much time you must have put into the project.
Great effort - and great result.
The antiX services that we looked at in reply no13 are all system services present at boot.
If you need some service ( eg samba) which does not have service files present by default , your first option is to look at the package system and see if they can be installed.
The package system in antix25 beta1 has packages with names like runit-service-samba or dinit-service-samba or 66-service-samba which install service files for the package samba. So you simply inatall package samba and the appropriate xx-service-samba package.
We can look and see how much progress has been made with service packages in antix25. Just search the repository as follows
$ apt-cache search runit-
runit - system-wide service supervision
runit-antix - system-wide service supervision
runit-antix-dbgsym - debug symbols for runit-antix
runit-core-services-antix - runit core service scripts (one-shot) for antiX runit editions
runit-dbgsym - debug symbols for runit
runit-full-core-services-antix - runit core service scripts (one-shot) for antiX full runit editions
runit-init - system-wide service supervision (as init system)
runit-init-antix - system-wide service supervision (as init system)
runit-init-antix-dbgsym - debug symbols for runit-init-antix
runit-init-diversity - system-wide service supervision
runit-init-diversity-dbgsym - debug symbols for runit-init-diversity
runit-run - service supervision (systemd and sysv integration)
runit-service-acpi-support - runit service files to manage acpi-support.
runit-service-acpid - runit service files to manage acpid.
runit-service-anacron - runit service files to manage anacron.
runit-service-avahi-daemon - runit service files to manage avahi-daemon.
runit-service-bluetooth - runit service files to manage bluetooth.
runit-service-boot-module - A collection of essential scripts to boot a debian system using runit.
runit-service-chrony - runit service files to manage chrony.
runit-service-connman - runit service files to manage connman.
runit-service-cron - runit service files to manage cron.
runit-service-cups - runit service files to manage cups.
runit-service-dbus - runit service files to manage dbus.
runit-service-dhcpcd - runit service files to manage dhcpcd.
runit-service-elogind - runit service files to manage elogind.
runit-service-gpm - runit service files to manage gpm.
runit-service-haveged - runit service files to manage haveged.
runit-service-libvirtd - runit service files to manage libvirtd.
runit-service-lightdm - runit service files to manage lightdm.
runit-service-lxdm - runit service files to manage lxdm.
runit-service-manager - Manage runit services
runit-service-mpd - runit service files to manage mpd.
runit-service-network-manager - runit service files to manage network-manager.
runit-service-ofono - runit service files to manage ofono.
runit-service-rpcbind - runit service files to manage rpcbind.
runit-service-rsync - runit service files to manage rsync.
runit-service-rsyslog - runit service files to manage rsyslog.
runit-service-samba - runit service files to manage samba.
runit-service-seatd - runit service files to manage seatd.
runit-service-slim - runit service files to manage slim.
runit-service-slimski - runit service files to manage slimski.
runit-service-smartmontools - runit service files to manage smartmontools.
runit-service-spice-vdagent - runit service files to manage dhcpcd.
runit-service-ssh - runit service files to manage ssh.
runit-service-udevd - runit service files to manage udevd.
runit-service-xrdp - runit service files to manage xrdp.
runit-services-base-antix - extra runit service scripts for antiX runit base editions with an X environment
runit-services-core-antix - extra runit service scripts for antiX runit core editions without X environment
runit-services-full-antix - extra runit service scripts for antiX runit full editions with an X environment
runit-services-net-antix - basic runit service scripts for antiX net runit editions without X environment
runit-helper - dh-runit implementation detail
golang-github-prometheus-community-go-runit-dev - Go library wrapping runit service status
golang-github-soundcloud-go-runit-dev - transitional dummy package
runit-services - UNIX init scheme with service supervision (services)
$ apt-cache search dinit-service
dinit-dialogbox-manager - Provides a simple qt5 user graphical user interface to manage dinit services .
dinit-service-acpid - dinit service files to manage the acpid service.
dinit-service-bluetoothd - dinit service files to manage the bluetooth service.
dinit-service-boot-module-antix - Essential service module to fully boot debian with dinit.
dinit-service-connmand - dinit service files to manage the connman service.
dinit-service-cron - dinit service files to manage the cron service.
dinit-service-cups - dinit service files to manage the cups service.
dinit-service-dbus - dinit service files to manage the dbus service.
dinit-service-dhcpcd - dinit service files to manage the dhcpcd service.
dinit-service-elogind - dinit service files to manage the elogind service.
dinit-service-haveged - dinit service files to manage the haveged service.
dinit-service-lightdm - dinit service files to manage lightdm.
dinit-service-networkmanager - dinit service files to manage network-manager.
dinit-service-samba - dinit service files to manage the samba service.
dinit-service-seatd - dinit service files to manage the seatd service.
dinit-service-slim - dinit service files to manage the slim service.
dinit-service-slimski - dinit service files to manage the slimski service.
dinit-service-sshd - dinit service files to manage the sshd service.
dinit-service-ufw - dinit service files to manage the ufw service.
dinit-service-xrdp - dinit service files to manage the xrdp service.
$ apt-cache search 66-service
66-service-acpid - 66 service module to manage acpid under s6-66.
66-service-alsa - 66 service module to manage alsa under s6-66.
66-service-apache2 - 66 service module to manage apache2 apache2 under s6-66.
66-service-bluetoothd - 66 service module to manage bluetoothd under s6-66.
66-service-boot - Essential 66 service module to boot a system with s6-66.
66-service-boot-user - 66 service module to configure user services.
66-service-brltty - 66 service module to manage brltty under s6-66.
66-service-chronyd - 66 service module to manage chronyd under s6-66.
66-service-colord - 66 service module to manage colord under s6-66.
66-service-connmand - 66 service module to manage ConnMan under s6-66.
66-service-consolekit - 66 service module to manage consolekit under s6-66.
66-service-cron - 66 service module to manage cron under s6-66.
66-service-crond - 66 service module to manage cron under s6-66.
66-service-cupsd - 66 service module to manage cups under s6-66.
66-service-dbus - 66 service module to manage dbus under s6-66.
66-service-deluged - 66 service module to manage deluged under s6-66.
66-service-dhclient - 66 service module to manage dhclient under s6-66.
66-service-dhcpcd - 66 service module to manage dhcpcd under s6-66.
66-service-dmraid - 66 service module to manage dmraid under s6-66.
66-service-dnsmasq - 66 service module to manage dnsmasq under s6-66.
66-service-dockerd - 66 service module to manage dockerd under s6-66.
66-service-dovecot - 66 service module to manage dovecot under s6-66.
66-service-elogind - 66 service module to manage elogind under s6-66.
66-service-fail2ban - 66 service module to manage fail2ban under s6-66.
66-service-gpm - 66 service module to manage gpm under s6-66.
66-service-greetd - 66 service module to manage greetd under s6-66.
66-service-gvfs - 66 service module to manage gvfs under s6-66.
66-service-haveged - 66 service module to manage haveged under s6-66.
66-service-libvirtd - 66 service module to manage libvirtd under s6-66.
66-service-lightdm - 66 service module to manage lightdm under s6-66.
66-service-lighttpd - 66 service module to manage lighttpd under s6-66.
66-service-lvm2 - 66 service module to manage lvm2 under s6-66.
66-service-lxdm - 66 service module to manage lxdm under s6-66.
66-service-mysqld - 66 service module to manage mysql & mariadb under s6-66.
66-service-network-manager - 66 service module to manage network-manager under s6-66.
66-service-nfs-utils - 66 service module to manage nfs-utils under s6-66.
66-service-nginx - 66 service module to manage nginx under s6-66.
66-service-ntpclient - 66 service module to manage ntpclient under s6-66.
66-service-ntpd - 66 service module to manage ntpd under s6-66.
66-service-openntpd - 66 service module to manage openntpd under s6-66.
66-service-openvpn - 66 service module to manage openvpn under s6-66.
66-service-openvswitch - 66 service module to manage openvswitch under s6-66.
66-service-php-fpm - 66 service module to manage php-fpm under s6-66.
66-service-postgresql - 66 service module to manage postgresql under s6-66.
66-service-prosody - 66 service module to manage prosody under s6-66.
66-service-rc-local-user - 66 service module to manage rc-local-user under s6-66.
66-service-rtkit - 66 service module to manage rtkit under s6-66.
66-service-samba - 66 service module to manage samba under s6-66.
66-service-scandir - 66 service module to manage scandir under s6-66.
66-service-sddm - 66 service module to manage sddm under s6-66.
66-service-seatd - 66 service module to manage seatd under s6-66.
66-service-slim - 66 service module to manage slim under s6-66.
66-service-slimski - 66 service module to manage slimski under s6-66.
66-service-spamd - 66 service module to manage spamd under s6-66.
66-service-spice-vdagent - 66 service module to manage openssh-server under s6-66.
66-service-sshd - 66 service module to manage openssh-server under s6-66.
66-service-ufw - 66 service module to manage ufw under s6-66.
66-service-xrdp - 66 service module to manage xrdp under s6-66.
s6-66-services - Deploys many (experimental) service scripts for use with s6-66 as the init system
$ apt-cache search s6-rc-service
s6-rc-dialogbox-manager - Provides a simple user graphical user interface to manage s6-rc services .
s6-rc-service-acpid - s6-rc service files to manage acpid.
s6-rc-service-avahi-daemon - s6-rc service files to manage avahi-daemon.
s6-rc-service-binfmt - s6-rc service files to manage binfmt.
s6-rc-service-bluetoothd - s6-rc service files to manage bluetoothd.
s6-rc-service-boot-module - A collection of essential s6-rc services to boot a debian system.
s6-rc-service-connmand - s6-rc service files to manage connman.
s6-rc-service-cups - s6-rc service files to manage cups.
s6-rc-service-dbus - s6-rc service files to manage dbus.
s6-rc-service-dhclient - s6-rc service files to manage dhclient.
s6-rc-service-dhcpcd - s6-rc service files to manage dhcpcd.
s6-rc-service-manager - Manage s6-rc services via an easy to use gui
s6-rc-service-rc-local-user - s6-rc service files to manage rc-local-user.
s6-rc-service-samba - s6-rc service files to manage samba.
s6-rc-service-seatd - s6-rc service files to manage seatd.
s6-rc-service-slimski - s6-rc service files to manage slimski.
s6-rc-service-spice-vdagentd - s6-rc service files to manage spice-vdagentd.
s6-rc-service-sshd - s6-rc service files to manage sshd.
s6-rc-service-ufw - s6-rc service files to manage ufw.
s6-rc-service-xrdp - s6-rc service files to manage xrdp.
s6-rc-services - Deploys many (experimental) service scripts for use with s6-rc as the init system
So progress is
runit 55
dinit 21
66 60
s6-rc 22
and one of each of those, for s6-rc and 66, is a package of experimental service files.
So there is considerable progress, especially for 66. You will more than likely find a service file package to meet your needs there.
The one that is least complete is dinit.
I test it out in s6-66
oot@antix1:/home/nevj# apt-get install 66-service-xrdp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
xorgxrdp xrdp
Suggested packages:
66-service-turnstill | 66-service-consolekit | 66-service-elogind
| 66-service-logind | 66-service-systemd-logind guacamole
Recommended packages:
66-service-xdg-user-dirs xorg
The following NEW packages will be installed:
66-service-xrdp xorgxrdp xrdp
0 upgraded, 3 newly installed, 0 to remove and 157 not upgraded.
Need to get 689 kB of archives.
After this operation, 4,890 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.de.debian.org/debian trixie/main amd64 xrdp amd64 0.10.1-3.1 [619 kB]
Get:2 http://ftp.cc.uoc.gr/mirrors/linux/mx/antix/trixie trixie/main amd64 66-service-xrdp all 0.0.2-0antix2 [4,204 B]
Get:3 http://ftp.de.debian.org/debian trixie/main amd64 xorgxrdp amd64 1:0.10.2-1 [65.8 kB]
Fetched 689 kB in 4s (193 kB/s)
Selecting previously unselected package xrdp.
(Reading database ... 229304 files and directories currently installed.)
Preparing to unpack .../xrdp_0.10.1-3.1_amd64.deb ...
Unpacking xrdp (0.10.1-3.1) ...
Selecting previously unselected package xorgxrdp.
Preparing to unpack .../xorgxrdp_1%3a0.10.2-1_amd64.deb ...
Unpacking xorgxrdp (1:0.10.2-1) ...
Selecting previously unselected package 66-service-xrdp.
Preparing to unpack .../66-service-xrdp_0.0.2-0antix2_all.deb ...
Unpacking 66-service-xrdp (0.0.2-0antix2) ...
Setting up xrdp (0.10.1-3.1) ...
Generating 2048 bit rsa key...
ssl_gen_key_xrdp1 ok
saving to /etc/xrdp/rsakeys.ini
runlevel: applet not found
invoke-rc.d: could not determine current runlevel
Setting up xorgxrdp (1:0.10.2-1) ...
Setting up 66-service-xrdp (0.0.2-0antix2) ...
parsing/reconfiguring/starting/enabling packaged services
parse: info: Parsed successfully: xrdp-sesman-log at tree: global
parse: info: Parsed successfully: xrdp-sesman at tree: global
parse: info: Parsed successfully: xrdp-log at tree: global
parse: info: Parsed successfully: xrdp at tree: global
enable: info: Enabled successfully: xrdp-log
enable: info: Enabled successfully: xrdp-sesman-log
enable: info: Enabled successfully: dbus-log
enable: info: Enabled successfully: dbus
enable: info: Enabled successfully: xrdp-sesman
enable: info: Enabled successfully: xrdp
start: info: Initialized successfully: xrdp
start: info: Initialized successfully: xrdp-sesman
start: info: Initialized successfully: xrdp-log
start: info: Initialized successfully: xrdp-sesman-log
signal: info: Successfully started service: dbus-log
signal: info: Successfully started service: dbus
signal: info: Successfully started service: xrdp-log
signal: info: Successfully started service: xrdp-sesman-log
signal: info: Successfully started service: xrdp-sesman
signal: info: Successfully started service: xrdp
parsing/reconfiguring/starting/enabling packaged services
signal: info: Successfully stopped service: xrdp
signal: info: Successfully stopped service: xrdp-sesman
signal: info: Successfully stopped service: xrdp-log
signal: info: Successfully stopped service: xrdp-sesman-log
stop: info: Unsupervised successfully: xrdp
stop: info: Unsupervised successfully: xrdp-log
stop: info: Unsupervised successfully: xrdp-sesman
stop: info: Unsupervised successfully: xrdp-sesman-log
parse: info: Parsed successfully: xrdp-sesman-log at tree: global
parse: info: Parsed successfully: xrdp-sesman at tree: global
start: info: Initialized successfully: xrdp
start: info: Initialized successfully: xrdp-sesman
start: info: Initialized successfully: xrdp-log
start: info: Initialized successfully: xrdp-sesman-log
signal: info: Successfully started service: dbus-log
signal: info: Successfully started service: dbus
signal: info: Successfully started service: xrdp-log
signal: info: Successfully started service: xrdp-sesman-log
signal: info: Successfully started service: xrdp-sesman
signal: info: Successfully started service: xrdp
enable: info: Enabled successfully: xrdp-log
enable: info: Enabled successfully: xrdp-sesman-log
enable: info: Enabled successfully: dbus-log
enable: info: Enabled successfully: dbus
enable: info: Enabled successfully: xrdp-sesman
enable: info: Enabled successfully: xrdp
enable: info: Enabled successfully: xrdp-sesman-log
enable: info: Enabled successfully: dbus-log
enable: info: Enabled successfully: dbus
enable: info: Enabled successfully: xrdp-sesman
signal: info: Successfully started service: xrdp-sesman-log
signal: info: Successfully started service: dbus-log
signal: info: Successfully started service: dbus
signal: info: Successfully started service: xrdp-sesman
Processing triggers for runit-antix (2.2.0-3.0antix4) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12) ...
root@antix1:/home/nevj# ps ax | grep xrdb
So, yes , it works. As well as installing the service files, it enables and starts the daemon.
but
What is that message about ? Processing triggers for runit-antix (2.2.0-3.0antix4) ...
I am in s6-66, not runit?
I guess that is a leftover message that needs to be cleaned up?
Overall that is quite impressive. Normal users who dont like writing init scripts will be able to use any of the 4 antX25 init systems with minimal hassle.
I expect , by the time we get from beta1 to a full release there will be a full compliment of service packages for all 4 init systems. I have to say well done to the antiX developers.
And , a special thanks to @ProwlerGr for explaining this to me … it is does not seem to be documented yet in the beta1 release.
We are priviliged to get an early look at this development.
There are a few packages in Debian that have a (needless IMO) dependency to the runit-helper package. openssh-server is surely one of them & there are many others - this is what causes the triggers. antiX’s scope is not to package everything in Debian so oddities like this are to be expected
