Skip to main content ↑ ↓
Topic: Anyone else play around with Devuan runit? (Read 1370 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Anyone else play around with Devuan runit?

Hi all, I've been using Artix with runit exclusively since December of last year. I recently decided to test out Devuan with runit in a VM just to see what the major differences are and other than their packages just being very old in some cases, it's not too bad!

What caught my eye, however, was that when I installed mariadb and postgresql along with a few other services that rely in runit, I realized they didn't need soft links like in Artix, and instead, just ran by default like they do on a standard systemd distribution. Upon a little bit of inspection, at least according to btop, these services were indeed being run by runit, but through udevd. I was wondering if anyone has played around with Devuan and noticed this? I've also noticed that the Void distro has a very slight different implementation of runit in that their service directories are located in slightly different locations. I know these are subtle differences, at least from a user's perspective like mine, but I was wondering if anyone could elucidate on the decisions made regarding how runit was implemented on Ariix vs Void and vs Devuan?

I know I'm splitting hairs, here, but I have to admit my curiosity is peaked. Any insights would be greatly appreciated, and thanks in advance!

Re: Anyone else play around with Devuan runit?

Reply #1 –
>these services were indeed being run by runit, but through udevd.

What does the device manager have to do with running services?
 

Re: Anyone else play around with Devuan runit?

Reply #2 –
Quote from: z3rOR0ne – on
What caught my eye, however, was that when I installed mariadb and postgresql along with a few other services that rely in runit, I realized they didn't need soft links like in Artix, and instead, just ran by default like they do on a standard systemd distribution.

This is a packaging decision from Arch that Artix imitates. In principle there could be a post-install hook so pacman would enable the service for you, but just as Arch requires you to systemctl enable --now service, Artix requires a manual rc-update/runit symlink/etc.

Devuan is also copying Debian in this regard.

Quote from: z3rOR0ne – on
Upon a little bit of inspection, at least according to btop, these services were indeed being run by runit, but through udevd.

Your topic picked my interested so I went to check Devuan's runit implementation. Unfortunately the rumors I kept seeing everywhere are true: Devuan's runit implementation is fact just a coat of paint on classic SysV initialization. runsvdir, runsv and sv only manage the ttys (ie do nothing SysV PID 1 didn't already do) and every other service is spawned through ye olde SysV scripts, double-forking and getting re-parented to PID 1. Not only none of runit's benefits apply to Devuan, many things criticized in that page (PID files, init scripts with boilerplate, syslog being a central bottleneck...) are true of Devuan runit.

You also get the inconsistency of managing ttys with sv and all other system services with /etc/init.d/service start|stop. On "real" runit (like you get on Artix and Void), sv is used for everything.

Quote from: z3rOR0ne – on
I was wondering if anyone has played around with Devuan and noticed this? I've also noticed that the Void distro has a very slight different implementation of runit in that their service directories are located in slightly different locations. I know these are subtle differences, at least from a user's perspective like mine, but I was wondering if anyone could elucidate on the decisions made regarding how runit was implemented on Ariix vs Void and vs Devuan?

That's something only konimex can answer for sure, but AFAIK, the service folder location was renamed so it'd be more consistent with OpenRC (/run/openrc = /run/runit).

Void and Artix both closely follow runit's documentation (arriving at the same results using slightly different code), while Devuan seems stuck in the middle (step 3, to be precise), where runit is the PID 1 and manages the TTYs, but doesn't actually manage any services.


Installing Devuan on a VM made me again appreciate how fast pacman is compared to apt. Maybe it was qcow's compression also slowing things down, but I don't miss the concept of "dpkg --configure".

Re: Anyone else play around with Devuan runit?

Reply #3 –
Quote from: capezotte – on
Your topic picked my interested so I went to check Devuan's runit implementation. Unfortunately the rumors I kept seeing everywhere are true: Devuan's runit implementation is fact just a coat of paint on classic SysV initialization. runsvdir, runsv and sv only manage the ttys (ie do nothing SysV PID 1 didn't already do) and every other service is spawned through ye olde SysV scripts, double-forking and getting re-parented to PID 1. Not only none of runit's benefits apply to Devuan, many things criticized in that page (PID files, init scripts with boilerplate, syslog being a central bottleneck...) are true of Devuan runit.

Thanks for doing some digging regarding this topic! It's too bad that there isn't a Debian based distribution that mirrors the Artix philosophy. Not that I favor apt or anything like that, but rather I just like seeing diversity within the Linux ecosystem, but Devuan's implementation of runit is not encouraging based off of what you're telling me here.

Again, thank you for the in depth explanation and exploration.