Artix is a really great distribution imo. There's no installer though, you set it up just like Gentoo with console tools and you have to know what you're doing – at least a bit.

No. If you want to install Artix linux you can use calamares installer. Graphical installation images come with a slightly preconfigured desktop system (LXQt, LXDE, MATE, Cinnamon, KDE/Plasma, XFCE) and a rudimentary set of applications: a file manager, media player (mpv), network manager, document viewer, web browser and the calamares installer. People afraid of the Linux terminal or in need of a quick, intuitive installation would want this ISO.

However, I do of course appreciate Devuan a lot for still supporting 32 bit machines, the Raspberry Pi 1 and so on. And by now, I'm about to migrate a server from Gentoo to Devuan (that's why I found this Radicale issue).

At the moment, I'm using Devuan, Artix and Gentoo – on different machines with different purposes. And I'm really happy that there are still reasonable people out there who don't use that Systemd spawn of the devil!

Btw I really like the way Artix handles this (the other non-systemd and non-Gentoo distro I am using as of recently): There, you have a package without any init scripts, and multiple packages including them, specifically for the init system in use. In case of Radciale, this would be the "radicale" package, and if you want the OpenRC init script, the "radicale-openrc" package.

I had to read that twice to let the elegance of it soak in.  *That* is the proper approach to supporting interchangeable init systems.  It feels like ... common sense.  I'm happy with my Devuan desktop, but may have to give Artix a spin for fun -- sounds like they have a few beautiful minds on the team.  Thank you for mentioning this.

Btw I really like the way Artix handles this (the other non-systemd and non-Gentoo distro I am using as of recently): There, you have a package without any init scripts, and multiple packages including them, specifically for the init system in use. In case of Radciale, this would be the "radicale" package, and if you want the OpenRC init script, the "radicale-openrc" package.

Apparently, this doesn't fit the way Devuan does it, but fixing such a bug like the one here would be no problem, and would not depend on others … however, I hope the Debian guys will fix this.

Won't Devuan provide a fixed package if it's broken on Devuan and Debian doesn't fix it? The bug report dates back to August …

EDIT: Oh, I just saw we were cross-posting

Snap!

The package originates with Debian so a fix will be dependent on them. The only caveat is that Debian policy allows the maintainer to ignore non-systemd support requests. Hopefully they will want to fix it for all init systems. Updating the bug report with the working version of the patch would probably help.

Thanks for this info, I could get it to work with this hint. But the patch doesn't make it work respectively is not applicable.

There are more fixes to do. The /etc/default/radicale file contains a non-existant command line option that has to be removed:

--- /etc/default/radicale.orig	2022-11-16 18:47:47.350441509 +0100
+++ /etc/default/radicale	2022-11-16 18:48:07.849614303 +0100
@@ -5,7 +5,7 @@
 
 # Options for radicale on startup
 # Note that most options can be specified in /etc/radicale/config
-RADICALE_OPTS="--daemon"
+RADICALE_OPTS=""
 
 # Make initscript verbose, override system default
 # (Note: This is ONLY about the initscript!)

Also, the Devuan init script misses a --background option when starting the daemon. But also when having fixed this, stopping and/or restarting the daemon is broken and also has to be fixed.

The patch that makes it work would be:

--- /etc/init.d/radicale.orig	2022-11-16 19:06:50.714274017 +0100
+++ /etc/init.d/radicale	2022-11-16 19:33:49.998867023 +0100
@@ -68,10 +68,10 @@
 	fi
 
 	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --test > /dev/null \
+		--exec $DAEMON --test > /dev/null \
 		|| return 1
-	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
+	start-stop-daemon --start --quiet --startas $DAEMON --background \
+		--exec $DAEMON --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
 		$RADICALE_OPTS \
 		|| return 2
 }
@@ -86,7 +86,7 @@
 	#   1 if daemon was already stopped
 	#   2 if daemon could not be stopped
 	#   other if a failure occurred
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --name $NAME
+	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --user $DAEMON_UID
 }
 
 case "$1" in

What are the chances this will be officially fixed (soonish) in Devuan's repositories? Can I do anything to help?

https://bugs.debian.org/cgi-bin/bugrepo … ug=1017433

^ The bug report includes a patch for the init script :-)

EDIT: to clarify: you can use the supplied /etc/init.d/radicale script (once patched). There is no need to use an OpenRC script.

EDIT2: no, it's a bit more complicated than that...

Here's a patch that actually makes the init script start the daemon:

--- radicale.orig	2022-11-16 17:11:10.392000000 +0000
+++ radicale.new	2022-11-16 17:18:52.184000000 +0000
@@ -33,9 +33,6 @@
 # Define LSB log_* functions.
 . /lib/lsb/init-functions
 
-# Declare default options
-RADICALE_OPTS="--daemon"
-
 # Read configuration variable file if it is present
 [ -r /etc/default/$NAME ] && . /etc/default/$NAME
 
@@ -68,11 +65,11 @@
 	fi
 
 	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --test > /dev/null \
+		--exec $DAEMON --test > /dev/null \
 		|| return 1
 	start-stop-daemon --start --quiet --startas $DAEMON \
-		--name $NAME --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
-		$RADICALE_OPTS \
+		--exec $DAEMON --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID \
+		--background \
 		|| return 2
 }

But for some reason the LSB block isn't working — update-rc.d doesn't enable the service and if I enable it manually with sysv-rc-conf it doesn't start.

What does work is adding this line to /etc/rc.local:

/etc/init.d/radicale start

But that's so stupid it makes me want to poke my eyes out.

It would probably be best to add my extra information and anything else you can glean about the problem to the bug report to which I linked earlier. I have no idea why it won't work

EDIT3: s/gleam/glean/. How embarrassing...

/etc/init.d/radicale start

I didn't change anything … I just took the /etc/radicale directory from my Gentoo machine. I didn't touch /etc/default/radicale or anything else.

EDIT:

I just removed (and purged) Radicale and started over again from scratch. Here's what happens when I try to start it:

# /etc/init.d/radicale start
Starting Radicale CalDAV server : radicale.
# ps -ef | grep radicale
root     23055 22552  0 08:38 pts/0    00:00:00 grep radicale

As said: Nothing happens. The Radicale process is not started …

This is what happens when using the adapted Gentoo init script, with the Gentoo etc:

# /etc/init.d/radicale start
 * Caching service dependencies ...
Error: radicale is the name of a real and virtual service.                                    [ ok ]
 * Starting radicale ...                                                                      [ ok ]
# ps -ef | grep radicale
root     23298     1 94 08:42 ?        00:00:06 /usr/bin/python3 /usr/bin/radicale
root     23307 22552  0 08:42 pts/0    00:00:00 grep radicale

And after restarting it, the error is gone:

# /etc/init.d/radicale restart
 * Stopping radicale ...                                                                      [ ok ]
 * Starting radicale ...                                                                      [ ok ]

And after doing so, the original init script interestingly reports an error:

# /etc/init.d/radicale_default start
Starting Radicale CalDAV server : radicaleusage: radicale [OPTIONS]
radicale: error: unrecognized arguments: --daemon
 failed!

I couldn't start Radicale using the shipped init script /etc/init.d/radicale. Nothing happened. No error, no syslog entry, nothing.

How did you attempt to start Radicale, exactly? The sysvinit script should work.

I'm about to migrate a server from Gentoo to Devuan. As a Gentoo user, I of course want to use OpenRC :-)

However, I couldn't start Radicale using the shipped init script /etc/init.d/radicale. Nothing happened. No error, no syslog entry, nothing.

I thus tried to use Gentoo's init script:

#!/sbin/openrc-run
# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

PIDFILE=/run/radicale.pid

depend() {
        need localmount
}

start() {
        ebegin "Starting radicale"
                start-stop-daemon --start --quiet --background \
                --user radicale \
                --umask 0027 \
                --stderr-logger /usr/bin/logger \
                --pidfile ${PIDFILE} --make-pidfile \
                --exec /usr/bin/radicale
        eend $?
}

stop() {
        ebegin "Stopping radicale"
                start-stop-daemon --stop --quiet \
                --pidfile ${PIDFILE}
        eend $?
}

Which also didn't work out of the box – but after having removed the "depend" function and the "--stderr-log" argument, I actually did start Radicale. On the first start, I got "Error: radicale is the name of a real and virtual service.", but it did start. After restarting it, that error was also gone.

I tried to reproduce what the original init script did before writing this, but interestingly, I now get an error using it:

Starting Radicale CalDAV server : radicaleusage: radicale [OPTIONS]
radicale: error: unrecognized arguments: --daemon
 failed!

I'm pretty sure this wasn't there before I tried to use the Gentoo init script …

All this is a bit strange. Is this the "handwork" that would be necessary when using OpenRC, as the installer told me? I never used anything else than OpenRC, so I am not used to sysvinit init scripts …

Thanks for all info!