https://dev1galaxy.org/viewtopic.php?id=3371

A newer version is now available in Ceres, although there remains a bug related to openrc-init during shutdown.

Geoff

As mentioned, OpenRC can use the existing init scripts as is, but if you re-do a script, you can set it up to do supervision, as in the above example of agetty, although SysV init already supervises getty! The other feature that OpenRC brings is that you can start services in parallel, although it does tend to make the logs a bit untidy. With OpenRC being started from SysV init, things seem to work very nicely and with little impact on the running of the machine. Once you replace SysV init with openrc-init, then the shutdown behaviour is changed as openrc-init uses different signals, so you tend to end up using openrc-shutdown. With openrc-init running the logging in rc.log is tidier, compared when started from SysV init, when I was seeing duplicates of the different phases.

Geoff

Debians implementation of openrc init uses /sbin/init (obviously).  /etc/inittab, /etc/init.d/rcS, and /etc/rc are used to run openrc runlevel sysinit (until completion) and then runlevel default.  Note runlevel boot is not used in Debians implementation.  "running" these runlevels is executing /sbin/openrc with the runlevel as the commandline arg.

When running openrc-init (as demonstrated by @Geoff42), /sbin/init, initab, rcS, rc are not used.  Instead openrc-init has hard-coded (in openrc-init.c) the running of runlevel sysinit, followed by runlevel boot, followed by runlevel default.  "default" can be overridden with a commandline arg to openrc-init.

Also, it appears that Debian has added patches to openrc for the LSB and insserv support.  This support is not included in vanilla openrc.  This modification provides the ability for openrc to use stock sysvinit init scripts (via LSB) and thus not requiring all init scripts to be rewritten to openrc-run interpretive specs (/bin/sh can be used).  This is good in that it allows openrc to be run with minimal changes, from sysvinit.  Debians process for using LSB and insserv does not use the 3 hidden .depend.* files in /etc/init.d, instead processes the LSB headers directly (thus the 3 .depend.* files are not used).

Thanks @Geoff42 for your persistent work in getting openrc-init to boot!

Geoff

I had downloaded the 0.41.2 sources, as above, and run make, then :-

Either copy the files from your copy of the source tree or from their github at :-
https://github.com/OpenRC/openrc/blob/m … /agetty.in
https://github.com/OpenRC/openrc/blob/m … f.d/agetty

cp /home/user1/src/Devuan/openrc-0.41.2/src/rc/openrc-init /sbin/openrc-init.41
cd /etc/init.d/
cp /home/user1/src/Devuan/openrc-0.41.2/init.d/agetty .
chmod a+x agetty
cd ../conf.d/
cp /home/user1/src/Devuan/openrc-0.41.2/conf.d/agetty .

I think the idea is that you leave init.d/agetty as is and put your edits in conf.d/agetty

ln -sr /etc/init.d/agetty /etc/init.d/agetty.tty1
rc-update add agetty.tty1 default
cd /boot/grub
nano grub.cfg

add to the linux line in a spare entry init=/sbin/openrc-init.41

Then rebooted and selected the OpenRC-init option and it all seemed to work nicely.

The next step was to set up grub 'properly' so edited /etc/default/grub and added

init=/sbin/openrc-init.41

thus to

GRUB_CMDLINE_LINUX_DEFAULT="earlyprintk=vga,keep net.ifnames=0 init=/sbin/openrc-init.41"

followed by update-grub.

Geoff

https://github.com/OpenRC/openrc/releases

tar xvf openrc-0.41.2.tar.gz
cd openrc-0.41.2
make

then as root

cp src/rc/openrc-init /sbin/openrc-init.41
cd /boot/grub
nano menu.lst

where I changed the kernel line to init=openrc-init.41, remembering that I had another kernel which could boot SysV init if necessary!

When I booted up using the 0.41.2 openrc-init, it seems to work nicely and everything has come up without any errors.

I'm sure it is not good practice to mix version stuff like this, but openrc-init is quite simple and I seem to have got away with it ;-)

Geoff

I notice that the code you quote from openrc-init is a bit different from that on the github OpenRC.

https://github.com/OpenRC/openrc/blob/m … nrc-init.c

Their version does not obviously wait for do_openrc to finish and do_openrc itself appears to execlp the runlevel.
I am not an expert C coder so I may mis-understand what it is doing, but doesn't each level just get started asynchronously?

Geoff

Just to tidy up-
Yes, in effect; it would be "each level just get started asynchronously" from the code change in init(), but the new code moved the waitpid out of from init() down into do_openrc() at line 73:

while (waitpid(pid, NULL, 0) != pid)

Thus the return from do_openrc() wont happen until the "whatever we need to do to ensure all has started..."  has actually started.

EDIT- To clarify; The transition of sysinit-boot-default will not be asynchronously.  atleast in the intent of the coding.

Geoff

Geoff 42 wrote:

I think that OpenRC does not use the .depends files in init.d, as those files are based on the init runlevels 1 to 6,
while OpenRC uses /etc/runlevels/, which in my case are sysinit, boot and default. I am now wondering whether boot and default are starting up before sysinit has finished.

I thought OpenRC does use the .depend files, at each bootup to generate the /run/openrc directory.  This is how the LSB code in the init scripts ends up being used by OpenRC, and the dependencies all work as expected.   I played around with this some with some test scripts and it seemed thats the way it worked.  But I may be mistaken, I will look into this further.

