[HowTo] runit-init as PID1

Head_on_a_Stick · 2020-06-22 17:45:47

This guide shows how to use runit-init as PID1 in Devuan, it is primarily aimed at Jesse from Distrowatch

First, instal the runit-init package:

# apt install runit-init

APT will ask for a specific confirmation for the operation because replacing the init system is far from trivial, type in the required authorisation to install the package.

Next, reboot into runit-init. Check it has worked with

cat /proc/1/comm

The output should be runit.

That's it!

EDIT: if a display manager is not required then add the user to the input group to allow access to the keyboard &c:

# gpasswd -a $USER input

Last edited by Head_on_a_Stick (2020-07-19 11:59:31)

golinux · 2020-06-22 18:57:27

Thanks for doing this. Did you send him a link to this post? IIRC, runit will not be officially supported until the Beowulf point release.

Head_on_a_Stick · 2020-06-22 19:04:21

golinux wrote:

Did you send him a link to this post?

I left a comment on the Distrowatch weekly page.

minute27 · 2020-06-22 19:32:38

I just did it, and everything's working out fine.

minute27@dev1local:~$ cat /proc/1/comm
runit

I was already hoping that with Devuan I could make the switch to runit, but now it's possible. Thank you very much!

P.D.: The output of cat /proc/1/comm is runit, not runit-init

Head_on_a_Stick · 2020-06-22 19:35:29

minute27 wrote:

P.D.: The output of cat /proc/1/comm is runit, not runit-init

Corrected, thanks!

Debian has had very good integration with runit for a long time now but it's much trickier to switch to runit-init because of the systemd-logind entanglement, Devuan solves that problem nicely.

andyprough · 2020-06-22 21:24:45

That did the trick, thanks! runit on Devuan 3 with Linux-libre (with other non-libre software and firmware removed), and with KDE 5.18.5 from Norbert Preining's repos. All working together well so far.

macondo · 2020-06-24 15:03:50

bobo@foo:~$ sudo apt install runit-init
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  fgetty getty-run runit runit-helper sysuser-helper
The following packages will be REMOVED:
  init sysvinit sysvinit-core
The following NEW packages will be installed:
  fgetty getty-run runit runit-helper runit-init sysuser-helper
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init sysvinit-core (due to init)
0 upgraded, 6 newly installed, 3 to remove and 0 not upgraded.
Need to get 0 B/202 kB of archives.
After this operation, 413 kB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] Yes, do as I say
Abort.
bobo@foo:~$

Head_on_a_Stick · 2020-06-24 18:07:46

macondo wrote:

To continue type in the phrase 'Yes, do as I say!'
 ?] Yes, do as I say

The trick is to type in the requested phrase — prepending the phrase with a question mark and a square bracket will not work

EDIT: and you missed the exclamation mark.

Last edited by Head_on_a_Stick (2020-06-24 19:31:45)

fsmithred · 2020-06-29 15:06:46

The question mark and square bracket are the prompt. I got the same. And it did what I said!

And more...

This required some minor hacking to get around dependency issues. When sysvinit gets removed, live-config-sysvinit and refractasnapshot go with it. I copied all the files into place and it works. There needs to be a live-config-runit package.

user@refracta:~$ cat /proc/1/comm 
runit
user@refracta:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            480M     0  480M   0% /dev
tmpfs            99M  392K   99M   1% /run
/dev/sr0        965M  965M     0 100% /run/live/medium
/dev/loop0      927M  927M     0 100% /run/live/rootfs/filesystem.squashfs
tmpfs           494M  440K  493M   1% /run/live/overlay
overlay         494M  440K  493M   1% /

System was installed in a VM, and the live-iso was made with refractasnapshot.
The iso boots in qemu and also isohybrid usb boots on hardware. Stuff works.
This is in beowulf. I think aitor may have done this already. I'm surprised at how easy it was.

brocashelm · 2020-06-29 15:12:27

This worked for me. Runit is a lot faster than all the other inits I've tried, so it's great to see this option finally available on a Devuan base!

john2009w · 2020-07-17 20:25:20

My mouse cursor freezes under runit and I have no choice but to shutdown with power button. I'm on Chimaera/testing. I use `exec dbus-launch openbox-session &` with ~/.xinitrc

When I ran `# apt install runit-init`, it said:

...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on sysvinit-core | runit-init: however:
  Package sysvinit-core is to be removed.
  Package runit-init is not installed.
...
Unpacking runit-init (2.1.2-36) ...
Setting up runit-init (2.1.2-36) ...

And there was no question asked like, "To continue type in the phrase" etc. Is this normal?

However I ran `reboot` and it said at the end:

Will now restart.
Give root password for maintenance
(or press Control-D to continue):

