The officially official Devuan Forum!

You are not logged in.

#1 Re: Hardware & System Configuration » problem with rsyslog during cron jobs » 2024-03-11 15:28:44

I find that I have :-

/usr/local/sbin/invoke-rc.d

which is dated Apr 2 2020.
I am trying to remember how it got there. I recall that I had been receiving "command not found" error messages.

I have been checking in my records, and I found it when I was trying OpenRC. At that time invoke-rc lived in /usr/sbin.

Geoff

#2 Re: Installation » [SOLVED] Daedalus Xorg/X11 problem after su "anyExistingUser" » 2023-12-31 11:27:39

Or I could simply have used :-

lxsu rxvt -rv&

One difference in using su rather than sudo is that it asks for the root password rather than your own!

Geoff

#3 Re: Installation » [SOLVED] Daedalus Xorg/X11 problem after su "anyExistingUser" » 2023-12-31 11:20:41

Thank you!
I had, in fact, got ALWAYS_SET_PATH and ENV_SUPATH set up as above, but I was unable to open an X window. I then realised that it might be because I was using lxqt-sudo. On checking, I found that just using su did have $PATH set and I could open X programs. A quick check of the man page for lxqt-sudo showed that what I needed was the -s flag (for su rather than sudo).

Now when I run :-

lxqt-sudo -s rxvt -rv &

I have $PATH set and I can run X programs.
I run rxvt in reverse video so that I can easily spot that it is a root window.

Geoff

#4 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 16:10:16

My /etc/sv/postgresql.main directory currently looks like this :-

ls -alF /etc/sv/postgresql.main/

total 28
drwxr-xr-x  3 root root 4096 Dec 30 11:38 ./
drwxr-xr-x 48 root root 4096 Dec 30 13:40 ../
lrwxrwxrwx  1 root root   12 Dec 29 15:50 config -> config.multi*
-rwxr-xr-x  1 root root 1813 Dec 26 16:43 config.auto*
-rwxr-xr-x  1 root root  163 Dec 30 11:30 config.fixed*
-rwxr-xr-x  1 root root 1939 Dec 30 13:56 config.multi*
drwxr-xr-x  2 root root 4096 Dec 30 11:41 log/
-rwxr-xr-x  1 root root  290 Dec 29 15:06 run*
lrwxrwxrwx  1 root root   36 Dec 29 15:54 supervise -> /run/runit/supervise/postgresql.main/

and the log directory :-

ls -alF /etc/sv/postgresql.main/log

total 12
drwxr-xr-x 2 root root 4096 Dec 30 11:41 ./
drwxr-xr-x 3 root root 4096 Dec 30 11:38 ../
-rwxr-xr-x 1 root root  221 Dec 29 14:54 run*
lrwxrwxrwx 1 root root   40 Dec 29 15:54 supervise -> /run/runit/supervise/postgresql.main.log/

#5 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 16:04:35

The latest version of config.auto steps through the database names in the various versions looking for the first one which is set to auto start.

# Automatically find the version and database name
# taken by postgresql/run

PGBINROOT="/usr/lib/postgresql"
RUNROOT="/var/run/postgresql"
CONFROOT="/etc/postgresql"

# Typical sort of values. I think "main" is the default name for a db.
# VERSION="13"
# DB="main"
# but we will look for the actual values in use.

# We look through the versions and then for each one, look through the db names
# stopping at the first one which is set to auto start in start.conf

start=''

get_db_name() {
    local c
    DB=''
    for c in "$CONFROOT"/"$VERSION"/*; do
	[ -e "$c"/postgresql.conf ] || continue

	DB=$(basename "$c")
        echo "$c ${VERSION} ${DB}"

        # evaluate start.conf, is it to be auto started?
	if [ -e "$c/start.conf" ]; then
	    start=$(sed 's/#.*$//; /^[[:space:]]*$/d; s/^\s*//; s/\s*$//' "$c/start.conf")
	else
	    start=auto
	fi
        echo "$c yields ${VERSION} ${DB} set to $start"

	[ "$start" = "auto" ] || continue

        # we have a db configured to auto start.

        return
    done
    # we have no valid database names in this version
    echo "Version $VERSION no database found set to auto start."
    DB=''
    return
}

