The officially official Devuan Forum!

You are not logged in.

#51 Re: Other Issues » Runit and backwards compatibility » 2022-03-14 10:49:44

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

#52 Re: Other Issues » Runit and backwards compatibility » 2022-03-13 16:33:15

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.

#53 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 20:18:51

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.

#54 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 11:23:24

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.

#55 Re: Other Issues » Runit and backwards compatibility » 2022-03-10 10:33:35

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

#56 Other Issues » Runit and backwards compatibility » 2022-03-09 16:46:41

Geoff 42
Replies: 9

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.

#57 Other Issues » Runit and background daemons » 2022-02-22 16:35:21

Geoff 42
Replies: 0

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>&1

echo "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.

#58 Re: Installation » The best init system » 2022-02-13 11:47:25

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

#59 Desktop and Multimedia » Cursor redraws very slowly » 2022-01-19 11:23:07

Geoff 42
Replies: 0

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

#60 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-21 14:48:38

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.

#61 Hardware & System Configuration » Chimaera upgrade - no sound » 2021-10-21 09:55:31

Geoff 42
Replies: 0

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

#62 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-21 08:05:36

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

#63 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-20 19:13:25

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.

#64 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-20 18:08:55

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

#65 Re: Other Issues » Login hangs after upgrade to chimaera? Slim might be the cause! » 2021-10-20 08:40:59

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

#66 Hardware & System Configuration » Chimaera upgrade - old kernel » 2021-10-19 09:13:42

Geoff 42
Replies: 0

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

#67 Hardware & System Configuration » Chimeara upgrade - Python 2.7 » 2021-10-19 09:07:26

Geoff 42
Replies: 0

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

#68 Hardware & System Configuration » Chimeara upgrade - LibreOffice - menu font size » 2021-10-19 08:53:49

Geoff 42
Replies: 0

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

#69 Hardware & System Configuration » Chimaera upgrade - ddclient » 2021-10-18 14:54:00

Geoff 42
Replies: 3

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

#70 Hardware & System Configuration » Chimaera upgrade - Printing » 2021-10-18 14:45:00

Geoff 42
Replies: 1

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

#71 Re: Other Issues » recommend a good email prgram » 2021-09-09 10:20:29

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

#72 Re: Desktop and Multimedia » Chromium + ALSA + jitzsi: mic problem after update » 2021-06-08 14:56:51

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

#73 Re: Installation » How to activate S6 init together with OpenRC? » 2021-05-20 13:55:48

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

#74 Re: Installation » Partitioning schemes separate var and usr and boot 4 unfussy root? » 2021-04-14 14:54:24

To make /tmp a tmpfs you edit /etc/defaults/tmpfs and remove the '#' from

RAMTMP=yes

which defaults to "no"

#75 Re: Desktop and Multimedia » [SOLVED] Cursor oddity under backported kernel » 2021-04-11 14:30:59

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.

Board footer

Forum Software