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

I didn't have to do anything to make runit work as a processor supervisor, it just works in both jessie and ascii. The fun bit is configuring it to run stuff ;-)
You can run it alongside SysV init and I think I saw that you can use it with OpenRC in a similar fashion, if you want your daemons supervised, i.e. restarted if they fail.

Geoff

Postfix again

I was reviewing the setup for Postfix, and having a fiddle, when I discovered that I had misunderstood the flags to the "master" program. Under SysV init, master runs with "-w", which launches it as a daemon, but does not return until the daemon is running correctly. If you omit the "-w" flag then master runs in the foreground, which is what we want! The set up then becomes very simple. All that is needed is a simple run file and you may setup logging if you wish. The "echo" in the run file is reported through the logging mechanism.

cat << EOF > run
#!/bin/sh -eu
echo "executing /etc/sv/postfix/run"
/usr/sbin/postfix check
exec /usr/lib/postfix/master
EOF

The "-eu" flags cause the script to fail on any unchecked errors. There is no need for a finish script. "ps uaxf" then reports :-

root      2658  0.0  0.0   4100   688 ?        Ss   14:31   0:00  \_ runsv postfix
log       2662  0.0  0.0   4244  1240 ?        S    14:31   0:00      \_ svlogd -tt /var/svlogd/postfix
root      3697  0.0  0.0  36168  3820 ?        Ss   15:54   0:00      \_ /usr/lib/postfix/master
postfix   3810  0.0  0.0  38232  3724 ?        S    15:54   0:00          \_ pickup -l -t unix -u -c
postfix   3811  0.0  0.0  38280  3924 ?        S    15:54   0:00          \_ qmgr -l -t unix -u

Geoff

Running "apt-cache search linux-image" shows the range of kernels available, which includes linux-image-4.13.0-0.bpo.1-amd64.
I was able to select this in Synaptic and it did not want to pull in anything else. It installed with no problem and it leaves a couple of older kernels (4.9.0-3 and 4.9.0-4) which can also be booted up. The new kernel boots up with no problem. It is too early to tell if it fixes the graphics problem, but it is no worse!

Geoff

The problem with trying to change the acceleration method is really that it is a work-around that doesn't actually work, in that it stops X from starting normally. The fix for that is to not do it ;-)

The real problem is with an instability with the graphics.

On both occasions when I have triggered it, I typed a <return> which led to a chunk of text moving vertically, which triggered the instability. In one case in emacs the chunk of text was moved down and in the other typing <return> to man, caused the chunk of text to move up.

I can imagine that the graphics driver does an optimisation and tells the graphics card to move an area of the display, rather than re-drawing it. The Arch forum article mentioned changing the acceleration method. I was looking at Xorg.0.log, to see what acceleration was being used and saw that it mentions

glamor: OpenGL accelerated X.org driver based

This problem has ony occured in the last few days, so it may have been
introduced in a recent upgrade. The kernel was updated on 17 Dec 2017

Preparing to unpack .../26-linux-image-4.9.0-4-amd64_4.9.65-3_amd64.deb ...
Unpacking linux-image-4.9.0-4-amd64 (4.9.65-3) over (4.9.51-1) ...

Grub is also offering 4.9.0-3-amd64, so I could boot that. It seems to date back to 19th Sept. What is the most helpful thing to do to track down this odd behaviour?

Geoff

Thank you for that. I can confirm that it does find the file in either /usr/share/X11/xorg.conf.d/ or /etc/X11/xorg.conf.d/. The advice about overwrites on upgrades is well made.

The bad news, however, is that the file stops X from coming up, so I had to move it out of the way. I have not yet had a chance to track down the problem yet.

Geoff

Package upgrades

I was wondering about package upgrades as it appears that many services are automatically stopped before an upgrade and restarted afterwards, or possibly simply restarted after the upgrade. To have a look at how this worked I had a look through a ".deb" file. I copied one over to somewhere safe :-

cp /var/cache/apt/archives/apache2_2.4.10-10+deb8u11_amd64.deb .

and then had a look with spacefm/Xarchiver, extracting the control.tar file into my safe area. In the "postinst" file near the end is the code fragment :-