get_version() {
    VERSION=''

    for ver in "$PGBINROOT"/* ; do
        VERSION=${ver##*/}
        echo "Version $VERSION."

        if [ -x "$PGBINROOT"/"$VERSION"/bin/pg_ctl ]; then

            # we have a valid version, now look through the db names
            get_db_name
            if [ -n "$DB" ] && [ "$start" = "auto" ]; then
                echo "$VERSION $DB $start"
                return
            fi
      	fi

    done
    # we have no valid databases to start
    echo "No databases set for auto start."
    VERSION=''
    DB=''
    exit 162
}

# Start here...

get_version

STATDIR="${RUNROOT}/${VERSION}-${DB}.pg_stat_tmp"

#6 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 16:00:13

The config.multi script is intended to extract the database name from the service name and then find the first version which is set to auto start.

# find the version and database name
# taken by postgresql/run
# This copy is for when you specify one of several named DBs in the service name
# e.g. postgresql.mouse for the mouse database, but we find the first postgresql
# version which we can run.

PGBINROOT="/usr/lib/postgresql"
RUNROOT="/var/run/postgresql"
CONFROOT="/etc/postgresql"

# Typical sort of values. I think "main" is the default name for a db.
# VERSION="15"
# DB="main"
# but we will look for the actual values in use.

# Pick up the DB name from the directory name
# NAME="postgresql.mouse"

NAME="${PWD}"
DB="${NAME#*.}"
echo "$DB"

# We look through the versions and then for each one, check for the db name
# and checking if it is set to auto start in start.conf

start=''

get_db_name() {
	local c

	for c in "$CONFROOT"/"$VERSION"/"$DB"; do
		[ -e "$c"/postgresql.conf ] || continue
		echo "$c ${VERSION} ${DB}"

		# evaluate start.conf, is it to be auto started?
		if [ -e "$c/start.conf" ]; then
			start=$(sed 's/#.*$//; /^[[:space:]]*$/d; s/^\s*//; s/\s*$//' "$c/start.conf")
		else
			start=auto
		fi
		echo "$c ${VERSION} ${DB} is set to $start"

		[ "$start" = "auto" ] || continue

		# we have a db configured to auto start.

		return
	done

	# we have no valid database names in this version
	echo "Version $VERSION $DB not set to auto start."
	return
}

get_version() {
	VERSION=''

	for ver in "$PGBINROOT"/*; do
		VERSION=${ver##*/}
		echo "Version $VERSION."

		if [ -x "$PGBINROOT"/"$VERSION"/bin/pg_ctl ]; then

			# we have a valid version.
			# have we picked up the wanted db name?
			get_db_name
			if [ -n "$DB" ] && [ "$start" = "auto" ]; then
				echo "$VERSION $DB $start"
				return
			fi
		fi

	done
	# we have no valid databases to start
	echo "No databases set for auto start."
        sv down /etc/sv/postgresql."${DB}"

	VERSION=''
	DB=''
	exit 162
}

# Start here...

get_version

STATDIR="${RUNROOT}/${VERSION}-${DB}.pg_stat_tmp"

#7 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 15:51:48

The very simple config.fixed script, sourced by the run script is

VERSION="15"
DB="main"

PGBINROOT="/usr/lib/postgresql"
RUNROOT="/var/run/postgresql"
CONFROOT="/etc/postgresql"
STATDIR="${RUNROOT}/${VERSION}-${DB}.pg_stat_tmp"

#8 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 15:46:15

The log/run script is intended to work with any service without needing to be edited.

#!/bin/sh

NAME="${PWD%/log}"
NAME="${NAME##*/}"

LOG="/var/log/runit/$NAME"

