Fossil Forum

MX Linux Service
Login

MX Linux Service

MX Linux Service

(1.1) By decuser on 2024-01-04 22:18:49 edited from 1.0 [link] [source]

I have installed MX Linux 23-1 "Libretto" as my distro of choice. I am having some difficulties getting things working there. I would like to create a service (it's openrc, I think, definitely not systemd). I don't want to run it as a container. So, I created a script /etc/init.d/fossil containing:

#!/bin/sh

### 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 /var/log/fossil.log --port 8080 --repolist /zfs/fossils &
    ;;
stop)
    killall -9 fossil 2> /dev/null
    ;;
esac

exit 0

I would like it to run as a server, log to /var/log/fossil.log, which I touched as root, be on 8080, serve up the repos off zfs, and restart if it needs to.

I enabled the service:

update-rc.d fossil defaults

and fired it up:

service fossil start

It appears to run fine and I can commit to it and such. However, over time, it isn't running anymore. I had hoped it wouldn't have any issues (on FreeBSD uptime is in months, but on linux...), but whatever. I looked in the log and nothing was there, so I don't know if my incantation is wrong, the system's got issues, or what.

Help :).

(2) By Preben Guldberg (preben) on 2024-01-04 23:04:12 in reply to 1.1 [link] [source]

However, over time, it isn't running anymore

Over how long have you been testing?

And any idea on how often it stops running?

I had hoped it wouldn't have any issues (on FreeBSD uptime is in months, but on linux...),

Are you suggesting that there is an uptime correlation?

And if so, any chance that the service is not started after a reboot?

That should be straight forward to test.

I looked in the log and nothing was there

As in "the file is empty" or "none of the messages helped me"?

(3) By decuser on 2024-01-04 23:37:11 in reply to 2 [link] [source]

Over how long have you been testing?

weeks.

And any idea on how often it stops running?

Not really.

Are you suggesting that there is an uptime correlation?

Not exactly, just that it never stops working on FreeBSD for the years I've run it there. Whereas every time I try it on linux (6-8 different times over the last 3-4 years), it doesn't. On Mint, it doesn't appear to be this way (systemd and I think there's a respawn option, which may mask it).

And if so, any chance that the service is not started after a reboot?

It starts after a reboot

As in "the file is empty" or "none of the messages helped me"?

The file is empty.

(4) By decuser on 2024-01-04 23:38:35 in reply to 3 [source]

Even though I'm uncertain as to how often it goes down, it does seem to happen a lot if I haven't committed in a day or so, I generally have to restart the service.

(8) By Preben Guldberg (preben) on 2024-01-05 08:27:07 in reply to 4 [link] [source]

Makes me wonder if the fossil process is long gone, or if something triggers it to stop on that first connection after a day or so.

I'd be inclined to keep a script running that logs if fossil is running or not every minute or so.

(5) By John Rouillard (rouilj) on 2024-01-05 00:19:33 in reply to 1.1 [link] [source]

log to /var/log/fossil.log, which I touched as root,

Hmm, that implies you are running fossil as root.

Running as root is not a good idea. IIRC it will chroot to the current working directory when fossil is executed. I wonder if your log file is outside of the chrooted directory?

Looking at the code in src/main.c, I see:

** If running as root, chroot to the directory containing the
** repository zRepo and then drop root privileges.  Return the
** new repository name.

I wonder what happens if fossil logs after the chroot? Does /var/log/fossil.log exist in the chrooted directory?

(6) By decuser on 2024-01-05 02:22:27 in reply to 5 [link] [source]

I wonder what happens if fossil logs after the chroot? Does /var/log/fossil.log exist in the chrooted directory?

That makes sense. I changed it to fossil-scm.log without the /var/log prefix and restarted. I then touched the file and restarted fossil. It didn't write anything until I tried a commit, then it wrote a couple of log entries about Can't open this, Bad file descriptor that:

------------- 2024-01-05 02:16:03 UTC ------------
warning: SQLITE_CANTOPEN(14): cannot open file at line 43198 of [05941c2a04]
HTTP_HOST=odin:8080
HTTP_USER_AGENT=Fossil/2.21 (2023-02-26 19:24:24 [3c53b6364e])
REMOTE_ADDR=127.0.0.1
REQUEST_METHOD=POST
REQUEST_URI=/notes
SCRIPT_NAME=/notes
------------- 2024-01-05 02:16:03 UTC ------------
warning: SQLITE_CANTOPEN(14): os_unix.c:43198: (9) open(/notes.fossil) - Bad file descriptor
HTTP_HOST=odin:8080
HTTP_USER_AGENT=Fossil/2.21 (2023-02-26 19:24:24 [3c53b6364e])
REMOTE_ADDR=127.0.0.1
REQUEST_METHOD=POST
REQUEST_URI=/notes
SCRIPT_NAME=/notes

The commit worked, though... weird. Wonder what that's about?

So, is it possible to get it logging information about the service as well as the http requests? Startup, shutdown, that sorta thing?

(7) By decuser on 2024-01-05 02:56:24 in reply to 6 [link] [source]

Oh, I remember the sqlite issues - something to do with backoffice, disabling this in settings, stops the warnings. Doesn't materially effect anything.