Pressing Ctrl+D says `sulogin: cannot read /dev/tty1: Operation not permitted`, then asks for root password again. If I enter root password it logins to a root prompt. I run `reboot` there and it finally rebooted.

After the reboot when I login on tty1 and run startx, it shows tint2 panel and everything, but I can't move the mouse cursor, can't do anything with keyboard and the machine freezes!! Please help!

Head_on_a_Stick · 2020-07-17 21:09:21

john2009w wrote:

My mouse cursor freezes under runit and I have no choice but to shutdown with power button. I'm on Chimaera/testing.

It's called "testing" for a reason

john2009w wrote:

I use `exec dbus-launch openbox-session &` with ~/.xinitrc

You shouldn't need dbus-launch or ~/.xinitrc.

Try

rm ~/.xinitrc
# update-alternatives --set x-session-manager /usr/bin/openbox-session
startx

If the desktop still doesn't work properly then please open a new thread about the problem and include the X.Org log file.

john2009w wrote:

When I ran `# apt install runit-init`, it said:
...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
 init depends on sysvinit-core | runit-init: however:
  Package sysvinit-core is to be removed.
  Package runit-init is not installed.
...
Unpacking runit-init (2.1.2-36) ...
Setting up runit-init (2.1.2-36) ...
And there was no question asked like, "To continue type in the phrase" etc. Is this normal?

I only tried the technique with beowulf but that certainly didn't happen for me.

john2009w · 2020-07-17 22:09:47

Head_on_a_Stick wrote:

It's called "testing" for a reason

Haha. You said it right. Living on Artix/Void has made me used to it. I think I found a solution. I remember I got this problem once on Artix/Parabola OpenRC. I had to add needs_root_rights = yes on /etc/X11/Xwrapper.config. So my steps are:

Install runit-init package

sudo -s
apt install runit-init

If it asks for a question answer it
Add the line below to /etc/X11/Xwrapper.config

needs_root_rights = yes

Then as the config file suggests, run this to keep the changes intact across upgrades:

dkpg-reconfigure xserver-xorg-legacy

When it prompts, default selection (console) is fine then press enter

Then run `reboot`
When asked to enter root password, enter it. Then again `reboot`

Head_on_a_Stick wrote:

You shouldn't need dbus-launch or ~/.xinitrc.
Try
rm ~/.xinitrc
# update-alternatives --set x-session-manager /usr/bin/openbox-session
startx

But I need to change to other desktops/wms sometimes, so startx is easier for me. It's more Unixy this way. Everything is a file, you just edit and it works.

EDIT: I have a question though... I have `runit` returned on `cat /proc/1/comm`. But when I tried `sudo sv restart network-manager` it didn't work. I have to restart network manager through `sudo service network-manager restart`. Why it that?

Last edited by john2009w (2020-07-17 22:13:02)

Head_on_a_Stick · 2020-07-17 22:15:14

john2009w wrote:

I had to add needs_root_rights = yes on /etc/X11/Xwrapper.config.

That is no longer needed, elogind should allow rootless X without xserver-xorg-legacy.

john2009w wrote:

But I need to change to other desktops/wms sometimes

For Devuan ~/.xsession should be used instead of ~/.xinitrc. And you don't need to prepend openbox-session with dbus-launch.

EDIT:

john2009w wrote:

when I tried `sudo sv restart network-manager` it didn't work

The service management is performed through wrapper functions so you just treat the box as if it was running sysvinit.

Last edited by Head_on_a_Stick (2020-07-17 22:19:39)

xinomilo · 2020-07-18 07:56:45

runit for debian is far for complete.. had a small talk about it in antixforum : https://www.antixforum.com/forums/topic … art-runit/

tried runit (& s6) in artix and indeed, a very different experience there.

john2009w · 2020-07-18 09:52:35

Head_on_a_Stick wrote:

john2009w wrote:
I had to add needs_root_rights = yes on /etc/X11/Xwrapper.config.
That is no longer needed, elogind should allow rootless X without xserver-xorg-legacy.

Thanks for the hint. Unfortunately having elogind did not work for me. I looked into a failed xorg log when mouse was not working. It had entries like:

(EE) xf86OpenSerial: Cannot open device /dev/input/event1

I searched around and found that adding the user to "input" group should solve the issue without needing to set `needs_root_rights=yes`. So removed the line from Xwrapper.config, ran sudo dpkg-reconfigure xserver-xorg-legacy command, then:

sudo usermod -aG input $USER

Then found out there was another problem. I wasn't able to connect to openvpn connections. It said `Error: Connection activation failed: Not authorized to control networking.` So I made sure I added myself to sudo usermod -aG netdev $USER, then put the code below on /etc/polkit-1/localauthority/50-local.d/80-networkmanager.pkla:

[network manager allow users]
Identity=unix-group:netdev
Action=org.freedesktop.NetworkManager.*
ResultAny=yes

Then rebooted to apply the group changes. Now everything's fine. (so far at least)

I think there should be some wiki or doc somewhere about these things. This is way past installing just a package.

Head_on_a_Stick wrote:

john2009w wrote:
But I need to change to other desktops/wms sometimes
For Devuan ~/.xsession should be used instead of ~/.xinitrc. And you don't need to prepend openbox-session with dbus-launch.

That's interesting. I've never used that. How do I change the desktop/wm then?

john2009w wrote:
when I tried `sudo sv restart network-manager` it didn't work
The service management is performed through wrapper functions so you just treat the box as if it was running sysvinit.

That's great. Then it becomes easier than I thought.

xinomilo wrote:

runit for debian is far for complete.. tried runit (& s6) in artix and indeed, a very different experience there.

I don't mind it, at least the way it's on Devuan. Artix/Parabola OpenRC also has some issues which need manual intervention during setup. But what really helps is a doc/wiki page guiding through this process. Artix has good guides on switching to and installing runit. Having something similar would be helpful.

Last edited by john2009w (2020-07-18 09:56:40)

Head_on_a_Stick · 2020-07-18 15:06:14

Your problems must be due to changes in testing because neither I nor anybody else in this thread has experienced them with beowulf.

As I mentioned earlier it would probably be best to open a new thread about this so that we can dig into it further, I think the developers may want to add runit-init as an option for future releases so it would help them.

john2009w · 2020-07-18 23:26:31

Well, previously tried runit on Beowulf. It also froze up like Chimaera. The difference is that it asked a question when installing. Otherwise everything else was the same.

It's OK. I think I found a solution to these problems. No new threads necessary. I installed slim dm and then started slim service, rebooted. Before rebooting I reverted the changes. And then after reboot when I logged in with slim, everything worked fine. Mouse and keyboard was working, nm openvpn connection was working. It even fixed a pavucontrol issue that was showing "Connection to PulseAudio failed. Automatic retry in 5s". I didn't need slim on sysvinit. So I guess using a dm is a must when switching to runit (to avoid problems that needs manual changes otherwise). But I had a good adventure tbh!

Head_on_a_Stick · 2020-07-19 11:58:35

john2009w wrote:

using a dm is a must when switching to runit (to avoid problems that needs manual changes otherwise).

Yes, I've just confirmed that — the user must be in the input group if a display manager isn't used.

I've added a note to the OP.

Lorenzo · 2020-07-21 11:16:47

Just run into this thread by chance. There is very few interest in runit in Debian right now so maybe is convenient to drop some howto directly here where it looks there are people available to do some testing..

After the reboot when I login on tty1 and run startx, it shows tint2 panel and everything, but I can't move the mouse cursor, can't do anything with keyboard and the machine freezes!! Please help!

Yes, I've just confirmed that — the user must be in the input group if a display manager isn't used.

This permission issue is new to me but is bad enough that I need to double check if this can be reproduced in Debian and possibly fix there. I'm not sure though, could be also something that is caused by some Debian-Devuan delta.

When I ran `# apt install runit-init`, it said:
...
dpkg: sysvinit-core: dependency problems, but removing anyway as you requested:
init depends on sysvinit-core | runit-init: however:
Package sysvinit-core is to be removed.
Package runit-init is not installed.
...
Unpacking runit-init (2.1.2-36) ...
Setting up runit-init (2.1.2-36) ...

Besides sysvinit-core, was any other package removed?
I'm not surprised that Xorg is not working with runit, without elogind or any other means that gives permission on input devices to your user, but what puzzles me is how was working with sysvinit..

Lorenzo

Head_on_a_Stick · 2020-07-21 17:30:57

Lorenzo wrote:

This permission issue is new to me but is bad enough that I need to double check if this can be reproduced in Debian

I can confirm that the user needs to be added to the input group to get the keyboard &c working in Debian buster if an alternative init system is used. I've tested with runit-init, sysvinit and openrc-init as PID1.

Lorenzo wrote:

I'm not surprised that Xorg is not working with runit, without elogind or any other means that gives permission on input devices to your user

In my test elogind was installed and the elogin-daemon process was running.

brocashelm · 2020-08-02 11:06:21

Using Runit, I was also experiencing abrupt freezing for a while. I understood what I was getting myself into, but I didn't seem to find much of a solution. This was only affecting one of my machines, whereas the others were also on the Chimaera branch. Ever since I "moved" all my machines to Ceres, I've been running the system for three days straight without issue. I keep an eye out for faults, yet my machines couldn't be any more stable!

xinomilo · 2020-10-11 21:17:13

