Container fails to complete startup

[DavidRa]

I have a relatively new deployment of Jellyfin 10.10.6 server which is failing to start.

It's a docker deployment, using the official Jellyfin container, running on a VM that is part of a 3 master, 3 worker swarm. For reference, the stack compose XML is attached as jf-compose.txt:


When the stack is started, there's nothing in the way of errors - see attached jf-log.txt. I have anonymised the URL - it does still resolve to the swarm, and to traefik which would provide access.

If I look at jellyfin.db it appears to be a reasonable size:

Code:

root@swarm-w03:/mnt/glustervol0/jellyfin/config/data# ls -lah
total 1.2G
drwxr-xr-x 4 1200 1200 4.0K Feb 19 22:00 .
drwxr-xr-x 8 1200 1200 4.0K Feb  5 10:54 ..
-rw-r--r-- 1 1200 1200   35 Feb  4 18:17 device.txt
-rw-r--r-- 1 1200 1200 168K Feb 18 00:56 jellyfin.db
-rw-r--r-- 1 1200 1200  32K Feb 19 19:37 jellyfin.db-shm
-rw-r--r-- 1 1200 1200    0 Feb 19 19:37 jellyfin.db-wal
-rw-r--r-- 1 1200 1200 1.1G Feb 18 01:10 library.db
-rw-r--r-- 1 1200 1200  32K Feb 19 19:38 library.db-shm
-rw-r--r-- 1 1200 1200 128M Feb 18 01:11 library.db-wal
drwxr-xr-x 2 1200 1200 4.0K Feb  4 18:17 playlists
drwxr-xr-x 2 1200 1200 4.0K Feb 10 14:52 ScheduledTasks
-rw-r--r-- 1 1200 1200 3.9M Feb 18 00:43 splashscreen.png

I've also tried repairing it with sqlite3 ".recover" while the stack is stopped, but that fails catastrophically - I expect this is user error on my part:

Code:

root@swarm-w03:/mnt/glustervol0/jellyfin/config/data# sqlite3 jellyfin.db ".recover" | sqlite3 jellyfin-recovered.db
sql error: SQL logic error (1)
root@swarm-w03:/mnt/glustervol0/jellyfin/config/data#

It's so new I don't have a valid backup in place yet - what's my best recovery path here? I'd rather not have it scan the media volumes for 3 days again if I can avoid it. Happy to share other config files if those will help.

[TheDreadPirate]

How long are you waiting before killing the container? What I THINK is happening is the "Clean up playlists and collections" job is taking a very long time to run. Depending on how much content you have and how your storage is attached, this can take upwards of 20-30 minutes.

Try waiting a while. If it does eventually start, you can disable this "Clean up playlists" job. Dashboard > Scheduled Tasks > Clean up playlists and collections. Delete the start up trigger.

[DavidRa]

Thanks for that. I wasn't actually killing the container deliberately - it was being restarted by Docker (or portainer, or ... or ... well, something).

However, you've given me enough to get a win. I've added the following to the compose file:

Code:

    healthcheck:
      test: ["CMD", "curl", "-fs", "-S", "--max-time", "2", "http://localhost:8096"]
      interval: 60s
      timeout: 10s
      retries: 5
      start_period: 1800s

This was enough to give the container 30m to restart, and additionally provides a reasonable health status for the container. I'll have to try a few things once I'm in front of it again, but at least it's running. Will probably see if I can propose some changes to the container deployment documentation, once I work out any remaining kinks. I think it would be helpful to have a larger example compose file with these settings, for example.