runit on antiX-bullseye iso.

Forum Forums General Tips and Tricks runit on antiX-bullseye iso.

  • This topic has 17 replies, 7 voices, and was last updated Sep 10-7:58 pm by Xecure.
Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #56414
    Forum Admin
    anticapitalista

      This is a work in progress.

      Much of the information has been copied from Artix wiki on runit, but modified to how it runs on antiX.

      What is runit?
      runit is a suite of tools which provides an init (PID 1) as well as daemontools-compatible process supervision framework, along with utilites which streamline creation and maintenance of services.

      Installation
      This is very much a work in progress. If users want to try out runit, use the runit version iso. Otherwise, converting an existing antiX-sysvinit to runit will probably end in breakage.

      Installation of services
      A basic set of runit service packages are provided on the iso and can be found in /usr/share/runit/sv and are copied to /etc/sv if they don’t already exist there. This allows users to customise their runit service scripts in /etc/sv and they will not get overwritten on any update.

      Programs
      runit has several programs, but usually you will only interact directly with one program only.

      *sv – used for controlling services, getting status of services, and dependency checking.
      *chpst – control of a process environment, including memory caps, limits on cores, data segments, environments, user/group privileges, and more.
      *runsv – supervises a process, and optionally a log service for that process.
      *svlogd – a simple but powerful logger, includes auto-rotation based on different methods (time, size, etc), post-processing, pattern matching, and socket (remote logging) options.
      *runsvchdir – changes service levels (runlevels, see below)
      *runsvdir – starts a supervision tree
      *runit-init – PID 1, does almost nothing besides being the init

      Files
      There are several files installed by runit.

      /etc/runit/1 – stage 1, system’s one-time initialization tasks
      /etc/runit/2 – stage 2, Normally runs runsvdir, should not return until the system is going to halt or reboot.
      /etc/runit/3 – stage 3, system’s shutdown tasks
      /etc/runit/ctrlaltdel – runit will execute this when receiving a SIGINT signal
      /etc/runit/runsvdir/* – Runlevels
      /etc/sv/* – directory containing subdirectories of available service files
      /etc/service – always symlinked to active runlevel, sv will search for running service here

      On antiX, one-time initialization task scripts are mostly found in /etc/runit-core and a few in /etc/init.d
      antiX has altered Debian’s sysvinit scripts to run as runit scripts.
      However, some manual intervention may be needed especially when using antiX-net or antiX-core runit editions.

      Basic usage

      *Enable service (in runlevel default)# ln -s /etc/sv/service_name /etc/service/
      *Disable service # unlink /etc/service/service_name or # touch down /etc/sv/service_name
      *Stop immediately # sv down service_name or # sv stop service_name
      *Start (if not running) # sv up service_name or # sv restart service_name
      *Restart # sv restart service_name
      *Reload # sv restart service_name
      *Status check # sv status service_name
      *Switch runlevels (this will stop all services that are currently running and will start all services in the new runlevel) # runsvchdir runlevel

      Thanks to @Xecure, the above can be done via the runit-service-manager app.

      Runlevel
      By default, on antiX runit has 3 runlevels, default, single and solo. You can make your own runlevels just by creating a new folder in /etc/runit/runsvdir/ and symlinking your desired service to that runlevel.
      To boot into runit level 1 (maintenance mode) simply type single at the boot menu. You will be prompted for the root password.
      If running ‘live’ or frugal, remove the splasht ‘cheat’.
      If you have booted into the X graphical environment but want to switch to X-less (no Xorg running) type this in terminal

      sudo runsvchdir solo

      You will need to login as user.

      To get back to the graphical X session from X-less, type

      sudo runsvchdir default

      Service directory structure
      This is a tree of a complete service directory structure (aka /etc/sv/servicedir), in some run scripts, typically only run will be available as usually it’s the only file needed.

      servicedir
      ├── run (755)
      ├── check (755)
      ├── conf (644)
      ├── finish (755)
      └── log (directory)
      ├── config (644)
      └── run (755)

      A runit (or any daemontools-compatible) run script service directory usually contains only one executable file, run, which runs process in the foreground. Processes that run in the background cannot be supervised by runit.

      If a service directory contains another directory named log, the output of the run process in the service directory will be piped to the input of the run process in the log directory. If the log service uses svlogd, it may be configured by using the file config. How svlogd can be configured is explained in the svlogd(1) manpage.

      A run script may also contain executables like finish and check. finish will be executed when a service is stopped, and check will be executed (if exists) by sv check or sv status.

      A run script may also contain a conf file (which is not executable) that modifies the variables available to the script.

      Service dependencies
      Some services may depend on other services. For example, Connman depends on dbus. To ensure that required dependencies are satisfied, check the service’s run file. For example, for Connman:

      # /etc/sv/Connman/run
      sv start dbus && sv check dbus || exit 170

      This means you have to enable dbus for Connman to start.

      • This topic was modified 1 year, 5 months ago by anticapitalista. Reason: Use Connman as an example
      • This topic was modified 10 months, 3 weeks ago by anticapitalista. Reason: added some runlevel commands

      Philosophers have interpreted the world in many ways; the point is to change it.

      antiX with runit - leaner and meaner.

      #57935
      Anonymous

        converting an existing antiX-sysvinit to runit will probably end in breakage.

        wondering:
        Will it begin with breakage, if “disable=lxmd” is present on the bootline, or does this release feature a modded liveboot init ?

        #57936
        Forum Admin
        anticapitalista

          wondering:
          Will it begin with breakage, if “disable=lxmd” is present on the bootline, or does this release feature a modded liveboot init ?

          No it won’t. It boots just fine with disable=lxmd

          Philosophers have interpreted the world in many ways; the point is to change it.

          antiX with runit - leaner and meaner.

          #61937
          Member
          Xecure

            Proposal: Addition to include a script to stop sysv scripts in the package runit-antix.

            Based on the runit manual, there are 3 stages (and control+alt+del) in which runit operates.
            antiX’ implementation of runit has, in STAGE 1, a place where it launches sysvinit scripts in /etc/runit-core using the script /lib/runit/run_sysv_scripts. All script starting with an “S” are run in the numerical order they are organized (first S01-scrip1, S02-script2, etc.).

            I would like a new script to be included in /lib/runit which would be called at the end of STAGE 3 (the stage that goes before shutdown), named stop_sysv_scripts. It would run the “stop” option for each script in /etc/runit-core that starts with “Z” in the order they appear. I made a lame copy-paste of run_sysv_scripts with the specific changes proposed:

            cat /lib/runit-core/stop_sysv_scripts
            #!/bin/sh -u
            # Deliberately NO 'set -e'. See #923957.
            initdir="${1}"
            for script in "$initdir/Z"* ; do
            	path=$(realpath "$script")
            	name=$(basename "$path")
            	# Special case for wicd. Runscript is called "wicd-daemon",
            	# to match binary package name.
            	[ -d "/etc/sv/$name" ] && continue
            	[ -d "/etc/sv/$name-daemon" ] && continue
            	"$script" stop
            done

            Then, at the end of /etc/runit/3 (STAGE 3), this command should be added:
            /lib/runit/stop_sysv_scripts '/etc/runit-core'
            So that the proposed script would run at the end of STAGE 3 (as explained above).

            The other addition would be to create symlinks in /etc/runit-core starting with the letter “Z” to the scripts we need stopped before shutdown. For example, for brightness (package runit-core-services-antix):
            sudo ln -s /etc/runit-core/S13brightness /etc/runit-core/Z13brightness
            This saves the brightness of the screen so that S13brightness can start it on next restart.

            I don’t know if other script may also need this stopping option, but at least this solves the brightness issue without the need of implementing a new runit service in /etc/sv/.

            Thanks for your time.

            • This reply was modified 2 years, 10 months ago by Xecure. Reason: Tryng to fix the code tags
            • This reply was modified 2 years, 10 months ago by Xecure. Reason: Second time trying to fix the code tags
            • This reply was modified 2 years, 10 months ago by Xecure. Reason: a bit of formating

            antiX Live system enthusiast.
            General Live Boot Parameters for antiX.

            #61994
            Moderator
            Brian Masinick

              Xecure wrote: “… This saves the brightness of the screen so that S13brightness can start it on next restart.

              I don’t know if other script may also need this stopping option, but at least this solves the brightness issue without the need of implementing a new runit service in /etc/sv/.”

              I *really* appreciate this! I am sensitive to light and being able to use and modify the Backlight Brightness is very important to me.

              Thanks!

              --
              Brian Masinick

              #64941
              Member
              Xecure

                I think it is time for all runit enthusiast to share what services they would like to have in the upcoming antiX 21-runit release.

                I have tweaked a few of the official antiX ones (accessible here):
                * slim and slimski, so that they only load if they are the default Display Manager (and fixed the needed options for slimski to load on live-USB).
                * connman and elogind, so that they check if dbus is already running before starting (and correctly stop if not installed).
                * dbus, improving the check command (and only load if it is installed – not tested; I was thinking this for systems without dbus).

                I have also created two new ones:
                * lightdm, for people who don’t want slim or slimski
                * network-manager, for those who don’t like connman or ceni

                I am planning on creating ones for sddm and maybe gdm, but I will need to test them first (all above were tested on antiX21b1-runit). Most were adapted from the original antiX runit scripts (barely adding some touches), the others were inspired by them and the original init scripts. I also studied runit services for debian/devuan, to better understand the structure and the exit commands.

                I am also planing on revising the ones that errored out on a clean install/ive-system antiX21b1-runit.

                I will listen to petitions and try to create the ones that I am capable.

                antiX Live system enthusiast.
                General Live Boot Parameters for antiX.

                #64952
                Forum Admin
                anticapitalista

                  Thanks Xecure.
                  antiX-21 runit needs some love as it is completely different from our antiX-19 runit attempt.
                  We’re trying to run it (pun intended) on a Debian derivative (antiX) as the runit dev intended ie without it being dependent on sysvinit.
                  For runit fans users, please respond to Xecure’s request.

                  • This reply was modified 2 years, 8 months ago by anticapitalista.

                  Philosophers have interpreted the world in many ways; the point is to change it.

                  antiX with runit - leaner and meaner.

                  #64954
                  Member
                  olsztyn

                    For runit fans, please respond to Xecure’s request.

                    Since this is a request to runit fans only I am not sure I qualify to respond, since I am not exactly a fan of either sysvinit or runit but I would prefer runit if it is implemented in a consistent, streamlined way. More I would like S6 but it is a moot point now…
                    So just my very limited two cents from end user perspective, mostly focused on network stability:

                    * connman and elogind, so that they check if dbus is already running before starting (and correctly stop if not installed).

                    My experience is that on some my machines Connman does not seem to firmly maintain stability of connection and rather too often loses communication with dbus. I have not found a way to revive Connman connection in such case short of rebooting. This might have to do with some WiFi cards only but nevertheless. Now, just to clarify, this my experience has nothing to do with recent Connman failures in result of changes.
                    I have read of critical assessments of Connman as not a streamlined implementation but rather being full of patches around various drivers as issues were discovered. I do not know if this might be causing the above instability of communication with dbus.
                    As Connman remains as default in antiX I would like to find out how to re-instate such network connection, when Connman loses communication with dbus to improve usability.

                    * network-manager, for those who don’t like connman or ceni

                    For Hannie Schaft I was using Network Manager rather than Connman. Grup Yorum seems made it more tricky to replace Connman but I have not spent much time to figure this out yet and Bullseye is around the corner.
                    So on this Xecure’s point I would welcome Network Manager as an official alternative to Connman. From my pre-‘Grup Yorum’ observation it seemed more mature, although sometimes slow to connect when new network card detected (such as running on different laptop).

                    Another service I would think beneficial to would be Bluetooth. It is currently available in antiX and just needs to be enabled and start Blueman. However it appears to be dependent on pulseaudio to work, which takes a toll on memory. I do not know if there is a solution though…

                    Just my two cents.
                    Thank you Xecure!

                    P.S.:
                    Is there a way to run without a dbus altogether? In MX forum late last year there was a discussion of memory footprint and anticapitalista was showing Htop print of antiX with extremely low memory footprint. One of participants noticed that in that setup there was no dbus running…
                    Just a digression…

                    • This reply was modified 2 years, 8 months ago by olsztyn.
                    • This reply was modified 2 years, 8 months ago by olsztyn.

                    Live antiX Boot Options (Previously posted by Xecure):
                    http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

                    #64982
                    Member
                    Xecure

                      My experience is that on some my machines Connman does not seem to firmly maintain stability of connection and rather too often loses communication with dbus.

                      I think you are confusing connman (the connection manager, cannot work without dbus), with the cmst GUI, which communicates with connman through dbus (and is messed up sometimes). Simply kill the cmst process and restart it again.
                      I like how anticapitalista has set up antiX21, where cmst doesn’t start except if there is no network connection. This way it doesn’t reside in RAM doing nothing and you only launch it when needed (when closed, it stops the process).
                      cmst -d

                      I was using Network Manager rather than Connman

                      That worked well on antiX 19.X, but it seems Debian removed the service init script for Network Manager at some point (it isn’t present in bullseye), so you will need to copy it from antiX-19 if you want to still use it on sysvinit. I created this service for runit just to see if it was possible to use it there, and I had no problem at all running it with this service.
                      I prefer connman, as I have spent more time learning and testing things with it (it is a very powerful connection manager (has less dependencies that network-manager and can run with less accompanying programs):

                      Another service I would think beneficial to would be Bluetooth

                      anticapitalista already has it working on runit, but I may touch it a bit just so it stops without errors when bluetooth packages are removed.

                      Is there a way to run without a dbus altogether?

                      Yes. I recently removed dbus on a testing system just to see if I can get slimski to work properly without it (anticapitalista asked if I could get it to work without dbus). When you remove dbus, many many things are uninstalled, as dbus seems to have become a standard in linux (more even than systemd). connman needs dbus, networkmanager needs dbus, complex DEs require dbus, etc.
                      Network without dbus is pure wpa_supplicant+ifup/ifdown, I think (ceni for example). Most daemons nowadays seem to need dbus, so it will not be easy at all.

                      You may want to check out iwd, as their aim is to simplify wireless connections in linux and replace wpa_supplicant (but it depends on dbus). This program would be the only one scanning and managing wireless connections, and other programs (connman/network-manager) would interface with it using dbus. I haven’t used it, so no idea hw well it works, but some people seem to be happy with it.

                      Anyway, back to the services for runit, I will be touching on anticapitalista’s working services (mainly to add the no-error stopping when not available), and maybe even be touching runit-antix package to edit some /etc/runit-core init script (like adding sudo there, as it isn’t a real service, and is just used to restart the sudo timer for all users after rebooting) and adding the brightness service to save brightness setting for next reboot (proposed a few replies above).

                      Apart from Login Managers, anything else that people use that isn’t already a service in antiX 21-b1 runit?

                      antiX Live system enthusiast.
                      General Live Boot Parameters for antiX.

                      #64991
                      Member
                      ModdIt

                        Not been having issues with connmann, only thing I would like is a simple gui way to force the system to use a fixed DNS.
                        There are free and no tracking DNS services which I prefer to use and provide to users.

                        I saw connman taking DNS control called a bug, intel designed it to be a one stop time DNS and network service system.

                        As for the rest it is icing on the cake, means enjoying the way the beta runit is, more usable than than many stable distros.
                        I rarely boot an installed system now as start times are similar and USB sticks so convenient. Just keep no important data
                        on boot device.

                        #64992
                        Member
                        Xecure

                          We are going off topic, but:

                          Not been having issues with connmann, only thing I would like is a simple gui way to force the system to use a fixed DNS.
                          There are free and no tracking DNS services which I prefer to use and provide to users.

                          The new connman configuration in antiX21 disables the aggressive resolv.conf hijacking by connman. Simply remove the /etc/resolv.conf symlink and manually create an /etc/resolv.conf file with the DNS configuration you want. connman will no longer try to take control from you and your manual DNS configuration will work. See this thread, how the user wanted to use a different program to prevent DNS spoofing with an encrypted dns proxy. This is what sparked the proposed connman change (which also brought a lot of pain, unfortunately).

                          antiX Live system enthusiast.
                          General Live Boot Parameters for antiX.

                          #65007
                          Member
                          olsztyn

                            I think you are confusing connman (the connection manager, cannot work without dbus), with the cmst GUI, which communicates with connman through dbus (and is messed up sometimes). Simply kill the cmst process and restart it again.

                            Thank you Xecure for detailed explanations of all points. On this one – yes, indeed, I meant CMST communicating with Connman through dbus. Killing and restarting CMST should restore connection. Thanks for the tip.

                            I like how anticapitalista has set up antiX21, where cmst doesn’t start except if there is no network connection. This way it doesn’t reside in RAM doing nothing and you only launch it when needed (when closed, it stops the process).

                            I think this is already implemented in Grup Yorum 19.4 as well. If I am not mistaken it will not show up if upgrading from Hannie Schaft 19.2, but just installing Grup Yorum fresh.
                            Thanks and Regards…

                            Live antiX Boot Options (Previously posted by Xecure):
                            http://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

                            #65058
                            Moderator
                            Brian Masinick

                              I probably won’t be veering off the path much in the future, so my views don’t have to carry a lot of weight; I’ll gladly accept whatever we choose to do. From my perspective, the status quo of services and features is sufficient; feel free to either keep with them or modify extensively, depending on the reigning consensus.

                              --
                              Brian Masinick

                              #66137
                              Member
                              fungalnet

                                My only suggestion is that anything relating to runit goes under the /etc/runit hierarchy, so if and when other init/serv.suprv systems are experimented with, there will be no confusion as to what etc/sv etc/service etc, are for.
                                I think Artix utilizing 3 different systems has it right, although through packaging they make it impossible for 2 or 3 systems to be coexisting.

                                The usual cross between init systems are 4 or 5 files. (/usr/)(s)bin/{init – if it is a file not a link, reboot, poweroff, shutdown, halt} You can have a default init –> /sbin/init and you can have others using the bootloader entry with init=/usr/bin/s6/init or init=/usr/sbin/runit-init and from that point on the one system doesn’t encounter the existence of the other.

                                Another issue from comparing systems (mostly s6 and runit) is that runit-scripts should be stored by the package and replaced at /usr/share or /usr/lib ..runit/ not in /etc. /etc should be respected as the sysadmin’s space to modify and customize what runs and how. If a sys-admin wants to modify a service, let’s say dhcpcd or dhclient, just for that one specific interface and not anything found on the system, then he can copy the script from /usr/share/runit/sv/dhclient into /etc/runit/sv/ and modify it. Then whatever is linked in ../runsvdir/default this is what runs. When packaging releases a new version it replaces things on /usr/share/runit/ only NOT on /etc/ rewriting sysadmin’s customized scripts. It is the sysadmin’s responsibility to accept or deny the changes proposed, and if the system/service breaks because changes weren’t adopted it is not the distro’s fault but the sysadmin’s. With runit being finalized pretty much ages ago, you shouldn’t expect anything to change or break.

                                The way 66 has this working is that s6 on a root level service, parses the /etc/66/…. service/module directories for services defined there, if none are found, then goes to /usr/share or /usr/lib slib, whatever the packager decides, then runs the services listed in the database. For user services it does one up, it first looks at ~/66/service and ~/66/module then if none are found there, parses /etc/66/serv../mod then if the sysadmin hasn’t defined those user services universal for all users, then goes to /usr/share /lib /slib …. /66 and reads the script from there.

                                This can keep user hacker, sysadmin hacker, dev-hacker happy and coexisting, without the authoritarian dictatorship mandating how you should run your service. Let’s say you have 2 ethernet cards, and 3 wifi cards, but today you only use one ethernet, and no plans to use the rest. Dhcpcd will start by runit and fork itself in at least 6 instances, and those extra services will run and run trying to configure a disconnected card, each as a separate run of dhcpcd. But you want to modify this one dhcpcd to only start and configure eth1 … then you do an upgrade and suddenly you have dhcpcd multiplying itself …. wtf!!!

                                Somedays I feel like runit (taking the old Kawasaki w650 out for a ride in the plains to pick wild flowers) and some days I feel like taking s6 (the racy zx7rr) out for some tire burning in the twisty mountain roads) .. .. (actually I only have a 30y old yamaha and no money to run it, and end up walking or riding the bicycle hack … but I wish I can scrape some metal to the tarmac again before I kick the bucket).

                                #66139
                                Member
                                Xecure

                                  This would have been great and constructive feedback months ago, or during teh testing period, and not now that antiX21 is this close to being released and changing things will bring in unexpected bugs.

                                  For anyone who wants their own services, they can create them with a different (folder) name so they are not overwritten by an update, or place them in a different folder to /etc/sv/.

                                  antiX Live system enthusiast.
                                  General Live Boot Parameters for antiX.

                                Viewing 15 posts - 1 through 15 (of 18 total)
                                • You must be logged in to reply to this topic.