Comment on PSA: If the first Smart Search in Immich takes a while

[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 ⁨6⁩ ⁨days⁩ ago

  But why?

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

  source

  • corsicanguppy@lemmy.ca ⁨6⁩ ⁨days⁩ 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”).

    source
• PieMePlenty@lemmy.world ⁨5⁩ ⁨days⁩ ago

  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.

  source

  • avidamoeba@lemmy.ca ⁨5⁩ ⁨days⁩ ago

    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.

    source

    • PieMePlenty@lemmy.world ⁨5⁩ ⁨days⁩ ago

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

      source
• MangoPenguin@lemmy.blahaj.zone ⁨5⁩ ⁨days⁩ ago

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

  source

  • avidamoeba@lemmy.ca ⁨5⁩ ⁨days⁩ 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.

    source

    • MangoPenguin@lemmy.blahaj.zone ⁨5⁩ ⁨days⁩ ago

      Interesting, waiting on network mounts could be useful!

      I deploy everything through Komodo so it’s handling the initial start of the stack, updates, logs, etc…

      source