It appears OpenRC does NOT use the .depend.* files in /etc/init.d.  Instead directly using the LSB header info within the scripts.  I ran some tests; changing the #Required-Start: in a particular script in /etc/init.d, and also manually changing the scripts entry in depend.boot to something different from that.  The change to the script file was picked up on next boot, and the change to .depend.boot was not picked up at all.  I then deleted the 3 .depend files, rebooted, and nobody complained.

The change I made to the script file was reflected in /run/openrc/deptree as well as the actual running of the script, at the next boot after the change.

I see that the changes are recent :-

https://github.com/OpenRC/openrc/commit … 65898b2411

and are to do with waiting for the child process.

Geoff

Edit: the bug report :-

https://github.com/OpenRC/openrc/pull/300

The code I posted and was looking into was from Debian testing, most likely what you are running.  And as you have found out, there seems to indeed be a problem with the child processes, and the github source is reflecting the current attempts being made to fix it.  There is significant difference in the current Debian code, and the patches reflected in the github version; in the init as well as do_openrc functions.

https://github.com/OpenRC/openrc/commit … 65898b2411

and are to do with waiting for the child process.

Geoff

Edit: the bug report :-

https://github.com/OpenRC/openrc/pull/300

https://github.com/OpenRC/openrc/blob/m … nrc-init.c

Their version does not obviously wait for do_openrc to finish and do_openrc itself appears to execlp the runlevel.
I am not an expert C coder so I may mis-understand what it is doing, but doesn't each level just get started asynchronously?

Geoff

rc_depend_strict="YES"

to see if it made any difference and it didn't :-(

Geoff

https://raw.githubusercontent.com/OpenR … /agetty.in

It includes supervision and is in the openrc-run style.
I have edited it a bit, to change the name to getty, for the #!/sbin path and to put in the options I like, the --noclear leaves the logging messages on the screen. I am not sure about the "keyword -prefix", which I think may be a Gentoo-ism.

cat << EOF > /etc/init.d/getty
#!/sbin/openrc-run
# Copyright (c) 2017 The OpenRC Authors.
# See the Authors file at the top-level directory of this distribution and
# https://github.com/OpenRC/openrc/blob/master/AUTHORS
#
# This file is part of OpenRC. It is subject to the license terms in
# the LICENSE file found in the top-level directory of this
# distribution and at https://github.com/OpenRC/openrc/blob/master/LICENSE
# This file may not be copied, modified, propagated, or distributed
# except according to the terms contained in the LICENSE file.

description="start getty on a terminal line"
supervisor=supervise-daemon
baud="38400"
port="${RC_SVCNAME#*.}"
respawn_period="${respawn_period:-60}"
term_type="${term_type:-linux}"
getty_options="--noclear"
command=/sbin/getty
command_args_foreground="${getty_options} ${port} ${baud} ${term_type}"
pidfile="/run/${RC_SVCNAME}.pid"

depend() {
	after local
	keyword -prefix
}

start_pre() {
	if [ -z "$port" ]; then
		eerror "${RC_SVCNAME} cannot be started directly. You must create"
		eerror "symbolic links to it for the ports you want to start"
		eerror "getty on and add those to the appropriate runlevels."
		return 1
	else
		export EINFO_QUIET="${quiet:-yes}"
	fi
}

stop_pre()
{
	export EINFO_QUIET="${quiet:-yes}"
}
EOF

This now works correctly and I can see it on ps

$ ps axjf| grep getty
    1  2011   664   664 ?           -1 S        0   0:00 supervise-daemon getty.hvc0 --start --pidfile /run/getty.hvc0.pid --respawn-period 60 /sbin/getty -- --noclear hvc0 38400 linux
 2011  2012  2012  2012 hvc0      2012 Ss+      0   0:00  \_ /sbin/getty --noclear hvc0 38400 linux

I can also see it in /var/log/boot

Fri Apr 12 13:40:21 2019:  * Executing: /lib/rc/sh/openrc-run.sh /lib/rc/sh/openrc-run.sh /etc/init.d/networking start
Fri Apr 12 13:40:21 2019: [....] Configuring network interfaces... exim4??7[ ok 8??.
Fri Apr 12 13:40:21 2019:  * Executing: /lib/rc/sh/openrc-run.sh /lib/rc/sh/openrc-run.sh /etc/init.d/getty.hvc0 start
Fri Apr 12 13:40:21 2019:  * supervise-daemon: fopen `/run/getty.hvc0.pid': No such file or directory
Fri Apr 12 13:40:21 2019:  * Detaching to start `/sbin/getty'
Fri Apr 12 13:40:22 2019:  * Executing: /lib/rc/sh/openrc-run.sh /lib/rc/sh/openrc-run.sh /etc/init.d/haveged start
Fri Apr 12 13:40:22 2019:  * Executing: /lib/rc/sh/openrc-run.sh /lib/rc/sh/openrc-run.sh /etc/init.d/irqbalance start
Fri Apr 12 13:40:22 2019: Internet Systems Consortium DHCP Client 4.4.1

interestingly the PID file does exist from a similar time :-

-rw-r--r-- 1 root root 5 Apr 12 13:40 /run/getty.hvc0.pid

With this now running, I could log in on the console, as the prompt has now appeared.

Geoff