this post was submitted on 08 Jul 2025
92 points (96.9% liked)

Selfhosted

49240 readers
616 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
92
PSA: If the first Smart Search in Immich takes a while (lemmy.ca)
submitted 1 day ago* (last edited 1 day ago) by avidamoeba@lemmy.ca to c/selfhosted@lemmy.world
37 comments fedilink hide all child comments
 

Your ML model cache volume is getting blown up during restart and the model is being re-downloaded during the first search post-restart. Either set it to a path somewhere on your storage, or ensure you're not blowing up the dynamic volume upon restart.

In my case I changed this:

  immich-machine-learning:
    ...
    volumes:
      - model-cache:/cache

To that:

  immich-machine-learning:
    ...
    volumes:
      - ./cache:/cache

I no longer have to wait uncomfortably long when I'm trying to show off Smart Search to a friend, or just need a meme pronto.

That'll be all.

you are viewing a single comment's thread
view the rest of the comments
[–] avidamoeba@lemmy.ca 2 points 19 hours ago (3 children)

Because I clean everything up that's not explicitly on disk on restart:

[Unit]
Description=Immich in Docker
After=docker.service 
Requires=docker.service

[Service]
TimeoutStartSec=0

WorkingDirectory=/opt/immich-docker

ExecStartPre=-/usr/bin/docker compose kill --remove-orphans
ExecStartPre=-/usr/bin/docker compose down --remove-orphans
ExecStartPre=-/usr/bin/docker compose rm -f -s -v
ExecStartPre=-/usr/bin/docker compose pull
ExecStart=/usr/bin/docker compose up

Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target
[–] waitmarks@lemmy.world 9 points 19 hours ago (1 children)

But why?

why not just down up normally and have a cleanup job on a schedule to get rid of any orphans?

[–] corsicanguppy@lemmy.ca 4 points 18 hours ago

But why?

I a world where we can't really be sure what's in an upgrade, a super-clean start that burns any ephemeral data is about the best way to ensure a consistent start.

And consistency gives reliability, as much as we can get without validation (validation is "compare to what's correct", but consistency is "try to repeat whatever it was").

[–] PieMePlenty@lemmy.world 6 points 13 hours ago (1 children)

Wow, you pull new images every time you boot up? Coming from a mindset of having rock solid stability, this scares me. You're living your life on the edge my friend. I wish I could do that.

[–] avidamoeba@lemmy.ca 3 points 13 hours ago* (last edited 13 hours ago) (1 children)

I use a fixed tag. 😂 It's more a simple way to update. Change the tag in SaltStack, apply config, service is restarted, new tag is pulled. If the tag doesn't change, the pull is a noop.

[–] PieMePlenty@lemmy.world 2 points 12 hours ago

Ahh, calmed me down. Never thought of doing anything like you're doing it here, but I do like it.

[–] MangoPenguin@lemmy.blahaj.zone 1 points 1 hour ago* (last edited 1 hour ago) (1 children)

That's wild! What advantage do you get from it, or is it just because you can for fun?

Also I've never seen a service created for each docker stack like that before..

[–] avidamoeba@lemmy.ca 1 points 6 minutes ago

Well, you gotta start it somehow. You could rely on compose'es built-in service management which will restart containers upon system reboot if they were started with -d, and have the right restart policy. But you still have to start those at least once. How'd you do that? Unless you plan to start it manually, you have to use some service startup mechanism. That leads us to systemd unit. I have to write a systemd unit to do docker compose up -d. But then I'm splitting the service lifecycle management to two systems. If I want to stop it, I no longer can do that via systemd. I have to go find where the compose file is and issue docker compose down. Not great. Instead I'd write a stop line in my systemd unit so I can start/stop from a single place. But wait 🫷 that's kinda what I'm doing isn't it? Except if I start it with docker compose up without -d, I don't need a separate stop line and systemd can directly monitor the process. As a result I get logs in journald too, and I can use systemd's restart policies. Having the service managed by systemd also means I can use aystemd dependencies such as fs mounts, network availability, you name it. It's way more powerful than compose's restart policy. Finally, I like to clean up any data I haven't explicitly intended to persist across service restarts so that I don't end up in a situation where I'm debugging an issue that manifests itself because of some persisted piece of data I'm completely unaware of.