You are not logged in.
Lorenzo!
thank you for your detailed response to my comments.
Before I get onto the details, might I ask about the salsa.debian.org URL,
as it opens, but does not display the actual content for me. Does it need me to create an account?
The situation with /etc/sv versus /etc/service is interesting and may depend on your
point of view. I am currently working through services and converting them from SysV to Runit.
Therefore, I would like the SysV service to keep running until I have the Runit version correctly
set up, in which case the use of /etc/service seems to work better for me. But I accept your
point about disabling a service, once everything is set up.
just use 'servicename-wip' and keep it disabled by default untill your service is ready for use.
I'm sorry, but I don't understand the bit about 'servicename-wip'. (Ah! does 'wip' stand for 'work in progress', so that it doesn't match the real name?)
As for a dependency, I see that the Man page for sv says that sv start is the same as sv up but that it waits for the command to take effect, calling the check script if present. This would seem to mean that sv start dbus is the same as sv up dbus && sv check dbus. I assume that the || exit 1 will cause Runit to recognise that the dependency has not started and retry later (1s ?).
I have used the run line :-
exec dbus-daemon --system --nofork --nopidfile
and have a check file :-
#!/bin/sh
exec dbus-send --system / org.freedesktop.DBus.Peer.Ping > /dev/null 2> /dev/null
I may have copied these from Void Linux.
Thank you for all of your work on Runit.
Geoff
With the services which are running under runsvdir, I have tried indicating when they need another service to have been started. Thus I have :-
avahi-daemon, cups, ddclient, elogind
depending on dbus.
As mentioned earlier there seem to be 2 different versions of this
sv start dbus
or
sv check dbus >/dev/null || exit 1
I have seen messages in the logs where dbus fails to start correctly the first time, only to start correctly 1s later, thus :-
2022-03-11_18:11:17.33232 warning: dbus: unable to open supervise/ok: file does not exist
2022-03-11_18:11:17.34982 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:17.34983 Successfully dropped root privileges.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 starting up.
2022-03-11_18:11:17.34983 dbus_bus_get_private(): Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
2022-03-11_18:11:17.34983 WARNING: Failed to contact D-Bus daemon.
2022-03-11_18:11:17.34983 avahi-daemon 0.8 exiting.
2022-03-11_18:11:18.33051 ok: run: dbus: (pid 2007) 1s
2022-03-11_18:11:18.33159 Found user 'avahi' (UID 104) and group 'avahi' (GID 111).
2022-03-11_18:11:18.33163 Successfully dropped root privileges.
2022-03-11_18:11:18.33173 avahi-daemon 0.8 starting up.
2022-03-11_18:11:18.33227 Successfully called chroot().
This type of message is intermittent and was produced with
sv start dbus
I will try it with
sv check dbus >/dev/null || exit 1
and see if that works better. I assume that this might suppress the warning message if it is redirected to /dev/null, but I will need to look out for the daemon failing and then trying again 1s later and succeeding.
Replacing /etc/sv with /etc/service in /lib/runit/run_sysv_scripts did seem to have the expected result that disabling a service in Runit caused it to be started via /etc/rc2.d on a reboot.
If this service then failed to start correctly because of a sequencing problem, then adding e.g. :-
sv start dbus
to the file in rc2.d also failed, probably because runsvdir had not been started yet,
causing the sv command itself to fail.
It was possible to get avahi-daemon to start correctly under Runit by adding the line :-
sv start dbus
to its run file and the sequencing then worked as expected.
I have now edited run_sysv_scripts to to use /etc/service instead of /etc/sv and it has not broken anything yet, but I will need to check what happens when I disable services under Runit, etc.
Thank you for your helpful observations.
I more or less copied the elogind run file from Void Linux. It starts :-
# elogind doesn't work right if it starts before dbus
sv check dbus >/dev/null || exit 1
which I assume will leave the elogind startup looping until dbus is running, while
sv start dbus
will hang until dbus is running. The latter sounds better. I suppose that that line could be included in an init.d script, although would that work if runsvdir has not been started yet?
Geoff
The Debian port of Runit has introduced some backwards compatibility, so that it can start services from /etc/init.d if they are not yet set up for Runit. To do this it uses the script /lib/runit/run_sysv_scripts.
This will look through the directory it has been passed (typically /etc/rcS.d and /etc/rc2.d) and it will run the scripts starting with "S" but only run them if they do not exist in /etc/sv. It uses rcS.d for stage 1 and rc2.d for stage 2. This seems reasonable, but there are problems.
I would have thought that all of the services in rcS.d would need to be started as the baseline for the system to be running and that they are probably not started by runsv.
As for stage 2, it starts the scripts in rc2.d if they are not in /etc/sv. It then starts runsvdir, which starts the services set up to run under Runit. There are two problems here. I suspect the /etc/sv is not the correct directory to check against, as the services here have not necessarily been enabled and indeed, people like me may not have finished setting up a service! I suspect that it may be better to check against /etc/service rather than /etc/sv, as those are the ones which have been enabled.
The other problem is that the sequencing may be wrong. So that if you have dbus set up to be run by runit and avahi has not yet been done, then avahi will fail as it will be started by run_sysv_scripts before runsv starts dbus. I am not sure what the answer might be for this.
Runit is designed to work with daemons that stay in the foreground, so that the daemon may be supervised easily. Many daemons do try and run in the background but there is often an option that can be given to tell it to run in the foreground. Thus ntpd can use the -n (--nofork) option to run in the foreground.
Occasionally, there is a daemon which only runs in the background. I have found noip2 which updates my dynamic IP address. I have not found a way to tell it to run in the foreground. There are one or two things which you can do to handle this.
Runit comes with a program to change the process status (chpst).
This has a number of things it can do, such as changing the user or group it runs as.
The options which are useful here are -l & -L which can open a lock file for writing and obtain an exclusive lock on it, creating the file if necessary. -l will wait for the file to become available, while -L will fail immediately if it is not available.
The file /etc/sv/noip2/run looks like this :-
#!/bin/sh -eu
exec 2>&1echo "executing /etc/sv/noip2/run"
chpst -L supervise/runlock /usr/local/bin/noip2 || exit 1
exec chpst -l supervise/runlock true
The echo message is logged if logging has been set up.
The daemon noip2 is run by chpst with an exclusive lock on the file /etc/sv/noip2/supervise/runlock
The second instance of chpst is ready to run the command true and waits for the lock file to become available, i.e. when noip2 stops running. When the lock file becomes available the command true will be run, which returns immediately and runit becomes aware that noip2 is no longer running and can take the appropriate actions.
But what happens if we want to stop the daemon? If
sv down noip2
is run then runit will stop the waiting chpst process, but not noip2.
After it has stopped chpst it will then look for the file finish and run it if it exists.
As we know the name of the lock file, we can find the PID of the process which has it open, using lsof, which may need installing.
apt install lsof
We can find the processes which have the lock file open :-
lsof /run/runit/supervise/noip2/runlock
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chpst 2006 root 3w REG 0,23 0 1738 /run/runit/supervise/noip2/runlock
noip2 2051 nobody 3w REG 0,23 0 1738 /run/runit/supervise/noip2/runlock
We could find the PID of the daemon by looking through the output for the process run by nobody
and then printing the second field :-
PID=`lsof /run/runit/supervise/noip2/runlock | grep nobody | awk '{ print $2 }' -`
although awk can do the search as well :-
PID=`lsof /run/runit/supervise/noip2/runlock | awk '/nobody/ { print $2 }' -`
However, a study of the lsof man page shows that there are lots of options available and the -t option just prints out the PIDs
lsof -t /run/runit/supervise/noip2/runlock
2006
2051
Also, there is the -c option which can select the process of a particular command or filter out processes of certain commands with the negation ^. In this case we don't want the chpst process.
lsof -t -c ^chpst /run/runit/supervise/noip2/runlock
2051
which can be incorporated into the file /etc/sv/noip2/finish :-
#!/bin/sh
exec 2&>1# use lsof to find the process with a lock on our file.
PID=`lsof -t -c ^chpst /run/runit/supervise/noip2/runlock`
echo "executing /etc/sv/noip2/finish. PID = $PID"
[ -z $PID ] && exit 1
# We could do something like "kill -TERM $PID", but in this case "noip2 -K $PID" works.
/usr/local/bin/noip2 -K $PID
This seems to work nicely. With run and finish set up the daemon can be started, supervised and stopped.
If your main interest is in having a running system, then go with the default, SysVinit, in the case of Devuan.
If you are interested in playing with the init system, or you are running a service which must be kept going, then Runit and OpenRC are interesting and can supervise the services.
OpenRC is probably easier for setting up new services, with its declarative style of script.
Runit seems to get rave reviews from people who understand the internals, but it does require setting up a directory structure for each service.
It depends a bit on how they are installed, as both Runit and OpenRC can be installed to be started from SysVinit, which takes its initial instructions from /etc/inittab. Runit can add an entry at the end on inittab :-
#-- runit begin
SV:123456:respawn:/etc/runit/2
#-- runit end
While OpenRC replaces /etc/init.d/rcS and /etc/init.d/rc, which are called from inittab.
Both Runit and OpenRC can replace the SysV init, in which case inittab is not referenced.
This has the effect that the gettys would not be started and they must be set up using the features of your new init system. If you install them from scratch, then this may have already been taken care of.
The Runit init does seem to work well.
I did have problems with the OpenRC init, resulting in the system not being shutdown cleanly, so that the file systems needed checking at boot time. When it boots from SysV init, it has an extra run state to pass through and this work nicely and the system shuts cleanly.
I have tried patching the OpenRC init to add this extra run state, but I failed to pursuade the Debian maintainers on this point.
https://dev1galaxy.org/viewtopic.php?id=2788
with details of the patching here :-
https://dev1galaxy.org/viewtopic.php?pid=21180#p21180
Geoff
I have an odd artifact involving the cursor redrawing very slowly
when it changes between cursors, say from the "I" cursor to the
"drag and stretch" cursor. It can take several seconds to complete
the redraw and seems to redraw by random scan lines. This also
similarly affects a certain type of pop-up.
My graphics card is an integrated Intel i915.
This artefact only occurs when I boot using the Xen hypervisor.
Booting on bare metal is ok, but booting with Xen produces this
slow redraw. I am currently on Devuan Chimaera, kernel 5.10.0-10-amd64
and Xen 4.14.4-pre although my failing memory tells me that I
had this effect earlier!
Devuan is booting in paravirtual mode (PV), as the controlling host
(Dom0). When I boot a guest system (DomU), the frame buffer of DomU
uses qemu, which runs in Dom0 and I can connect a vncviewer on
Dom0 to the qemu vncserver to access the X session on the DomU.
In this case the VNC display does not have this artefact.
If, however, I open an ssh connection to DomU and run a vncserver on DomU and
connect to it from Dom0 with a vncviewer, then the artefact
still occurs but to a lesser amount.
I wonder if anyone has encountered the slow redrawing of the
cursor and pop-ups. It would be really wonderful if anyone knows
how this ties in with Xen and even better if you know how to fix it!
Geoff
Reading the ps man page I discovered the command :-
ps -eo pid,user,start,args
which prints the start time for each process. I spotted that the 30s delay came between some power management daemons and the first user applications (Claws and Pale Moon). I went into :-
Preferences>LXQt settings>LXQt Configuration Centre
and selected the Session Settings.
In Basic settings I turned off Power Management and in
Autostart I turned off Power Manager.
On a reboot there was no delay.
I then turned these power management things back on and at a reboot there was still no delay.
I notice that I am running /usr/bin/xfce4-power-manager, which I don't remember being there before, as well as /usr/libexec/upowerd and /usr/bin/lxqt-powermanagement. I could not guaranty that the xfce one was not there before!
I will leave it as it is and see if the delay really has gone.
Following my upgrade to Chimaera, I noticed that sound was not working, in my browser, Pale Moon.
I also noticed that Pulseaudio had become installed. Once I had removed Pulseaaudio I could get sound from VLC, but not from Pale Moon. What was required was a reboot, and then it was working.
Geoff
I don't know that command! Anyway it reports :-
loginctl session-status
1 - user1 (1026)
Since: Thu 2021-10-21 08:59:18 BST; 2min 0s ago
Leader: 3182 (lxdm-session)
Seat: seat0; vc7
TTY: tty7
Service: lxdm; type x11; class user
State: active
I don't know if that is ok, but it looks sensible to me. (I have edited out my real username)
Geoff
Thank you!
I have tried combinations of rngd and havged and neither.
I have also tried your suggestion with urandom :-
ls -alF /dev/*rand*
lrwxrwxrwx 1 root root 7 Oct 20 19:59 /dev/random -> urandom
crw-rw-rw- 1 root root 1, 9 Oct 20 19:59 /dev/urandom
None of which have any effect on my 30s delay. I may be experiencing a different problem from the OP as I should highlight that I am not using Slim but lxdm.
There is a thread on the mailing list :-
https://lists.dyne.org/lurker/message/2 … eb.en.html
where there is a report of a 30 second delay. This is thought to be related to the random number generator and that installing haveged can get rid of the delay.
Geoff
I am also seeing a delay. However, I am running lxdm and XLQt.
The desktop seems to load ok, including lxqt-panel, but then it hangs for about 30 seconds.
If I look in ~/.xsession-errors, then I can see a gap in the time amongst the messages.
(redshift-gtk:5080): Gdk-CRITICAL **: 09:12:05.617: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
several other messages, including :-
Starting idlenesswatcher
"PowerButton" "" ""
"SuspendButton" "" ""
"HibenateButton" "" ""
[Notice] Started
[Notice] X11 error: type: 0, serial: 319, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 321, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 323, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 325, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Warning] Cannot grab shortcut 'Alt+F2'
[Notice] X11 error: type: 0, serial: 683, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 685, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 687, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Notice] X11 error: type: 0, serial: 689, error_code: 10 'BadAccess (attempt to access private resource denied)', request_code: 33 (GrabKey), minor_code: 0, resourceid: 312
[Warning] Cannot grab shortcut 'Control+Alt+D'
and when I start Claws
(claws-mail:5166): GLib-GObject-CRITICAL **: 09:12:48.912: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
The part about idlenesswatcher caught my eye, but I have not yet been able to pin it down. The Cannot grab shortcut 'Control+Alt+D' was displaying before the upgrade, but did seem to come after a bit of a delay. I have not yet found where it is configured to set that as a shortcut.
Geoff
Following my upgrade to Chimaera, I noticed that, after a reboot, I was still running and old kernel (4.19.0-12-amd64).
This was easily fixed by installing linux-image-amd64, which (currently) pulls in 5.10.0-9-amd64.
I wonder whether the absence of linux-image-amd64 may be related to the uncertain heritage of my OS,
which has at least passed through Debian Jessie, Devuan Jessie, ASCII & Beowulf.
Geoff
Following my upgrade to Chimaera, there were 5 packages remaining that did not upgrade, relating to Python 2.7-minimal
These were left having used :-
apt upgrade --without-new-pkgs
apt full-upgrade
I had a look using aptitude, which wanted to remove several packages.
I then had a look with Synaptic and marked all upgrades and then apply-ed.
This removes python-minimal and then upgrades python2.7-minimal and python3-six.
Python 2.7 is now autoremovable! I suppose that this could be because maybe I am not using 2.7.
Geoff
Having upgraded my desktop from Beowulf to Chimaera, I checked that LibreOffice still worked and the things I tried were all ok.
However, I did notice that the font size in the menu bar was very small, as well as other parts of the UI.
The fix seems to be to install libreoffice-gtk3.
As I run LXQt, I had tried installing libreoffice-qt5, but that did not fix the font size, so I removed it.
Geoff
Following the upgrade of my desktop, from Beowulf to Chimaera, ddclient would not start, but reported :-
Unknown option: daemon 300 -syslog -pid /var/run/ddclient.pid
followed by the very long usage message.
After some fiddling around I finally (?) fixed this by moving the options from the command line to the config file :-
The following was added to /etc/ddclient.conf :-
daemon=300
pid=/var/run/ddclient.pid
syslog=yes
and then edited /etc/init.d/ddclient to set OPTIONS to be empty :-
OPTIONS=""
This then seems to work!
/etc/init.d/ddclient start
/etc/init.d/ddclient status
Status of Dynamic DNS service update utility: ddclient is running.
Geoff
Having upgraded my desktop from Beowulf to Chimaera, printing via CUPS stopped working.
My printer is an HP DeskJet 3630.
I found some info suggesting that the modern way is to go driverless and install IPP-USB.
I tried installing this, but printing did not resume.
I removed IPP-USB and installed hplip and I could print again. Also xsane could talk to the 3630 and do some scanning.
I am happy that printing is working, but should I worry about trying to get IPP-USB up and running?
Geoff
I use Claws and have the Dillo HTML viewer plugin in Beowulf. If you have Chimaera, then you can also install the LiteHTML viewer plugin, which probably displays the message more as the sender intended. I usually display messages as plain text, but sometimes use the Dillo plugin to check what was in the HTML version of the message.
I also installed Evolution and Thunderbird when I was checking for the one I liked the best and still have them available.
Geoff
I had some fun with sound some time ago. The problem was with 2 outputs sharing the module snd-hda-intel. It found HDMI first, which became the default.
The solution I found was to disable HDMI with
# Disable the HDMI card which shows up first, but enable PCH
options snd-hda-intel enable=0,1
in /etc/modprobe.d/alsa-base.conf
http://forums.debian.net/viewtopic.php?t=110572#p525601
Geoff
I have not got round to looking at S6 yet, but don't you just need to insert
supervisor=s6
into the OpenRC service script for a particular service.
https://github.com/OpenRC/openrc/blob/m … 6-guide.md
Geoff
To make /tmp a tmpfs you edit /etc/defaults/tmpfs and remove the '#' from
RAMTMP=yes
which defaults to "no"
I have just had a thought! I usually have the Xen hypervisor running, so I thought that I should try booting the backports kernel on the bare metal. This seems to remove the problem. I will continue to look to see if I can find what causes the problem.
Thank you for your help.