# Automatically added by dh_installinit
if [ -x "/etc/init.d/apache2" ]; then
	update-rc.d apache2 defaults 91 09 >/dev/null
	if [ -n "$2" ]; then
		_dh_action=restart
	else
		_dh_action=start
	fi
	invoke-rc.d apache2 $_dh_action || true
fi

Indeed, prerm and postrm also use invoke-rc.d and update-rc.d to stop apache and then remove the init.d links.
Interestingly, only postrm makes reference to systemd.

I suspect that the quick workaround is to do an apt-get upgrade and stop it when it asks. You would then inspect the packages to be upgraded and if you spot any of the services you have under runit, you would stop them manually. Then you would actually do the upgrade and then you could restart the services! I'm not sure that is the best answer! Runit's "sv" program does understand init.d and can be linked to from /etc/init.d

http://smarden.org/runit/faq.html#lsb

So that might be a way to have your services handled safely, although I wonder whether any upgrades might want to overwrite the service's init.d script, which could lead to sv be overwritten!

Geoff

Current state

across 2 machines, the following are running under runit :-

slim
lxdm
autofs
bluetoothd
wicd
postfix

For most of them it is simply the case of setting up a run file containing the command along with the flag to stop it from running as a daemon, but remain attached to stdin/stdout. With a few (lxdm) it is rather the case that you leave out the flag that causes it to become a daemon. It is probably a good idea to set up logging for most of them. It is only slightly more complex when the program really does want to run as a daemon, such as postfix.

There is the question of why the SysV init scripts are so complex. I think that these have evolved this way as they check that everything has been set up correctly and where possible put things in place that should be there. It is understandable that a general purpose distribution will want everything to just work out of the box. The price of this is perhaps that the mechanism becomes more complex. One of the complexities seems to be the setting up of a PID file. I think that this is necessary so that init is able to control the service, whereas this is probably not necessary under runit.

The services which I have set up do seem to be simpler, but it may be that they do actually work because they were originally set up under SysV init, which sorted out any problems!

If you are developing a new service or have one which is not set up for SysV init, then it may be easier to get it running under runit.

Geoff

With eudev installed I am getting my wifi appearing as wlan0, but my ethernet is coming up as enx followed by the mac address. I am not sure where this is set. dmesg reports (with the mac address obscured)

[    2.372782] r8152 2-2:1.0 eth0: v1.08.8
[    2.375118] r8152 2-2:1.0 enx2a2a2a2a2a2a: renamed from eth0

Geoff

I spotted another method of hanging for a daemon (rpc.nfsd) that detaches (in the Gentoo info).
The README file for the rpc.nfsd "run" says :-
   

After it has started the daemon, which detaches, the run file then does this :-

exec chpst -L supervise/runlock chpst -l supervise/runlock true

The change process state program (chpst) uses the -L switch to open the file supervise/runlock for writing, and obtain an exclusive lock on it. It then runs another copy of chpst which similarly gets a lock on the same file and then runs and returns "true".
The difference is that -L will fail immediately if it cannot get the lock, while -l will wait until it can get the lock. This line will therefore hang until it gets "sv stop postfix", when it will terminate true so that "finish" will be executed, which is set up to actually stop postfix. This does work as described, once the control/t file was moved out of the way, which was by-passing killing off the "run" process. The normal shutdown proceedure continues as before.

The set up is now fairly simple as it is only necessary to set up "run" & "finish" along with the logging.

cd /etc/sv/postfix
cat << EOF > run
#!/bin/sh
exec 2>&1
echo "executing /etc/sv/postfix/run"
/usr/sbin/postfix start
exec chpst -L supervise/runlock chpst -l supervise/runlock true
EOF

cat << EOF > finish
#!/bin/sh
exec 2>&1
echo "calling /etc/sv/postfix/finish"
/usr/sbin/postfix stop
EOF

mkdir log
cat << EOF > log/run
exec chpst -ulog svlogd -tt /var/svlogd/postfix
EOF

chmod a+x run finish log/run

the part of the output of ps uaxf relating to the postfix daemon looks like this :-

