[SOLVED] OpenRC Woes

rwall · 2025-09-06 01:01:44

Hello, this is my first time here. Please forgive me for not knowing a thing or two.

I've been running Devuan for a few months now with much success. I've even managed to get it running without any problems on two of my laptops. But it's the first one, my desktop computer, that I ask about today. See, it's a conversion from Debian Sid to Devuan Ceres. Between my inexperience, and the many, many bodge fixes it's recieved that I have since forgotten about, it did not go exceptionally smoothly. But it worked, and I even got OpenRC working on it. Well, I say 'working' - two things are wrong with OpenRC on it.

First, every time it starts up, the logs are spammed with the same thing, over and over again.

/usr/lib/rc/sh/openrc-run.sh: 17: [: unexpected operator

This happens every single time it starts something up, sometimes multiple times, but only on my workstation. My X230T, which is a clean install, and my T470, which was a conversion job from Debian Sid just like the workstation, don't have these issues. Line 17 of the offending script, openrc-run.sh, is this:

if [ ! -e ${RC_SVCDIR}/softlevel ]; then

I can't tell what the problem is, but it apparently seems to be OK. I can't even get it to say what it's seeing in terms of $RC_SVCDIR by editing the shell script. However, I know it does something, because of the other problem I've been having with regards to user services.

Yes, OpenRC has user services now, and they've finally made it to Devuan. However, whenever I try to start up a process in user mode, like, say, pipewire, I get an error, one I've always seen in the openrc-run.sh whenever I try to figure out what RC_SVCDIR is:

 * You are attempting to run an openrc service on a
 * system which openrc did not boot.
 * You may be inside a chroot or you may have used
 * another initialization system to boot this system.
 * In this situation, you will get unpredictable results!
 * If you really want to do this, issue the following command:
 * touch /run/user/1000/openrc/softlevel
 * ERROR: pipewire failed to start

In this case, it seems, RC_SVCDIR is /run/user/1000/openrc, and OpenRC does not set things correctly. That's OK, this is a new thing, and I doubt Devuan's package managers have caught onto the problem. Checking other OpenRC-using distros, specifically Artix, they state that one of the prerequisites to running user processes is to have the PAM module properly loaded, which means placing the following lines in ./etc/pam.d/system-login:

# Do NOT change NOR split the below 2 lines:
session [default=1 success=ignore] pam_succeed_if.so uid >= 1000
-session optional pam_openrc.so

This is fine and dandy for Artix, but Devuan doesn't HAVE system-login in the pam.d folder. The closest I can think of are the five common-* files.

So, from this, I have several questions:

How do I make that unexpected operator message go away on boot?

What file do I put the PAM lines suggested by Artix into?

Do I need the PAM lines at all to run user services?

Why isn't Devuan's OpenRC adding the softlevel directory into /run/user/1000/openrc?

Will this become less of a mess as the package is updated in Devuan?

Andre4freedom · 2025-09-06 08:27:35

Welcome here to the Devan-community
You talk about strange phenomenons.
If you use the Devuan development-branch, you are pretty much on your own - it's for developers and testers.
The stable branch is still Devuan Daedalus (5).
There, OpenRC works exceptionally well, but please be reminded that in OpenRC the init program is still from the trusted InitSysV, and only the service-controller (the one who takes care of the daemons) is OpenRC.
I use sometimes Artix (OpenRC) and there the init program is part of OpenRC. And the structures of the logs and their placement is different (more like you show in your post).
Please read the instructions on:
https://www.devuan.org/os/install
A lot of information and help can be found in the documentation there.
Good luck.

Last edited by Andre4freedom (2025-09-06 11:00:20)

ralph.ronnquist · 2025-09-06 09:11:26

@rwall, add some double-quotes, and make that line 17 be

if [ ! -e "${RC_SVCDIR}/softlevel" ]; then

and then you won't have that problem (at least).

rwall · 2025-09-06 14:46:28

@rwall, add some double-quotes, and make that line 17 be
if [ ! -e "${RC_SVCDIR}/softlevel" ]; then
and then you won't have that problem (at least).

I've tried that on a fair few occasions. The same result occurs. I'm starting to think that RC_SVCDIR either has multiple paths or it's not set at boot. My computer has things all over the place - the root filesystem been transplanted over and over again onto different drives for six years, so it's possible things have gotten so messy that RC_SVCDIR is in multiple places.

Andre4freedom · 2025-09-06 16:00:10

So this may be the very occasion to install a fresh system:
Devuan Daedalus and choose OpenRC
or
Devuan Excalibur (if you are keen to try, although it's quite stable already) and choose OpenRC.

The standard installer does an excellent job.
Just know that Excalibur has implemented the "usr-merge" already. This makes a dist-upgrade v5 to v6 a bit tricky. Read the notes and instructions.
Good luck!

greenjeans · 2025-09-06 17:12:13

So this may be the very occasion to install a fresh system

Seconding this excellent advice.

rwall · 2025-09-06 17:37:44

I'm honestly terrified of installing a new system. This is the culmination of six years of tinkering and bodging, and so many little things have been adjusted that I've forgotten what exactly I did to make it all happen. A bunch of installed packages are no longer in the repos, custom software has been installed outside of the package repos, an unknown number of udev rules were changed, and I'm extremely unwilling to touch my xorg.conf again. I'd rather not be here with a half-functional system until 2031.

greenjeans · 2025-09-06 17:48:02

You don't have to install something to try it, burn you a hybrid iso onto a USB stick and give it a whirl, you can install packages into a live system to see if they work. It's not that scary and you obviously have some advanced skills and knowledge.

zapper · 2025-09-06 18:38:02

I recommend you avoid using ceres/sid.

If you use testing, openrc would probably work for that too, but devuan unstable is just a good way to get a broken system.

If you don't know how to fix the problems that come with unstable, use testing or stable. I cannot recommend this enough.

RedGreen925 · 2025-09-06 19:06:33

I'm honestly terrified of installing a new system. This is the culmination of six years of tinkering and bodging, and so many little things have been adjusted that I've forgotten what exactly I did to make it all happen.

In future I would recommend an install log. Every system I install I do this it is a text file where I document every change made to the system, the reason for the change and if relevant the URLs of the web page(s) where I found the solution. This method has saved many a headache in trying to figure out the changes. I also use a ## Changed by me comment section in every configuration file changed where it was changed with a similar explanation block used for the change as goes in the install log. This makes it an easy grep to find any file I have made changes to.

Last edited by RedGreen925 (2025-09-06 19:08:22)

rwall · 2025-09-06 23:25:07

Reinstalled completely. The sound is more broken than it was before, all the front-facing stuff I interacted with is now off in myriad different ways, and I still can't get OpenRC to automatically start my stuff, but hey, at least the non-fatal error is gone.

(... I don't think it was worth it)

Last edited by rwall (2025-09-06 23:25:47)

Andre4freedom · 2025-09-07 09:21:49

Dear me... @rwall....
What exact version did you install?
Which ISO file?
Which method?
What special software do you install?
Have you thought of the SysV-Init files of your software to be used with OpenRC?
(/etc/init.d/......, maybe you have to install/edit/generate these special init.files, there may exist packages for it as in artix))
What hardware are you installing on?
Have you tried the superb method of testing with a live-iso as recommended by greenjeans?
And, last but not least:
If you are asking for help on this forum, after studying the documentation, please give detailed information on your configuration. (software-sources, versions, repo-info, system,.. simply all that enables our clever and volunteering members to help or give advice.

Have a good day all the same.

stargate-sg1-cheyenne-mtn · 2025-09-07 13:44:26

major kudos and hat-tip to @Andre4freedom for expending their finite, valuable time and energy to actually post...what the rest of us were thinking.

zapper · 2025-09-08 04:37:44

@rwall stable or testing?

And if unstable, that's why its happening. Its meant for developers lol.

rwall · 2025-09-08 14:29:16

I figured out the issue, after reinstalling again. Both times, I installed Daedelus, copied over my old sources.lists and important config files, upgraded to Ceres, and reinstalled a cache of packages I downloaded before I first reinstalled to create a reasonable approximation of my old system. Turns out, the reason OpenRC on Devuan doesn't start user services is that, through some miracle of packaging, it doesn't include facilities for running user services. There's no /etc/init.d/user service to link against, and the openrc-user file in pam.d doesn't exist, either (though that's more understandable). I'll probably figure out how to write a bug report on this, assuming this isn't intentional.

I do not recommend anyone else peform the following sequence of events, and instead hope that a fix comes someday to remove the need for all this bodging. However, if you think this is at all a good idea, here's what I did to fix my issue:

Built OpenRC from source, copied /build/init.d/user from there to my /etc/init.d/, changing any references of /usr/lbexec/rc to /usr/lib/rc, as that's where OpenRC's internal utilities are installed on Devuan (Do not install all of OpenRC from source after building; that bricked my system, and you only need a single file from it anyway)

Added the following to the end of /etc/pam.d/common-session (this was pulled from the Artix wiki, and it seems to work reasonably well):
```
session [default=1 success=ignore] pam_succeed_if.so uid >= 1000
-session optional pam_openrc.so
```

Created a new /etc/pam.d/openrc-user file, with the following contents:

#%PAM-1.0
#OpenRC-User starts up the user session for OpenRC. It needs all the
#stuff a common user session has
session include common-session

Symlinked /etc/init.d/user to /etc/init.d/user.(me), as instructed, in addition to creating /etc/user/init.d/, ~/.config/rc/runlevels, and ~/.config/rc/init.d .

Doing all this allows me to run user services of some description. Though I doubt you want to see my scripts for Pipewire, they can start automatically now.

zapper · Yesterday 03:47:52

@rwall that sounds peculiar, but I am glad you found out the answer you needed

The officially official Devuan Forum!

#1 2025-09-06 01:01:44

[SOLVED] OpenRC Woes

#2 2025-09-06 08:27:35

Re: [SOLVED] OpenRC Woes

#3 2025-09-06 09:11:26

Re: [SOLVED] OpenRC Woes

#4 2025-09-06 14:46:28

Re: [SOLVED] OpenRC Woes

#5 2025-09-06 16:00:10

Re: [SOLVED] OpenRC Woes

#6 2025-09-06 17:12:13

Re: [SOLVED] OpenRC Woes

#7 2025-09-06 17:37:44

Re: [SOLVED] OpenRC Woes

#8 2025-09-06 17:48:02

Re: [SOLVED] OpenRC Woes

#9 2025-09-06 18:38:02

Re: [SOLVED] OpenRC Woes

#10 2025-09-06 19:06:33

Re: [SOLVED] OpenRC Woes

#11 2025-09-06 23:25:07

Re: [SOLVED] OpenRC Woes

#12 2025-09-07 09:21:49

Re: [SOLVED] OpenRC Woes

#13 2025-09-07 13:44:26

Re: [SOLVED] OpenRC Woes

#14 2025-09-08 04:37:44

Re: [SOLVED] OpenRC Woes

#15 2025-09-08 14:29:16

Re: [SOLVED] OpenRC Woes

#16 Yesterday 03:47:52

Re: [SOLVED] OpenRC Woes

Board footer