Selfhosted

49240 readers

666 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:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

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

Questions? DM the mods!

founded 2 years ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

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

38 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

[–] MangoPenguin@lemmy.blahaj.zone 1 points 4 hours ago* (last edited 4 hours 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 2 hours ago (1 children)

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.

[–] MangoPenguin@lemmy.blahaj.zone 2 points 1 hour 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..