https://dev1galaxy.org/viewtopic.php?id=2078
Geoff
]]>cd /etc/service
rm bluetoothd
this has now stopped bluetoothd. It appears that in setting up the init links the command does not run if there is a conflicting set-up, so it is easiest to remove the links and then set them to the default.
cd /etc/init.d
update-rc.d bluetooth remove
update-rc.d bluetooth defaults
This has now re-instated the links in /etc/rc2.d etc.
The machine was rebooted and bluetoothd was running normally.
The next one to try was lxdm. I set up the links first and then stopped it under runit, as it may well crash X.
cd /etc/init.d
update-rc.d lxdm remove
update-rc.d lxdm defaults
I then logged out and switched to the console with <CTRL><ALT><F1> and logged in as root
cd /etc/service
rm lxdm
shutdown -r now
This then came back normally with lxdm running under init.
It was now clear to put the remaining services under init, which in the case of my laptop was autofs and wicd.
cd /etc/init.d
update-rc.d autofs remove
update-rc.d autofs defaults
update-rc.d wicd remove
update-rc.d wicd defaults
cd /etc/service
rm autofs wicd
and then reboot. (Although this reboot could probably have waited until after the following step.)
All the services are now running normally and runsvdir is still running but not doing anything!
I edited /etc/inittab and commented out the line at the end which was running runsvdir, thus :-
#runit-sysv maintscript -- BEGIN
#SV:123456:respawn:/etc/runit/2
#runit-sysv maintscript -- END
A reboot then left everything running in a normal state. I will report on OpenRC in another thread.
https://dev1galaxy.org/viewtopic.php?id=2072
Geoff
]]>Geoff
]]>When I upgraded my Jessie machine to Ascii, runit did not start. It should be started by a line added at the end of /etc/inittab. The upgrade had removed the start-up script from where it was. The script is now to be found as /etc/runit/2. The end of /etc/inittab should thus now be :-
#-- runit begin
SV:123456:respawn:/etc/runit/2
#-- runit end
and runit will then carry on supervising the processes which you have set up.
Geoff
]]>Booting:
/etc/init.d/rcS - Executes the symlinks to the actual startup scripts located in /etc/rc.d/S##xxxxxx with option "start".
/etc/init.d/rmnologin - Removes the /etc/nologin file as the last step in the boot process, if DELAYLOGIN=yes.
Shutting down:
/etc/init.d/rc - Main runlevel control script.
If your end goal is to use runit along with sysvinit for booting and shutting down, this is not a problem. For simplicity, however, I wanted to use runit independent of anything else. Attempting to purge all sysvinit packages along with the initscripts package resulted in an unbootable system. To circumvent this problem, I manually compiled Void Linux's runit configs along with their executables for rebooting, shutting down, etc. This allowed the system to boot again. In my opinion, Void's implementation for runit is far superior to that of Devuan's. If Void's runit could be used for Devuan, there is one other package I would like to be able to remove: init-system-helpers. init-system-helpers, from the information I could find, is only useful for switching between sysvinit and systemd. I don't see how it's necessary if runit is being used as PID 1.
]]>but in those days nothing its standard unless systemd! oughtch! oh no! what i said!
]]>Another interesting example is Apache. It seems that the way to start it is with "apache2ctl start" as that is the way to get the environment set-up correctly. This results in the daemon(s) running in the background. The "run" file should wait for the daemon(s) to stop. As apache produces a pid file, it is easy to find the top daemon. What we would like to do is "wait $PID". Unfortunately this does not work as $PID is not a child of mine! It is, however, possible to look at /proc/$PID :-
https://stackoverflow.com/questions/105 … -to-finish
while [[ ( -d /proc/$PID ) && ( -z `grep zombie /proc/$PID/status` ) ]]; do
sleep 1
done
Although I got a syntactical error with this, so I ended up with this "run" file :-
#!/bin/sh -eu
exec 2>&1
echo "executing /etc/sv/apache2/run"
/usr/sbin/apache2ctl configtest
/usr/sbin/apache2ctl start
# allow time for the PID file to be written
n=0
until [ -s /var/run/apache2/apache2.pid ]
do
if [ $n -gt 5 ]
then
echo "/var/run/apache2/apache2.pid not found after ${n}s.
exit 1
fi
n=$(( $n + 1 ))
sleep 1
done
read PID < /var/run/apache2/apache2.pid
echo "apache2 running as pid ${PID}."
# wait for the $PID to stop
while [ -d /proc/$PID ] && [ -z `grep zombie /proc/$PID/status` ]
do
sleep 60
done
I also set up a "finish" file as stopping the "run" script would not stop apache.
#!/bin/sh
# exec 2&>1
echo "calling /etc/sv/apache2/finish"
/usr/sbin/apache2ctl stop
I had wondered whether I could use chpst to put a lock on /proc/$PID or one of the files in that directory and then have a second copy of chpst to wait to get a lock on that file, to avoid the looping, but I though that it was best to avoid playing with the procfs!
I wonder whether one should take a different course of action if the $PID becomes a zombie?
Geoff
]]>yeah unmantained but the point it's due it's excelent compatibility (no need of any change for usage alongside with sysvinit)
can be a strategy move to more distributions and non-linux OS found a cooperative way to stop the alienate systemd process
we must take in consideration the workload to manpowers in devuan, what happened when project grow so many more thant the amount of developer can support? will be good a little of cooperative help beetweent MANY and not litle distros
]]>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
]]>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
]]>The next service to try was postgresql. This proved to be a bit more complex, in that there was more to set up.
The command line according to the ps command was :-
/usr/lib/postgresql/9.4/bin/postgres -D /var/lib/postgresql/9.4/main -c config_file=/etc/postgresql/9.4/main/postgresql.conf
Logging was set up and then on putting this command into the run file it failed to run. The log file reported that postgres must not be run as root. "chpst" was then used to set the user and group to postgres:postgres. This then failed as it could not read the ssl certificate. "chpst" allows for a number of groups to be set so using postgres:postgres:ssl-cert seems to work, although postgres is already in the ssl-group in /etc/group! The next problem was that it needed the socket directory to be created in /var/run, which, as it is a tmpfs, disappears on a re-boot. It was also clear that the stats sub-directory also needed to be recreated. This can be done with install, to set up permissions and ownership in one command.
This then seems to work, but there are a number of directories involved and these may change with versions, indeed the version number is included in several of the directories. It therefore seemed reasonable to make these easy to configure. There is some documentation on clusters of databases, but I am only running one. It may be that the one database is called "main" by default and that that part of the path names should also be easy to configure.
The currently working set up is like this :-
mkdir /etc/sv/postgresql
cd /etc/sv/postgresql
cat << EOF > run
#!/bin/sh -eu
exec 2>&1
VERSION="9.4"
PGBINROOT="/usr/lib/postgresql"
RUNROOT="/var/run/postgresql"
DATAROOT="/var/lib/postgresql"
CONFROOT="/etc/postgresql"
BINFILE="${PGBINROOT}/${VERSION}/bin/postgres"
STATDIR="${RUNROOT}/${VERSION}-main.pg_stat_tmp"
DATAFILE="${DATAROOT}/${VERSION}/main"
CONFFILE="${CONFROOT}/${VERSION}/main/postgresql.conf"
# create socket and stats directories
install -d -m 2775 -o postgres -g postgres ${RUNROOT} ${STATDIR}
exec chpst -u postgres:postgres:ssl-cert ${BINFILE} -D ${DATAFILE} -c config_file=${CONFFILE}
EOF
mkdir log
cat << EOF > log/run
exec chpst -ulog svlogd -tt /var/svlogd/postgresql
EOF
chmod a+x run log/run
mkdir /var/svlogd/postgresql
chown log /var/svlogd/postgresql
cd /etc/service
/etc/init.d/postgresql stop
update-rc.d postgresql disable
ln -s /etc/sv/postgresql .
tail -f /var/svlogd/postgresql/current
Once you are happy that the log file is not producing lots of errors you can ^C out of it!
Geoff
]]>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
]]>"rpc.nfsd is a "fake" service implemented using lock-wedging. Doing it this way allows sv stop rpc.nfsd to work, by stopping it in the finish script."
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
]]># find /etc/sv/postfix/ -name '*' -ls
651625 4 drwxr-xr-x 5 root root 4096 Dec 3 17:41 /etc/sv/postfix/
652292 4 -rwxr-xr-x 1 root root 71 Nov 24 14:31 /etc/sv/postfix/finish
652288 4 -rwxr-xr-x 1 root root 121 Dec 3 17:41 /etc/sv/postfix/run
656409 4 drwxr-xr-x 2 root root 4096 Dec 3 17:04 /etc/sv/postfix/control
661485 4 -rwxr-xr-x 1 root root 66 Dec 3 17:04 /etc/sv/postfix/control/t
652295 4 drwxr-xr-x 3 root root 4096 Dec 1 16:41 /etc/sv/postfix/log
661408 4 -rwxr-xr-x 1 root root 58 Dec 1 16:38 /etc/sv/postfix/log/run
661426 4 drwx------ 2 root root 4096 Dec 4 13:48 /etc/sv/postfix/log/supervise
661458 0 -rw------- 1 root root 0 Dec 1 16:41 /etc/sv/postfix/log/supervise/lock
661461 4 -rw-r--r-- 1 root root 20 Dec 4 13:48 /etc/sv/postfix/log/supervise/status
661477 0 prw------- 1 root root 0 Dec 1 16:41 /etc/sv/postfix/log/supervise/ok
661728 4 -rw-r--r-- 1 root root 4 Dec 4 13:48 /etc/sv/postfix/log/supervise/stat
652424 4 -rw-r--r-- 1 root root 5 Dec 4 13:48 /etc/sv/postfix/log/supervise/pid
652426 0 prw------- 1 root root 0 Dec 1 16:41 /etc/sv/postfix/log/supervise/control
652309 4 drwx------ 2 root root 4096 Dec 4 13:48 /etc/sv/postfix/supervise
654580 0 -rw------- 1 root root 0 Nov 23 11:20 /etc/sv/postfix/supervise/lock
661489 4 -rw-r--r-- 1 root root 20 Dec 4 13:48 /etc/sv/postfix/supervise/status
661277 0 prw------- 1 root root 0 Nov 23 11:20 /etc/sv/postfix/supervise/ok
661390 4 -rw-r--r-- 1 root root 4 Dec 4 13:48 /etc/sv/postfix/supervise/stat
661388 4 -rw-r--r-- 1 root root 5 Dec 4 13:48 /etc/sv/postfix/supervise/pid
656413 0 prw------- 1 root root 0 Dec 3 17:17 /etc/sv/postfix/supervise/control
The supervise sub-directories are automatically set up by runsv.
]]>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
]]>