OK. I give up on getting fossil to work using the following on my MX Linux installation, which is a SysVinit system:

update-rc.d fossil defaults

with this init script:

#!/bin/sh
exec 1>/var/log/fossil.log 2>&1

### BEGIN INIT INFO
# Provides:          fossil
# Required-Start: $local_fs $network $remote_fs $named $time
# Required-Stop: $local_fs $network $remote_fs $named
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Fossil Service
# Description:       Controls the fossil service
### END INIT INFO

case "$1" in
start)
    exec /usr/bin/fossil server --errorlog fossil-scm.log --port 8080 --repolist /zfs/fossils &
    ;;
stop)
    killall -9 fossil 2> /dev/null
    ;;
esac

exit 0

It just isn't reliable and with seriously limited logging output from fossil, I can't figure out what's going on - I don't know why it's not staying up...

So, what's the recommended approach to install fossil on a system like MX Linux where the init system is decidedly not systemd?

On Mint, it worked, but I have a feeling that wasn't it staying up, but rather it being respawned by systemd, dunno exactly, don't care, just an observation. On FreeBSD, as I've mentioned before, it never goes down, there I was running it via xinit, if I remember correctly.

I use following shell script(not service) on Void linux (no systemd) to start fossil server. I do start it manually but it keeps running till the restart of system (easily several weeks).

#!/bin/bash
cd /home/myuser/repos/
/usr/bin/fossil server -P 8089 --localauth --extroot /home/myuser/repos/myext --user myuser --repolist --files \* /home/myuser/repos/. &

So, what's the recommended approach to install fossil on a system like MX Linux where the init system is decidedly not systemd?

Off hand, I'd say what you tried to do: Use the relevant infrastructure to start the service.

If your observation on other systems is that "the fossil service is consistently available", then in my view it's because either 1) the service never had to be started again or 2) the relevant infrastructure successfully determined that the service had to be restart and did so.

For your MX linux setup, you encounter a situation where the need to restart is present (but does not appear to happen, possibly because the infrastructure in place does not offer monitoring or do not know how to for this service).

So to understand why MX linux is not stable for you, you'd either need to teach the infrastructure to restart the service as needed - or figure out what causes the service to stop.

As for the cause, I'd still suggest monitoring if the fossil process is running in order to differentiate between events such as:

1. Fossil stops after successfully handling a request, service is not running for a while and you start it. That is, the last handled request is successful (you don't notice any problems and assumes all is well), yet fossil stops.
2. Fossil handles a request successfully, service continues running for a while, the service stops, a period of time lapses and you start it. That is, something appears to kill the fossil process.
3. The service is running but fossil stops and fails to handle a request and you immediately restart it. That is, fossil crashes on some event, you detect an error condition and immediately restart the service.

Another thing to try: In tmux, screen or a terminal you know won't be disconnected, run "fossil ARGS ; date". If fossil crashes or is killed, the date command could let you know just when that occurred.

That's helpful. I didn't think of putting it up in a tmux session with date - nice. I'll combine y'all's suggestions and see if I can get some more insight.

Fair enough, Warren. It's good to know your experience. I'm ok with seeing how long it'll stay up in the foreground process running in a tmux session. If I can see when it dies/if it dies, then I can decide what to do. Up to now, it's been mysterious and unpredictable and I haven't been able to track it down, but I feel optimistic about this approach to troubleshooting.

Problem probably solved. I'm including the "solution" for posterity and in case I forget :).

sudo -s
apt install inetutils-inetd

vi /etc/services
#http-alt   8080/tcp    webcache    # WWW caching service
fossil 8080/tcp #fossil server

vi /etc/inetd.conf 
fossil stream tcp nowait.10000 root /usr/bin/fossil server --errorlog fossil-scm.log http --repolist /zfs/fossils

update-rc.d inetutils-inetd default

# start
/etc/init.d/inetutils-inetd start

# test via browsing to <HOST>:8080
reboot

# test again via browsing to <HOST>:8080

Now, I know why it never went down on FreeBSD, duh, it was only up long enough to service the request (thanks for the suggestion, Warren). This'll work.

Yes, socket activation is one of several methods for setting up a Fossil server, and yes, it has the same virtue as CGI: each HTTP hit gets served by a different PID.

Thanks for the link :). I found several different links, but not that one. I love fossil and have been using it now for several years for all of my repos, it's great. Now that I don't think it'll be crashing (or whatever it was doing) anymore, I'm a happy camper. Please don't think I'm griping about anything, just trying to get it to settle down!