openrc support in init-system-helpers part 1

[Matthias Geiger]

On Sat, 22 Aug 2026 03:31, Lorenzo <plorenzo at disroot.org> wrote:
>Hi Matthias,
>
>late reply but I'm still on vacation, I hope that few pointers are
>better than nothing 
>
Hi Lorenzo,

thanks, no worries at all!
>> One other issue I have the name. rc-service and openrc are already 
>> taken; how would I name such a helper then?
>
>looking at other helpers, it could be something like openrc-helper
>(similar to runit-helper) or deb-openrc-helper (similar to systemd's
>deb-systemd-helper) and/or deb-openrc-invoke ?
>
Right, thanks. For now I called it rc-helper, but deb-openrc-helper 
sounds nice.
>> implemented. To autostart services on package installation, we need 
>> debhelper support, essential dh_installinit. 
>
>not sure if the idea is to use dh_installinit for openrc, but I would
>rather use dh_openrc or dh_installopenrc; developers will likely look
>for an equivalent of dh_installsystemd and it would not be obvious that
>openrc support is in dh_installinit; also openrc support would be
>coupled to sysvinit (think if you want to ship a service disabled but
>the sysvinit script is shipped as enabled)
>
>> However, that in turn 
>> requires init-system-helper support.
>
>Yes and no: if you do like sysvinit and systemd, then yes; if you do
>like runit and package and external helper like runit-helper, then
>mostly no.
>But keep in mind that, for purge operations, you would still need
>an helper such as 'openrc-purge-helper' inside an essential package,
>because purge happens at postrm and even if a foo-package depends on
>your 'openrc-helper' package, such dependency is not guaranteed to be
>installed after the foo-package has been removed..
>So yes, is better if you manage to merge your openrc helper(s) into
>init-system-helper.
>
Once upstream releases 0.64, I can make my case for debian-policy 
(services can be started from under /usr then; see #1138547 for full 
context).

This is what my plan hinges on: If I can get openrc into policy, that is 
a mighty sword to wield. There would be no technical reason to refuse 
its support in i-s-h (or any relevant package, for that matter), and I 
can then add support for it in dh_installinit after.
Then I could go and nag package maintainers to include native services.
>> how I would reliably determine I was
>> running under 
>> sysvinit.
>
>* detecting running init: i think the current way is
>    if [ -d "/run/systemd/system" ]; then
>        #systemd
>    elif [ -f /run/openrc/softlevel ]; then
>        #openrc
>    elif [  -f /etc/runit/stopit ]; then
>        #runit
>    elif [ -p /run/initctl ]; then
>        #sysvinit
I think this might need an additional check, since under openrc with 
sysvinit, both /run/initctl and /run/openrc/softlevel exist.

So maybe:

.. elif [ -p /run/initctl ] && [ ! -f /run/openrc/softlevel ]
sysvinit
 elif [ -p /run/initctl ] && [  -f /run/openrc/softlevel ]
 openrc-lsb

 elif [ ! -p /run/initctl ] && [ -f /run/openrc/softlevel ]
 openrc-native


>    fi
>   but look inside invoke-rc.d and or reportbug; note that order of
>   testing matters: systemd had support for initctl pipe, so it had to
>   be tested first; I would look for the running init rather than for
>   an installed package, the latter has false positives, like during an
>   init switch or if one starts a non default init at boot with the
>   kernel command line
>
Ah, thanks. This helps a lot, definitely stealing that.

>* consider the "old" policy-rc.d mechanism
>  https://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt
>  see also invoke-rc.d(8)
>  you have to check for /usr/sbin/policy-rc.d (if exists) and when it
>  returns 101 do nothing; example: you don't want to run/signal services
>  during the installation process; you don't want to run services in a
>  sbuild chroot.
>
Right, thanks, much appreciated.
>* you likely want to design an override mechanism for sysvinit scripts:
>  sysvinit script are run unconditionally (regardless or the running
>  init) in maintscripts so if you have a native openrc service you end
>  up with duplicate instances of the same service. So when there is a
>  native openrc service you want to "mask" the init script.
>  For example, I think systemd uses the 'invoke-rc.d
>  --skip-systemd-native' flag; previously they used
>  /usr/lib/lsb/init-functions.d/40-systemd
>  (I strongly recommend against 40-systemd); runit has a configurable
>  mechanism for each runscript, see
>  https://salsa.debian.org/debian/runit/-/blob/master/debian/contrib/runit-default?ref_type=heads
>  and
>  https://salsa.debian.org/debian/runit/-/blob/master/debian/contrib/i-s-h/invoke-rc.d-runit.patch?ref_type=heads
>
Thanks. The plan is to store "native" openrc scripts under 
/usr/lib/rc/init.d; I have to ask upstream again if /etc/init.d would be 
ignored then (or what takes preference). I already tested that a 
sysvinit script under /etc/init.d with native openrc does not start at 
all (by default), and refuses to run anyway; though I did not check 
package installation. So since only openrc-only services will be 
supported, this can and should go into i-s-h IMO. Regardless, masking 
the sysvinit service seems very sensible.
>> .
>> Am I correct in assuming that this is where I would abstract all
>> checks, such as only starting a openrc service if we are truly
>> running a openrc system? 
>> 
>> I think most functionality would be a thin wrapper over rc-service,
>> so I do not see a huge benefit there, but apparently this has to be
>> done this way?
>
>> Second, which command line flags to implement etc.
>
>I will try to answer this tomorrow
>
Thanks! I already started with a bare getopts skeleton, I can try to push 
that later.


best,


-- 

Matthias Geiger <werdahias>

Debian Developer -- KiCad Contributor
GPG: ECBEDBB607B9B2BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: Digital signature
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20260822/31fa5f5b/attachment.sig>