https://bugs.debian.org/cgi-bin/bugrepo … bug=958820

and I have had a positive reply and now 0.42-1 has come through
from sid to Ceres. I have not yet had a chance to test this,
but will report when I have.

Geoff

http://kulcha.x10host.com/shutdown.jpg

The running of pstree is from sendsigs rather than from openrc-init itself.

After it enters the runlevel shutdown it runs the sendsigs script with stop, which then returns a warning, although I don't see anything really wrong. It then goes on to close things down from the sysinit runlevel, such as the network and unmounting the filesystems.

Geoff

cat 0010-init-runlevel-off.patch

Geoff

Geoff

As my desktop is used for running VMs under Xen, it uses lvm to handle the disks for the VMs. The desktop also boots from BIOS. I have checked my laptop, which boots on the real hardware and boot with UEFI. Before applying my above mod, there was also the problem with the file systems not shutting down properly, particularly /home. This only shows as it boots up. The logging is a bit different from my desktop, and the shutdown runlevel does not get logged. The other logging oddity is that the sysinit runlevel gets logged twice. The documentation seems to suggest that sysinit won't get logged at all!

Geoff

* edited to add that the RPC processes were rpc.statd and rpcbind

As it shuts down, there is a warning message on the screen, but I have not been able to read it yet, but will work on this.

Geoff

with openrc-init :-

It would appear that the simplest thing to do would be to add in the runlevel off before shutdown in openrc-init.

Both boot and shutdown runlevels are empty. off has the entries savecache, sendsigs and umount[nfs.sh|fs|root]. I think that moving to off will cause the entries in default to be stopped, apart from those also in off. The umount* ones will therefore not be stopped, as they are already "started" as they are dependents on entries in default. These will be stopped when moving to shutdown. Their start routines are no-ops, only stop does anything. In the case of umount, I think this is obvious. The savecache entry does its thing on start.

Of course, the simplest thing is not necessarily the best thing to do! Is it important to keep OpenRC as close as possible to the original, or is compatibility with SysV init more important. Debian has put in quite a bit of effort to bring in SysV init compatibility.

Geoff

In /var/log/rc.log it reports that /tmp, /var and /home failed to unmount as the target is busy. Then on booting fsck has to recover the journal on /var and /home. This only happens when using openrc-init and not with SysV init.

With SysV init being used to start OpenRC, it uses /etc/init.d/rc to get openrc running.
When shutting down rc 0 calls openrc off and then openrc shutdown. This gets logged as rc off and appears to run through default stopping the entries in reverse order. This is because it is leaving the default runlevel and stops any services not in the new runlevel, i.e. off.

Compared to using openrc-init, where it is logged as rc shutdown. This also runs through the entries in default and stops them in reverse order. It then appears to take the entries in sysinit, again,  stopping them in reverse order. This includes the umount[nfs|fs|root] scripts, which are notionally started as they are dependencies of other scripts.

The dependencies do my head in. Which way round are the dependencies? The LSB headers are described in the Debian docs :-

https://wiki.debian.org/LSBInitScripts/
https://wiki.debian.org/LSBInitScripts/ … yBasedBoot

In the LSB headers the Required-Start: and Required-Stop: tend to be the same-ish.

Although OpenRC does not use insserv, it is interesting to use it to see the dependencies also using dotty, as described in the Debian docs. You probably have insserv anyway, but you might need to install dotty :-

apt install insserv graphviz

then as yourself :-

cd /tmp
/usr/share/insserv/check-initd-order -g > boot.dot
/usr/share/insserv/check-initd-order -g -k > reboot.dot
dotty boot.dot &
dotty reboot.dot &

Note that you should "read" the graph for reboot/halt from right to left.

Coming up, it brings up the network and mounts the file systems. $remote_fs is taken as the milestone that the FS is available. Then the logger is started and $syslog is taken as the milestone to start the daemons. $all is the milestone that it has all been done so that local stuff can be started.

Going down, the daemons are stopped and then $remote_fs is the milestone to be stopped. This uses sendsigs to stop stuff and then stops rsyslog and then unmounts nfs and stops the networking. After that $local_fs is stopped and finally umountroot.

Comparing the dotty graphs lvm2 has :-

and lvm2 appears to be started before mountall has started.

rsyslog has :-

and rsyslog appears to be stopped after sendsigs has been stopped.

I am getting a clearer picture, but more head scratching is required...

Geoff

The script for shutting down is a very crude thing and would not win any awards for beauty, but it does work. It looks like this :-

cat << "EOF" > /usr/local/bin/my-logout-query
#!/bin/bash

xmessage \
    -geometry 650x100+1700+400 \
    -font 10x20 \
    -bd red \
    -bg yellow \
    -fg black \
    -title "Shutdown/Logout" \
    -buttons Shutdown:101,Reboot:102,Logout:103,Cancel:104 \
    "How do you want to leave the computer?"

answer=$?

case "$answer" in
     101)
#        echo shutdown
	sudo /sbin/openrc-shutdown -p now
        ;;
     102)
#        echo reboot
	sudo /sbin/openrc-shutdown -r now
        ;;
     103)
