Immich working, but fails to re-start after being stopped or server reboot

What app is this about, and its version: Immich 2.6.3~ynh1
What YunoHost version are you running: Yunohost 12.1.39 stable
What type of hardware are you using: Old laptop or computer

Describe your issue

Immich failing to start because of dependency problems.

The odd thing about this is that Immich was running fine and I’d had no indication of problems. I stopped the immich service from the Yunohost web admin to run a fsarchiver backup of the /home/yunohost.app/immich directory as I’ve done many times before. The backup ran fine (about 1.1TB of compressed data).

After it was done, I re-started the Immich services from the web admin, and it looked like it started normally. A while later, I tried to get into Immich via the browser, and it showed an http error 502.

I checked the Yunohost web admin services status and saw that the service wasn’t running. I tried to re-start it and it wouldn’t start. In the snippet of the log I saw, it looked like there was a dependency problem. Something about npm and sharp.
I took the actions that it suggested in the log, but it didn’t make any difference. The service still wouldn’t start.

At this point I decided to remove Immich via the web interface, leaving the data, and then re-install it, and finally, restore the latest automatic database backup from the night before. That worked, and then Immich seemed to be back to normal.

It ran fine until I needed to reboot the server (for unrelated reasons). The Yunohost server came back up normally, except Immich didn’t start again. It reported exactly the same dependency issue that it did before I removed and restored it. So I went ahead and captured the logs in it’s broken state (that’s the log attached here), removed Immich again, and re-installed it, restored the database as before, and it’s back up and running normally again.

The problem is, I’m pretty sure if I stop or reboot the server again (as I will have to at some point), it will likely fail again, and I’m afraid that one of these times I may not be able to so easily get it going again.

Thanks for any suggestions.

Share relevant logs or error messages

Here’s The log output from when Immich wouldn’t start.

1 Like

that line is not normal: ERR_DLOPEN_FAILED: libcgif.so.0: cannot open shared object file: No such file or directory
could you post the output of:

  • sudo apt-cache policy libcgif0
  • sudo apt-cache rdepends --no-{suggests,conflicts,breaks,replaces,enhances} --installed --recurse libcgif0

Thanks for the reply.

Here’s the output of sudo apt-cache policy libcgif0:

libcgif0:
  Installed: 0.3.0-1
  Candidate: 0.3.0-1
  Version table:
 *** 0.3.0-1 500
        500 http://ftp.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

and here’s the output of sudo apt-cache rdepends --no-{suggests,conflicts,breaks,replaces,enhances} --installed --recurse libcgif0:

libcgif0
Reverse Depends:

(Not much there on the second one).

It might be worth noting, these are the responses while Immich is running normally. It’s possible that they might change if I stop, and then attempt to restart Immich (basically, intentionally temporarily breaking it). If it would help, I could do that. If you think it won’t matter, I won’t, since it’s working right now.

This may or may not be relevant.. if I do a sudo apt update, then sudo apt upgrade, I get:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  jellyfin-ffmpeg7 libcgif0 libexif12
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

that’s relevant because those package are some dependencies of the immich meta package.
what’s the output of: sudo dpkg-query --show --showformat='${Depends}' immich-ynh-deps

It is:

libpq5, libpq-dev, postgresql-17, postgresql-17-pgvector, postgresql-client-17, postgresql-17-vchord

Same issue for me

ok find the root cause, should be fixed with upcoming 2.6.3~ynh2