USER="_runit-log"
GROUP="adm"
MODE="755"

install -m "$MODE" -o "$USER" -g "$GROUP" -d "$LOG"
exec chpst -u "$USER":"$GROUP" svlogd -tt "$LOG"

#9 Re: Installation » Postgresql under runit and OS upgrade » 2023-12-30 15:38:57

I have been thinking about how it might work with several Postgresql databases. I believe that each database would have its own service instance controlled by runit. This could be similar to having getty, where there are services called, e.g. getty-tty1, getty-tty2 etc.
I now have services called postgresql.a and postgresql.main. The contents of their directories are the same, apart for deleting the supervise links, so that they can be correctly recreated by update-service. The main run script still takes the config file, but config is now a link to one of several versions, config.fixed, config.auto and config.multi.

config.fixed simply sets the variables $VERSION and $DB along with the paths.
config.auto looks for the first $DB set for auto start, stepping through the ${VERSION}s.
config.multi gets the $DB from the service name extension and looks for the first $VERSION set for auto start.

I have also got the log/run script so that it picks up the service name and should not require changing.

In /etc/sv I have the service postgresql. It is necessary to copy over postgresql to postgresql.main and it should work! It is necessary to delete the supervise links and to change the config link over to config.multi.

cd /etc/sv
cp -a postgresql postgresql.main
cd postgresql.main
rm supervise
rm config
ln -s config.multi config
cd log
rm supervise

now remove the automatic set up and start the selective version :-

update-service --remove /etc/sv/postgresql
Service postgresql removed, the service daemon received the TERM and CONT signals.
sv status postgresql
fail: postgresql: unable to change to service directory: file does not exist
update-service --add /etc/sv/postgresql.main
Service postgresql.main added.
sv status postgresql.main
run: postgresql.main: (pid 4614) 4s; run: log: (pid 4613) 4s
cd /var/log/runit/postgresql.main
cat current 