#         echo logout
#        /usr/bin/lxsession-logout
        /usr/bin/lxqt-leave --logout
        ;;
     104)
        echo cancel
        ;;
esac
EOF
chmod a+x /usr/local/bin/my-logout-query

You may need to adjust the geometry to fit your screen.

As myself :-

cd .local/share/applications
cp /usr/share/applications/lxqt-leave.desktop my-leave.desktop

I then edited my-leave.desktop to change the "Exec" line from lxqt-leave to

Then it should appear in the LXQt menu under the Leave options. If you have a quicklaunch plugin it is possible to drag a copy of leave and drop it on the quicklaunch as an easy way of shutting down. I have a second quicklaunch on the far right of the LXQt panel, just for this purpose.

I have tried openrc-shutdown while SysV init was still in use and it seems to work correctly, so it is possible to set this up before looking at replacing SysV init with openrc-init.

Geoff

As Openrc 0.42.1 seems to be happy on a VM under Xen I thought that I should check it on real hardware. I tried it on my desktop machine.
This usually boots under the Xen hypervisor with Beowulf as the controlling OS, Dom0. This machine is still using SysV init to start things.
I simply used the deb files I had created earlier, as described above, and the command :-

dpkg -i libeinfo1_0.42.1-1_amd64.deb librc1_0.42.1-1_amd64.deb openrc_0.42.1-1_amd64.deb

The machine rebooted as normal as Dom0 but running 0.42.1 and all looks normal.
I then rebooted with it running on the bare metal and it still looks normal.

I have also installed 0.42.1 on my laptop. I had previously put the Gentoo openrc-init 0.41.2 on this to replace SysV init. I had also hacked up a small script to use openrc-shutdown, which could be used from LXQt. After installing 0.42.1 it still works as before.
It is documented that this later version of openrc-shutdown will also work with SysV init, although I have not tested this.

Geoff

This file was derived from agetty. The name agetty has been changed to getty
and a couple of variables from /etc/conf.d/agetty have been incorporated.
It extracts the name of the device from the end of the name of the file it was started from, e.g. getty.tty
It uses the OpenRC native format of init file and also uses the supervise-daemon which is part of OpenrRC.

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

Geoff

edited to add quotes round "EOF" to stop substitutions.

The default set-up in Debian (and hence Devuan) is that SysV init is started at boot time.
SysV init, as usual reads /etc/inittab, which is unchanged and thus sets up the ttys.
Openrc gets called from within inittab by rcS and rc which are scripts that have been
replaced by the openrc package.

If we replace SysV init with openrc-init, then we need to have openrc set up the ttys. The Openrc sources
provide init files for agetty. In various earlier attempts to get this working I had got a copy of agetty
in /etc/init.d and changed it into getty. Then the Gentoo recommendation is to set up a link with the
name of the device appended. As I am testing this in a VM under Xen, the console is called hvc0 and
I also set up tty1.

cd /etc/init.d
chmod a+x getty
ln -s getty getty.hvc0
ln -s getty getty.tty1

These are then activated in the usual Openrc way with

rc-update add getty.hvc0
rc-update add getty.tty1

The next thing was to add init=/sbin/openrc-init to the kernel start-up.
As this was booting up under Xen using pygrub I needed to edit menu.lst.

cd /boot/grub

and edited menu.lst so that the selected entry read :-

Rebooting then worked successfully. The console messages included :-

Having logged in via vnc ps axjf shows, inter alia :-

This all appears to be running nicely and it is possible to log in via the console.
Looking at /var/log/rc.log appears to be correct including when the machine gets shut down.

There are error messages about getty is the name of a real and virtual service.
It would be good to get rid of those.

The other thing to do would be to ensure that either the agetty or getty init script
is left somewhere sensible by the package. I am not sure which name should be used and
whether it makes any difference.
It might be possible to put the (a)getty directly in /etc/init.d or maybe somewhere else,
perhaps with the other Gentoo init scripts, as examples.
The Gentoo people seem to like having fairly generic init.d files with corresponding configuration files
in /etc/conf.d, with the expectation that you would only edit the files in conf.d.

The other thing about running openrc-init is that when you shut it down you need to use openrc-shutdown instead of shutdown.
This also takes the usual flags such as -r for reboot and -H for halt.

Geoff

edited to add chmod getty

which I edited to be :-

I think that the removal of test meant that the original line did not match the patch. I also presume that lsb2rcconf is to accommodate a real source code patch to handle the LSB headers in init files, providing dependency information, for Debian.

Geoff

The advice on using dch to generate the changelog entry is very good, as the format is very important, or debmake will get upset!

The failure of signing did not seem to cause any problems but I assume that the -us -uc flags stop the warnings.

Geoff

You can use this to generate the new changelog entry automagically:

dch -v $version_number

Replace $version_number with the actual version number then add in the details for the change. The dch command can be found in the devscripts package.

If you export $DEBEMAIL & $DEBFULLNAME from ~/.bashrc (or whichever shell initialisation file is appropriate) those will also be added in for you. See https://www.debian.org/doc/manuals/debm … mail-setup (the rest of that guide is very good).

Use this to create unsigned packages:

debuild -us -uc