root      2767  0.0  0.0   4100   696 ?        Ss   09:02   0:00  \_ runsv postfix
log       2768  0.0  0.0   4244   708 ?        S    09:02   0:00      \_ svlogd -tt /var/svlogd/postfix
root      2771  0.0  0.0   4104   652 ?        S    09:02   0:00      \_ chpst -l supervise/runlock true
root      2903  0.0  0.0  36168  3152 ?        Ss   09:02   0:00 /usr/lib/postfix/master -w
postfix   2904  0.0  0.0  38232  3884 ?        S    09:02   0:00  \_ pickup -l -t unix -u -c
postfix   2905  0.0  0.0  38280  3936 ?        S    09:02   0:00  \_ qmgr -l -t unix -u

Geoff

Postfix and shutdown

There is some further documentation on runit at Gentoo :-

https://wiki.gentoo.org/wiki/Runit

including some example run scripts to be found at :-

https://gitlab.com/flussence/runit-scripts

thus they offer a postfix run file :-

https://gitlab.com/flussence/runit-scri … ostfix/run

I added in -d and corrected the paths. This does seem to work, although I notice that the sub-processes also have the -d flag.

#!/bin/sh -eu
/usr/sbin/postfix check
exec /usr/lib/postfix/master -d

Although "master" is in itself a process supervisor which looks after the various postfix programs. I think that this leads into questions that have been rising in my mind about shutdown. It is not very clear from the documentation how shutdown works if you only use runit as a process supervisor. As far as I can see the shutdown mechanism would use stage 3 of runit, if you were using runit as init. (As a supervisor, it is only stage 2).

With the run file running "master" directly (with the -d flag), as above, then on shutdown, /var/log/mail.info reports

postfix/master[2795]: fatal: master_sigdeath: kill process group: No such process
postfix/postfix-script[4380]: fatal: the Postfix mail system is not running

I think that the first line is "master" receiving a signal to stop. From /var/log/syslog I can sees that at shutdown ntpd (which is not under runit) exiting on signal 15 (TERM), so I would guess that that is what "master" has received. The second line above is probably from "finish", which is being executed after "run" finishes and is therefore correct! The man page for "shutdown" says that "All processes are first notified that the system is going down by the signal SIGTERM." I have assumed that any daemons run by SysV init would have their "K" scripts in /etc/rc0.d run at shutdown, although I can't currently find the documentation on that!

As the couple of daemons that I am trying under runit are not part of the SysV init, I assume that they just receive SIGTERM.

I am wondering whether the answer is to set up runit's stage 3 and somehow trigger it at shutdown, early enough that the daemons get the signal before they get a SIGTERM from elsewhere. The sample stage 3 file for Debian Sarge looks like this :-

#!/bin/sh
exec 2>&1

PATH=/command:/sbin:/bin:/usr/sbin:/usr/bin

LAST=0
test -x /etc/runit/reboot && LAST=6

