The officially official Devuan Forum!

Mercury

Member

Registered: 2024-11-14

Posts: 7  

[SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

(Skip to next paragraph to get to the meat of my problem.) I've been trying to understand some strange behavior on a fresh install of Devuan 6.1 on an older laptop. I installed the minimal system with runit then added xorg, xfce4, and slim. This laptop has a lot of odd quirks related to video and hardware, but that is (seemingly) beside the point. The problem that stumped me for a while is that sometimes, slim would display the login screen but fail to login; after inputting username and pass, it would blank the screen, then present the login again. This would cycle forever. This would happen even with autologin enabled, but this was also inconsistent. Examining processes revealed that slim was hanging onto a defunct instance of Xorg. Meanwhile, a new, live instance of Xorg had been started directly by runit (parent process 1). The solution was to manually kill Xorg and sv restart slim. I even wrote a script to do this that I could invoke more easily. Another weird, inconsistent behavior was that sometimes autologin would work and I'd get to my xfce desktop, but slim would appear in a window, which I could just minimize and ignore. Closing this window would just cause it to come back after a few seconds.

After a lot of frustration, it seems that slim was actually being started twice, causing some kind of race condition. One of the instances of slim would be started with the -d argument, the other without. The runit service definition did not have the -d arg. Troubleshooting, I just disabled the slim service (deleted the symlink from /etc/runit/runsvdir/default and... slim still starts!

The parent process is still 1, meaning runit is starting slim, with the -d arg, but I have no clue where this is coming from. The link in /etc/runit/runsvdir/default gets recreated on boot, again I don't know by what process, but I assume by slim or runit. For whatever reason, runit reports that the slim service is down.

So then I deleted the slim service file from /usr/share/runit/sv.current (where the symlink pointed to). And that gets recreated on boot. Finally, in desperation, I deleted the service definition from /usr/share/runit/sv -- that finally got the service to permanently not start.

But slim is still starting, with the -d arg, and I have no idea from where. Parent process is 1, so it seems runit is starting slim, but why does it do that without a service defined to do that? Everything I read online says that the login manager should be started as a service by runit (that's how one would switch from one LM to another if multiple are installed) and the default installed config was set up for that as well. Yet that broke things because slim got started twice -- once as the defined service, and secondly by... magic?

Oddly this has actually fixed my problem, at least so far through a dozen or so boots. I'm really just confused by what is happening. What logic is starting slim without a service defined?

Mercury

Member

Registered: 2024-11-14

Posts: 7  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

So runit is starting sysvinit scripts... somehow. slim isn't the only sysvinit service that's being started, but it was just the only one causing problems due to the double-start.

I don't know what logic in runit is doing this. This page describes the behavior I'm seeing:

All those executable files ( marked with *) are sysvinit scripts).
They wer all present at install time, except vsftpd which I installed as a test.
All these services are running. It is not clear to me whether runit automatically executes
all scripts in /etc/init.d, or whether it is triggered in some way.
...
At some point during startup, the runit process #1 must launch these sysVinit scripts

This is talking about Peppermint Dev1, but it's exactly what's happening on base. I'm definitely using runit. /sbin/init is symlinked to runit-init.

Everything else I've read says this should not be the case. Even google's AI says:

No, the runit process does not launch traditional sysvinit scripts in the way the user is implying. Runit and sysvinit are fundamentally different init systems with incompatible service management models.
...
Due to these differing models, a standard sysvinit script cannot be run unmodified as a runit service.

And while I'm not naive enough to trust AI, this at least shows that the preponderance of information available online says that sysvinit scripts are not directly launched by runit... except they are.

This is honestly very annoying, frustrating, and demoralizing. Why is this behavior not documented anywhere even semi-official? Why is the default configuration of runit/slim broken? I've spent hours of my own time just on investigating something that would've taken the developers, who clearly must've coded it to work this way, all of ten minutes to properly document it. This is unacceptable. I'm angry.

Last edited by Mercury (2026-01-30 16:26:38)

abower

Member

Registered: 2024-04-19

Posts: 25  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

I don't know why you seem to have to different slim startup scripts in parallel.

But it won't be helped by the existence of this bug, which has a simple fix/workaround: https://bugs.debian.org/cgi-bin/bugrepo … ug=1121099

Mercury

Member

Registered: 2024-11-14

Posts: 7  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

Okay, I finally understand what's happening.

Firstly, yes, runit starts sysvinit scripts, despite docs to the contrary. This is triggered from /etc/runit/2, which calls /lib/run/run_sv_scripts. (Good name, I guess.) All the online documentation is hopelessly out-of-date/wrong. I'm still angry.

run_sv_scripts tries to be clever by checking if a symlink with the name of the service exists in /etc/service/, precisely to prevent double-starts by ignoring sysvinit scripts for services that runit starts. This check works, and prevents slim from being started at this point. (Notably, this directory is symlinked to /etc/runit/sunsvdir/current/, where individual service dirs are symlinked to /usr/share/runit/sv.current/; foreshadowing.) Then follows another check (not reached in my case), which is in fact broken, which brings me to...

There is a runit service called dbus.dep-fixer which tries to ensure certain services that depend on dbus are really started, because the earlier start (by run_sv_scripts) might have failed due to timing issues. This script also tries to prevent double-starts by runit and sysvinit by looking for services that runit "knows about" in /etc/sv/. This check also appears in run_sv_scripts. This check is broken.

While online documentation (again, wrongly) says that runit service definitions (active or not) should be in /etc/sv, they are in fact in /usr/share/runit/sv/. There is no symlink from one to the other. /etc/sv contains some getty-tty stuff I don't understand, but it doesn't have the regular services (inlcluding slim) that runit manages. Hence, this check fails to find that slim is already a runit service, so the sysvinit script is run at this point.

And of course, runit tries to run slim as its ordinary service. The race happens between the regular slim service and dbus.dep-fixer.

Diagnosis: Someone moved around the runit directories and tried to duct tape it over with symlinks, but failed.

Fix: Add the line [ -d "/usr/share/runit/sv/$name" ] && continue to the loop in /usr/share/runit/sv/dbus.dep-fixer/run This allows runit to start slim as intended and prevents the double-start through the sysvinit script.

Consider this a bug report.

I'm out, and still angry.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,807  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

Runit will use sysvinit scripts if there's no runscript for the service. Not all services have runscripts because not all maintainers of service packages are interested in runit. The runit-services package has additional scripts to the ones that come with runit-init.

Bug reports go to bugs.devuan.org or bugs.debian.org depending on if it's a forked package or not. The runit packages are from debian.

Here's a readme that might have some relevant information:
https://salsa.debian.org/runit-team/run … ian/README

Mercury

Member

Registered: 2024-11-14

Posts: 7  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

^ The very first sentence of the file you linked contains misinformation:

The /etc/sv/ directory contains service directories for a collection of
services available in Debian, to have them run under runit service
supervision instead of sysvinit or through init.d scripts.

As I said, that directory does not contain regular runit services. Those are in /usr/share/runit/sv/. Someone somewhere made that change and didn't document it, and did not fix scripts that rely on it, causing breakage.

The rest of the file is not helpful; slim is already a runit service. It does not need to be migrated.

Runit will use sysvinit scripts if there's no runscript for the service.

Where is this documented?!

The reason I'm angry is because there are several layers at which proper documentation would have helped me, but it's either wrong or simply missing. I'm a developer myself, and I make it a point to properly document my code, thought I have run into plenty colleagues who don't. The lesson I've taken is that 10 minutes of docs today can save hours of work for someone else weeks, months, or years from now. In this instance, it has, in fact caused me many hours of frustration. I can't process that as anything other than disrespect for the user.

Last edited by Mercury (2026-01-30 20:40:42)

abower

Member

Registered: 2024-04-19

Posts: 25  

Re: [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled?

Consider this a bug report.

I'm out, and still angry.

There's no justification for anger. Runit has a diligent maintainer who is extremely attentive to actual bug reports - which this isn't - as you can see from his fast resolution of the bug report I posted above. Use 'reportbug runit-init'. You should include your analysis of the problem and suggested solution.