so, had it in mind for months, finally switched to runit in a fully upgraded ceres. was using openrc before, so never seen any: "Yes do as i say!" messages during installation.
`apt install runit-init` , some packages were removed and then tried a reboot, but that got stuck for missing commands.. don't have the exact messages, but since all?/most daemons were closed and running system was missing some previously used programs after installation, that looked normal... so, shutdown using power button.
machine came up normally, boot seemed faster than usual, and everything still works..
because this is debian runit, i only found 2 daemons with sv configured (tor + acpid), everything else still needs `service blah ...`. note that eg `service tor stop` doesn't work, one needs to run `sv stop tor` for that. so could be a fuzz with lots of daemons, when some will work with `sv`, but most still need `service`...
/etc/sv for available services, /var/log/runit/ contains logs for these, everything else is working/logging as before.

(RTFM) will have to do some reading along the way to also check why sv stopped $service still keeps a `runsv $service` & `svlogd -tt $service` running.
and also lookup runit scripts for more daemons.

thierrybo · 2020-10-23 23:15:46

I confirm, installed it on Chimaera/Sysv init system, no "Yes do as i say!" message and I also had to use the power button.
For me there was only ssh as a true Runit service.

I played a bit with Runit on Void, and contrary to many comments I read, this is a full featured Runit. The few directories changes are just to be compliant with Filesystem Hierarchy Standard.

When comments say that Runit support is not complete in Debian, this is because these persons wait a full distro that choose Runit as a main init system and provide all init scripts for it. But as I think Devuan is a "base" for other distributions as Debian is and its goal is to stay an "independent" init distro, it is unlikely they can maintain init scripts for Openrc and Runit in addition to Sysv scripts.

So yes Runit in Debian just "embed" sysv scripts, but this is not a Debian hack, Debian just did what is described in Runit manual, in "Step 5: Service migration chapter".

So if the goal is to use sv to manage all services, do not choose Debian/Devuan, otherwise it is fine for me.

zapper · 2020-10-24 00:26:46

Runit with runit-init for me was twice as fast as openrc. Hard to believe, but yeah it is.

It worked fine for me on both testing devuan and devuan beowulf, can't say if the others it works well on.

But, on devuan beowulf when you switch from openrc to runit and add runit-init and then try to go back for some reason to openrc, I once had some issues on beowulf. heh... weird stuff.

If you intend to install runit-init + runit the moment you install devuan beowulf, don't install openrc right off the bat. Unless you know something I don't...

That kind of thing caused me some issues once, where dependency hell got in the way...

PS, in my experience, runit + runit-init cut my boot time in half. and shutdown happens in a 1/3 less time if I recall correctly.

Last edited by zapper (2020-10-24 00:27:37)

The officially official Devuan Forum!

#1 2020-06-22 17:45:47

[HowTo] runit-init as PID1

#2 2020-06-22 18:57:27

Re: [HowTo] runit-init as PID1

#3 2020-06-22 19:04:21

Re: [HowTo] runit-init as PID1

#4 2020-06-22 19:32:38

Re: [HowTo] runit-init as PID1

#5 2020-06-22 19:35:29

Re: [HowTo] runit-init as PID1

#6 2020-06-22 21:24:45

Re: [HowTo] runit-init as PID1

#7 2020-06-24 15:03:50

Re: [HowTo] runit-init as PID1

#8 2020-06-24 18:07:46

Re: [HowTo] runit-init as PID1

#9 2020-06-29 15:06:46

Re: [HowTo] runit-init as PID1

#10 2020-06-29 15:12:27

Re: [HowTo] runit-init as PID1

#11 2020-07-17 20:25:20

Re: [HowTo] runit-init as PID1

#12 2020-07-17 21:09:21

Re: [HowTo] runit-init as PID1

#13 2020-07-17 22:09:47

Re: [HowTo] runit-init as PID1

#14 2020-07-17 22:15:14

Re: [HowTo] runit-init as PID1

#15 2020-07-18 07:56:45

Re: [HowTo] runit-init as PID1

#16 2020-07-18 09:52:35

Re: [HowTo] runit-init as PID1

#17 2020-07-18 15:06:14

Re: [HowTo] runit-init as PID1

#18 2020-07-18 23:26:31

Re: [HowTo] runit-init as PID1

#19 2020-07-19 11:58:35

Re: [HowTo] runit-init as PID1

#20 2020-07-21 11:16:47

Re: [HowTo] runit-init as PID1

#21 2020-07-21 17:30:57

Re: [HowTo] runit-init as PID1

#22 2020-08-02 11:06:21

Re: [HowTo] runit-init as PID1

#23 2020-10-11 21:17:13

Re: [HowTo] runit-init as PID1

#24 2020-10-23 23:15:46

Re: [HowTo] runit-init as PID1

#25 2020-10-24 00:26:46

Re: [HowTo] runit-init as PID1

Board footer