echo 'Waiting for services to stop...'
sv -w196 force-stop /etc/service/*
sv exit /etc/service/*

echo 'Shutdown...'
/etc/init.d/rc $LAST

Since runit is not in charge, presumably running /etc/init.d/rc $LAST can be commented out. I also removed /command from the path.
Maybe, this stage 3 file could be triggered as K010runit in /etc/rc[06].d to get these daemons to stop cleanly.

cd /etc/rc0.d
ln -s /etc/runit/3 K010runit3
cd /etc/rc6.d
ln -s /etc/runit/3 K010runit3

Also I looked at whether it is possible have runsv catch the SIGTERM and handle it more gracefully. The man page for runsv tells how to customise control signals, so that for SIGTERM :-

/etc/sv/postfix/control/t could contain :-

#!/bin/sh
echo We have SIGTERM for postfix
/usr/sbin/postfix stop

so this should run for "terminate" and should also pick up the control signals for "down" and "exit", according to the man page for runsv.

This does run and appear in /var/svlog/postfix/current when I give the command

sv stop postfix

I reverted the postfix "run" file to the earlier one which uses the "postfix start" command and
with stage 3 being called from rc0.d and with control/t set up, then on shutdown I can see in /var/log/syslog :-

Dec  4 10:49:58 fluorine shutdown[4884]: shutting down for system halt
Dec  4 10:49:58 fluorine init: Switching to runlevel: 0
Dec  4 10:49:59 fluorine avahi-daemon[2600]: Got SIGTERM, quitting.
Dec  4 10:49:59 fluorine avahi-daemon[2600]: Leaving mDNS multicast group on interface xenbr0.IPv6 with address fe...
Dec  4 10:49:59 fluorine avahi-daemon[2600]: Leaving mDNS multicast group on interface xenbr0.IPv4 with address 19...
Dec  4 10:49:59 fluorine avahi-daemon[2600]: avahi-daemon 0.6.31 exiting.
Dec  4 10:50:00 fluorine postfix/master[2924]: terminating on signal 15
Dec  4 10:50:00 fluorine ntpd[2466]: ntpd exiting on signal 15
Dec  4 10:50:00 fluorine postfix/postfix-script[5281]: fatal: the Postfix mail system is not running
Dec  4 10:50:00 fluorine postfix/postfix-script[5289]: fatal: the Postfix mail system is not running
Dec  4 10:50:01 fluorine acpid: exiting
Dec  4 10:50:03 fluorine rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="2166" x-info="http://www.rsyslog.com"] exiting on signal 15.

I think that the 2 fatal messages are from "finish" and control/t being called after "master" has alread received SIGTERM, although the echo messages are not appearing in /var/svlogd/postfix/current, maybe svlogd has already been shutdown!

I can see that before I started trying runit and with postfix being started from SysV init, that on shutdown /var/log/mail.info reports :-

Nov 11 12:23:20 fluorine postfix/master[2909]: terminating on signal 15

So the set up with "runit" seems to produce more or less the same result as with SysV init. Setting up to run stage 3 from rc0.d and also setting up control/t does not appear to have any real effect on shutdown.

Geoff

Postfix

Running the display manager under runit was very straightforward. I also tried something more complex. As a domestic user I use an mail provider, GMX in my case. However, some system messages are generated locally for delivery to root. Although I recall that exim had been installed, I had earlier experience with postfix, so I had installed that instead and configured it for my requirements and it was working well. This was obviously a prime target for trying out under runit!

Looking at /etc/init.d/postfix I found nearly 1000 lines of impenetrable script. Whereas, I thought that the actual command to start postfix was :-

postfix start

and the actual daemon which is left running is "/usr/lib/postfix/master -w".

There is an example "run" file in the documentation and I tried it

#!/bin/sh
exec 1>&2
 
daemon_directory=/usr/lib/postfix \
command_directory=/usr/sbin \
config_directory=/etc/postfix \
queue_directory=/var/spool/postfix \
mail_owner=postfix \
setgid_group=postdrop \
  /etc/postfix/postfix-script check || exit 1

exec /usr/lib/postfix/master

This did not work well. It appeared to be checking every single file on the system and spotting that most were not owned by postfix! It also failed to run the daemon.

After some fiddling around I decided to try and keep it simple. Since "postfix start" does actually work, why not use it? Well it finishes and returns, which is not how runit works. I therefore set up a simple kludge, /etc/sv/postfix/run :-

#!/bin/sh
exec 1>&2

/usr/sbin/postfix start
while /usr/sbin/postfix status
do sleep 300
done

This does actually work! It also puts out a timestamp every 5 minutes in the log file.

I was not sure how things would work at shutdown, so I also set up a "finish" file. This is described as being executed if "run" stops.
/etc/sv/postfix/finish

#!/bin/sh
echo "calling /etc/sv/postfix/finish"
/usr/sbin/postfix stop

My hope is that if things are not shutdown properly, then this would tidy it all up! What I see in /var/log/mail.info is that the "master" daemon reports

postfix/master[2916]: terminating on signal 15
postfix/postfix-script[4443]: fatal: the Postfix mail system is not running

I think that the second line is saying that it can't stop as it isn't running.
Postfix does its own logging via syslog.

This simple set up seems to work ok, although not really in the spirit of runit!

Geoff

I only use the codenames, as in "jessie" in the repositories, but synaptic seems to report the versions as being from "stable". Also, if you select the "origin" display in synaptic, then the repositories are shown as "stable" etc. They are all from "pkgmaster.devuan.org".

Geoff