2023-12-29_15:54:42.13174 ok: run: dbus: (pid 2032) 7772s
2023-12-29_15:54:42.13183 main
2023-12-29_15:54:42.13193 Version 13.
2023-12-29_15:54:42.13194 /etc/postgresql/13/main 13 main
2023-12-29_15:54:42.13282 /etc/postgresql/13/main 13 main is set to manual
2023-12-29_15:54:42.13282 Version 13 main not set to auto start.
2023-12-29_15:54:42.13282 Version 15.
2023-12-29_15:54:42.13284 /etc/postgresql/15/main 15 main
2023-12-29_15:54:42.13363 /etc/postgresql/15/main 15 main is set to auto
2023-12-29_15:54:42.13364 15 main auto
2023-12-29_15:54:42.26292 2023-12-29 15:54:42 GMT [4614-1] LOG:  starting PostgreSQL 15.5 (Debian 15.5-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2023-12-29_15:54:42.26294 2023-12-29 15:54:42 GMT [4614-2] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-12-29_15:54:42.28991 2023-12-29 15:54:42 GMT [4614-3] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-12-29_15:54:42.35872 2023-12-29 15:54:42 GMT [4624-1] LOG:  database system was shut down at 2023-12-29 15:54:11 GMT
2023-12-29_15:54:42.38238 2023-12-29 15:54:42 GMT [4614-4] LOG:  database system is ready to accept connections

For test purposes, I have the few files necessary to fool the scripts so that it will check the database "a" and find that it is set to be started manually, i.e. not run by runit. I have then set up postgresql.a in the same way as above. When the service postgresql.a was started it failed to find a database to start and looped about once a second. I have fixed this by adding the command

sv down /etc/sv/postgresql.a

which stops the looping, when no suitable database is found.

I will list the scripts in separate posts.

#10 Re: Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-18 13:36:54

As I looked through the man page for rxvt-unicode, I found out that in rxvt you can do the paste part with <shift><insert>. This is probably easier than trying to click on the mouse wheel without scrolling at the same time.
I tried copy and paste from Claws to emacs, using <shift><insert>, but this did not use the text I had just selected, but some text from another buffer.

Geoff

#11 Re: Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-18 10:53:42

Thank you for the confirm-paste info. I had a quick look at rxvt-unicode using Synaptic and it does indeed list the file

/usr/lib/x86_64-linux-gnu/urxvt/perl/confirm-paste

amongst the installed files and this is confirmed with ls. I wonder whether this is new, as I have not noticed this effect before.

Thank you

Geoff

#12 Re: Desktop and Multimedia » Claws-mail themes after upgrade to Daedalus » 2023-12-16 11:26:23

I have just received an email, to which I replied. When the compose window popped-up, the To: line was already filled in. However, the To: line was the expected height, i.e. suitable for a single line. Now, when I click on the compose email icon, the new compose window now has the suitable height To: line.

I do not know what has tidied up this "feature". I am, however, happy that Claws is working nicely.

Geoff

#13 Re: Installation » Upgrading to Daedalus running runit-init » 2023-12-15 16:29:10

Thank you for that.

I also had to sort out the ownership of the files themselves, current and lock, but it is now running happily.

Someone here had worked out a run file that needed very little customisation between services, so my log/run file now looks like :-

#!/bin/sh

NAME=ssh
LOG="/var/log/runit/$NAME"
USER="_runit-log"
GROUP="adm"

chown "$USER:$GROUP" "$LOG"
chmod 750 "$LOG"

exec chpst -u "$USER" svlogd -tt "$LOG"

Maybe that should be 'chown -R "$USER:$GROUP" "$LOG"' to sort out the log files themselves, as well as the directory?

Geoff

#14 Re: Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-15 15:52:55

On reading the man page for rxvt, I noticed the other sequence for copy and paste was to select the area with the left button and then copy it with <alt><ctl>c and paste it with <alt><ctl>v. While this is necessary in rxvt, some programs are resistant to <ctl>c and thus I can use <ctl>c to copy from Claws and then paste it into rxvt with <alt><ctl>v.

The message which I have recently started to get in rxvt is :-

Pasting 1 control characters, continue? (y/n)

highlighted in yellow. This appears when there is a new line lincluded in the copied text.

Geoff

#15 Re: Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-15 15:41:50

Sorry, that should read button 1 and button 3 being pressed, when I press left & right simultaneously.

#16 Re: Desktop and Multimedia » Claws-mail themes after upgrade to Daedalus » 2023-12-15 15:39:22

It seems that the light blue background is part of the Clearlooks-Phenix-Sapphire theme and does show up in other programs.

I think that the toolbar icons jumping sideways, is because the highlighted icons were a different width from the normal versions, so as you mouse over them, so the icons to the right move sideways. Since playing with the Claws themes and returning to the default, this phenomenon has gone away!

The remaining "feature" is in the compose message window, where there used to be several lines to enter recipients, but owing to each line being about 3 lines worth of height, there is only room for one and a bit lines at a time. This area is scrollable, so can be worked around, but is an annoying waste of space. Do you see this with your copy?

I am interested in your comment about the silver theme in LXQt preferences. I am seeing a choice between Debian and System. I have chosen the System theme as the lighter option.

Geoff

#17 Re: Desktop and Multimedia » Claws-mail themes after upgrade to Daedalus » 2023-12-14 16:16:58

Thank you for the update on the theming!

I am running LXQt with Openbox and have set the overall theme to be Clearlooks-Phenix-Sapphire.

Geoff

#18 Re: Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-14 15:45:40

PedroReina wrote:

My first step would be checking with xev if the mouse if firing correct events.

Copy and paste is currently working and xev reports :-

left = button 1
click on wheel = button 2
right = button 3
scroll up = button 4
scroll down = button 5
click wheel left = button 8
click wheel right = button 9

I do have a similar mouse plugged into my laptop and will try swapping them over when this one stops working, after testing with xev.

Camaf wrote:

Alternative to middle wheel pasting is both left & right buttons together....

That rings a bell, but is not currently working for me. xev reports button 1 and button 2 being pressed.

Thank you for your ideas

Geoff

#19 Desktop and Multimedia » Copy and Paste the traditional way » 2023-12-14 10:38:42

Geoff 42
Replies: 9

Ever since I first started using X on Unix, I have used the left mouse button to select an area of text and the middle button to paste it in. These days I have to click down on the scroll wheel for the paste, but I do have to be a bit careful not to scroll at the same time!

This has worked fine for decades. Recently, however, it stops working. This does not seem to be a complete break. I had wondered whether it might be that the battery in my mouse (Logitek M325) might be flat and I have replaced it, but the copy and paste does seem to stop working. I have now updated to Daedalus and copy/paste does work most of the time, but does seem to stop sometimes.

When this is not working, I can use the edit facility in those programs that provide it, to copy and paste, but this does not help with e.g. my rxvt terminal windows.

I have recently noticed a new feature, that when I try and paste into rxvt some text which includes a new line, a little message appears at the bottom of the window asking if I mean to paste in control characters. I don't think that this co-incided with the upgrade.

Does anyone have any ideas of what might be going on here?

Geoff

#20 Desktop and Multimedia » Claws-mail themes after upgrade to Daedalus » 2023-12-14 10:18:29

Geoff 42
Replies: 6

After updating from Chimaera to Daedalus, there seems to have been some changes to the theme in Claws-mail.
I don't know whether this is from a change in the Devuan theme or in Claws itself, now on v 4.1.1.
At first, after the upgrade, I noticed that the toolbar icons were jumping sideways as I moused over them.
I have since installed the claws-mail-themes and have looked at some them, but Claws crashes when I go back to the default theme!
It does restart ok, with the default theme, but I see that the toolbar icons are not now jumping sideways!

The odder feature is that when I open a compose message window, the area near the top, where it shows the headers, has the line(s) for entering To: (or Cc: etc) which are now very deep. There is probably room to have it 3 lines deep. As you add more recipients, these lines are all also very deep. This looks very odd and also takes up a lot of vertical screen space for no benefit. If you type a very long line in the To: field, it just scrolls across and leaves the blank space above and below.

The background to the message area is now a light blue colour. I wonder whether this is a Devuan theme feature. This is not really a problem, it is just that it is new/different! This does also affect the toolbar area and menus.

The OS upgrade also seems to remove the Claws plug-ins, but it is easy enough to reload them.

Claws itself continues to work nicely.

#21 Installation » Postgresql under runit and OS upgrade » 2023-12-13 14:53:12

Geoff 42
Replies: 6

It is possible to have several databases running under Postgresql.
There is, however, the simple case of having just one database, often called "main", which is what I have been using.

It does get a bit more interesting during an upgrade where you will have 2 versions of Postgresql installed, albeit briefly.
I have set it up to run under runit, whereby it looks though the file system to find the first version and then looks for the first database which is available to be run and then runs it. I have used some code from the SysV script.

/etc/sv/postgresql/run looks like :-

#!/usr/bin/env /lib/runit/invoke-run
exec 2>&1

sv start dbus || exit 1

. ./config

# create socket and stats directories
install -d -m 2775 -o postgres -g postgres ${RUNROOT} ${STATDIR}
exec chpst -u postgres:postgres:ssl-cert pg_ctlcluster --foreground ${VERSION} ${DB} start

while config looks like this :-

# find the version and database name
# taken by postgresql/run

PGBINROOT="/usr/lib/postgresql"
RUNROOT="/var/run/postgresql"
DATAROOT="/var/lib/postgresql"
CONFROOT="/etc/postgresql"

# Typical sort of values. I think "main" is the default name for a db.
# VERSION="15"
# DB="main"
# but we will look for the actual values in use.

# We look through the versions and then for each one, look through the db names
# stopping at the first one which is set to auto start in start.conf

start=''

get_db_name() {
    local c

    DB=''
    for c in $CONFROOT/$VERSION/*; do
	[ -e $c/postgresql.conf ] || continue
        
	DB=$(basename "$c")
        echo "$c ${VERSION} ${DB}"

        # evaluate start.conf, is it to be auto started?
	if [ -e "$c/start.conf" ]; then
	    start=$(sed 's/#.*$//; /^[[:space:]]*$/d; s/^\s*//; s/\s*$//' "$c/start.conf")
	else
	    start=auto
	fi
        echo "$c yields ${VERSION} ${DB} $start"

	[ "$start" = "auto" ] || continue

        # we have a db configured to auto start.
        
        return
    done
    # we have no valid database names in this version
    echo "Version $VERSION no database found set to auto start."
    DB=''
    return
}

get_version() {
    VERSION=''

    for VERSION in `ls $PGBINROOT 2>/dev/null`; do

        echo "\nVersion $VERSION."
        if [ -x $PGBINROOT/$VERSION/bin/pg_ctl ]; then

            # we have a valid version, now look through the db names
            get_db_name
            if [ -n $DB ] && [ "$start" = "auto" ]; then
                echo "$VERSION $DB $start"
                return
            fi
      	fi

    done
    # we have no valid databases to start
    echo "No databases set for auto start."
    VERSION=''
    DB=''
    exit 162
}

# Start here...

get_version

BINFILE="${PGBINROOT}/${VERSION}/bin/postgres"
STATDIR="${RUNROOT}/${VERSION}-${DB}.pg_stat_tmp"
DATAFILE="${DATAROOT}/${VERSION}/${DB}"
CONFFILE="${CONFROOT}/${VERSION}/${DB}/postgresql.conf"

After the upgrade from Chimaera to Daedalus it is possible to see what is there with :-

pg_lsclusters

This shows both versions 13 and 15 although 15 has not been started.
Close down the new version and upgrade the old one. I think that the "--stop" is probably redundant, but it doesn't seem to cause a problem.

pg_dropcluster 15 main --stop
pg_upgradecluster 13 main

This does the upgrade so we can now drop the old one.

pg_dropcluster 13 main

This leaves 15 running, but not under runit.

pg_ctlcluster 15 main stop -m smart

stops that copy and then runit notices and fires up the supervised version.

/var/log/runit/postgresql/current reports :-

2023-12-13_06:45:59.29154
2023-12-13_06:45:59.29841 Version 13.
2023-12-13_06:45:59.29843 Version 13 no database found set to auto start.
2023-12-13_06:45:59.29843
2023-12-13_06:45:59.29844 Version 15.
2023-12-13_06:45:59.29844 /etc/postgresql/15/main 15 main
2023-12-13_06:45:59.29844 /etc/postgresql/15/main yields 15 main auto
2023-12-13_06:45:59.29844 15 main auto
2023-12-13_06:46:00.55850 ok: run: dbus: (pid 2052) 1s
2023-12-13_06:46:00.79584 2023-12-13 06:46:00 GMT [2024-1] LOG:  starting PostgreSQL 15.5 (Debian 15.5-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2023-12-13_06:46:00.79586 2023-12-13 06:46:00 GMT [2024-2] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-12-13_06:46:00.82271 2023-12-13 06:46:00 GMT [2024-3] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-12-13_06:46:00.90202 2023-12-13 06:46:00 GMT [2418-1] LOG:  database system was shut down at 2023-12-12 19:02:00 GMT
2023-12-13_06:46:00.96074 2023-12-13 06:46:00 GMT [2024-4] LOG:  database system is ready to accept connections
2023-12-13_06:51:02.19918 2023-12-13 06:51:02 GMT [2416-1] LOG:  checkpoint starting: time
2023-12-13_06:51:02.80703 2023-12-13 06:51:02 GMT [2416-2] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.046 s, sync=0.021 s, total=0.608 s; sync files=2, longest=0.015 s, average=0.011 s; distance=0 kB, estimate=0 kB

I need to remember to remove postgresql 13, when I am happy with everything.

ps axjf reports for postgresql :-

PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
...
1853  1961  1961  1961 ?           -1 Ss       0   0:00  \_ runsv postgresql
1961  2003  1961  1961 ?           -1 S      999   0:00  |   \_ svlogd -tt /var/log/runit/postgresql
1961  2004  1961  1961 ?           -1 S      130   0:00  |   \_ /usr/lib/postgresql/15/bin/postgres -c config_file=/etc/postgresql/15/main/postgresql.conf
2004  2350  2350  2350 ?           -1 Ss     130   0:00  |       \_ postgres: checkpointer
2004  2351  2351  2351 ?           -1 Ss     130   0:00  |       \_ postgres: background writer
2004  2368  2368  2368 ?           -1 Ss     130   0:00  |       \_ postgres: walwriter
2004  2369  2369  2369 ?           -1 Ss     130   0:00  |       \_ postgres: autovacuum launcher
2004  2370  2370  2370 ?           -1 Ss     130   0:00  |       \_ postgres: logical replication launcher

...

Geoff

#22 Installation » Upgrading to Daedalus running runit-init » 2023-12-13 11:13:41

Geoff 42
Replies: 3

My Chimaera system has been running for a long time and has used runit and runit-init.
I was going to upgrade to Daedalus while having runit and not reverting to SysV init.
I simply followed the standard instructions.

https://www.devuan.org/os/documentation … o-daedalus

apt update
apt upgrade
apt full-upgrade
apt autoremove

edit /etc/apt/sources.list - adding non-free-firmware as well as changing chimaera to daedalus

deb http://deb.devuan.org/merged daedalus main non-free-firmware non-free contrib
deb http://deb.devuan.org/merged daedalus-updates main non-free-firmware non-free contrib
deb http://deb.devuan.org/merged daedalus-security main non-free-firmware non-free contrib
# deb http://deb.devuan.org/merged daedalus-backports main non-free-firmware non-free contrib
apt update

Now kill xscreensaver. The suggested "killall xscreensaver" did not work so I resorted to ps to get the pid and then :-

kill -TERM 24860 # in this case!
apt upgrade
apt full-upgrade

It asks about stopping and restarting some processes. Of these vsftpd failed to restart. This was due to an historic misconfiguration!

I think that it took about 1.5 to 2 hours to finish. Then the tidy up.

apt autoremove --purge
apt autoclean

df -h / reported :-

20G 15G 4.2G 78%

before the upgrade and now

20G 17G 2.7G 86%

This seems to imply that Daedalus is taking up 1.5G more than Chimaera.
This will of course depend on what you have installed! I have Flightsimulator which does take up a bit of disk space!

I rebooted and it worked.
A had to do bit of fiddling with my dual monitors, but that is not really to do with Daedalus or runit.

runsvdir command line errors
===================

When I ran "ps axjf" I noticed that the command line of runsvdir was not the expected line of dots, but was carrying some error messages.

ps axjf|grep runsvdir reports :-

runsvdir -P /etc/service log: tional log directories. svlogd: warning: unable to lock directory: /var/log/runit/ssh: access denied svlogd: fatal: no functional log directories. svlogd: warning: unable to lock directory: /var/log/runit/ssh: access denied svlogd: fatal: no functional log directories. svlogd: warning: unable to lock directory: /var/log/runit/acpid: access denied svlogd: fatal: no functional log directories.

in /var/log/runit current and lock were both owned by "_runit-log adm" in the subdirectories acpid/ and ssh/
This was probably some historic set up error, but :-

cd /var/log/runit
chown runit-log:runit-log acpid/current 
chown runit-log:runit-log acpid/lock 
chown runit-log:runit-log ssh/current 
chown runit-log:runit-log ssh/lock 

soon had that fixed and after the next reboot the runsvdir command line contains the expected, clean line of dots.

NTP
===

ntp has been replaced by ntpsec.

After the upgrade my set up started ntpsec and then runit tried to start ntp and failed, but looped when it noticed that an ntp service was already running (and was logging it...)

I needed to sort out ntpsec and disable init.d/ntp. I stopped ntp until I had it sorted.

I edited /etc/sv/ntp/run to contain :-

#!/bin/sh -eu
exec 2>&1

sv start dbus || exit 1

DAEMON=/usr/sbin/ntpd
NTPD_USER="ntpsec:ntpsec"
NTPD_OPTS="-n -N -g -u $NTPD_USER"
NTPD_OPTS="-c /etc/ntpsec/ntp.conf $NTPD_OPTS"

exec $DAEMON $NTPD_OPTS

This now runs happily...

sv up ntp
sv status ntp
run: ntp: (pid 15388) 1101s; run: log: (pid 1935) 6879s

To stop the init.d versions getting started (my runit service is called "ntp" so I disabled both ntp and ntpsec) :-

update-rc.d ntp disable
update-rc.d ntpsec disable

The ntp service is now running smoothly under runit.

I will report success with postgresql separately.

Geoff

#23 Re: Hardware & System Configuration » Default dhcp client floods my syslog » 2023-09-18 14:59:13

Thank you for looking into this, Lorenzo.

My Chimaera installation is happy without runit starting a copy of dhclient, and having removed it from Daedalus, that also seems happy. So I would think that having it disabled-by-default is probably the correct thing to do.

I am not an expert in networking so I a not sure when we would need to run a copy of dhclient from the init system.

Geoff

#24 Re: Hardware & System Configuration » Default dhcp client floods my syslog » 2023-09-17 14:58:20

I have spotted two copies of dhclient running after upgrading to daedalus.

I am using runit and, clearly, one copy was being started by runit but the other was less easy to track down. I came to the conclusion that one copy was started by the networking software, presumably related to /etc/network/interfaces .

The version started from runit has now been removed

update-service --remove /etc/sv/dhclient

and the VM (under Xen) where I am testing it, still boots ok with just the one copy of dhclient.

Interestingly, the runit copy was earlier complaining even more about not being able to find eth1. I then spotted that the new runit setup for dhclient had a config file in conf/interfaces which contained

INTERFACES=eth1

Changing this to eth0 soon solved that. But this is no longer in use!

Geoff

#25 Re: Installation » Daedalus upgrade with runit-init » 2023-09-01 15:11:56

One thing that I have been trying is to set up a symlink from /etc/init.d to /usr/bin/sv. This should mean that anything that uses a SysV init syntax should still work.

I have tried this on Postfix. As an extra backup I saved the old init.d scripts to /usr/local/etc/init.d

then :-

root@fluorine:/etc/init.d# mv postfix .postfix
root@fluorine:/etc/init.d# ln -s /usr/bin/sv postfix

root@fluorine:/etc/init.d# ls -alF .postfix postfix
-rwxr-xr-x 1 root root 3368 Mar 16  2020 .postfix*
lrwxrwxrwx 1 root root   11 Sep  1 15:49 postfix -> /usr/bin/sv*

root@fluorine:/etc/init.d# cd

root@fluorine:~# /etc/init.d/.postfix status
postfix is running.
root@fluorine:~# /etc/init.d/postfix status
run: postfix: (pid 1881) 6694s; run: log: (pid 1880) 6694s
root@fluorine:~# sv status postfix
run: postfix: (pid 1881) 6707s; run: log: (pid 1880) 6707s
root@fluorine:~# service postfix status
run: postfix: (pid 1881) 6718s; run: log: (pid 1880) 6718s

So, this shows that calling up the old SysV init script does still work if you know where it is and with the old behaviour
Then if you use what looks like the postfix script in init.d, you get the same result as if you use sv or service.

Geoff

Board footer

Forum Software