Microservices crash on reverse geocoding
Upgraded to the latest version. Migrated storage successfully. Started generating all thumbnails. Jobs are currently stuck - GENERATE THUMBNAILS 7/25,280; TAG OBJECTS 3/37,498; ENCODE CLIP 2/17,957.
Looking at "htop" no immich processes seem to do anything, CPU usage is close to idle.
How do I resume the process?
24 Replies
According to "docker ps" immich_microservices container seems to got into restart loop.
Logs:
We are aware of this issue and in the progress of working on a fix. At the moment, you can work around this by destroy the immich_microservices container and recreate it
Thanks
The workaround seems to be working, I see numbers being updated. Thanks again
Thank you for reporting back!
Well, it worked for 15 min before getting into the same state again. Logs show different record now.
hmm interesting
Can you post your
.env
file?
This time it lasted 7 min, so I guess I will have to wait until the fix
This is the error before it gotten into the restart loop.
There are also quite a few errors like that
I got it to be more stable by also recreating the Immich-Server and Immich-Microservices somehow. Maybe its luck but both of those containers does share the same image. Might as well recreate both then IMO.
Ah, so this is the reason my microservices are crashing
This is my error message:
After disabling reverse geocoding in env I get
I'm trying to find where we call that code. Could it be an issue with the csv data we download?
OK, issue confirmed and fixed. Deleting the microservices volume will clear the geoname cache and make it work again
If you don't want to delete the volume, just delete the .reverse-geocoding-dump folder in the microservices container
cool... thinking of volumizing that onto one server's folder and delete that folder.... (yes, i'm that reckless lol!)
Reminds me of this PR, which was to make it an anon volume:
https://github.com/immich-app/immich/pull/1234/files
One step further is to just map it to a physical folder and then delete the contents when needed.
There's no issue with doing that, it's simply a cache folder and the app will work as expected when the file is deleted. The issue, in fact, comes from the fact that is does a fresh/new download every day. If the download gets interrupted and the file becomes incomplete/corrupted it will start causing the microservices container to crash. I think because it is downloading daily for all immich users the chance of somebody having the issue is pretty high.
It's an old library and the code is hard to modify/improve, so it's kind of just how it is, although I think there's a pull request upstream that's supposed to try to detect a corrupted download and self-heal. We'll see 😄
i wish I can code - but I would say low hanging fruit is to not download daily. can I set it as readonly folder after - once content gets populated once?
volumes:
- ${UPLOAD_LOCATION}:/usr/src/app/upload
- /mnt/immich/micro:/usr/src/app/.reverse-geocoding-dump:ro
let see how it goes after this lol
redeploy after that folder has all it needs and stable
then made it RO
I'd guess it errors out, but not 100% sure how it would respond to that..
It's another library that i'm this close 🤏 to just rewriting 🙂
yep.. lets see tonight it if works
manual band aids for now
even if it restarts the container without that hard break reboot loop. I'll be happy
It looks for a file based on the date in the name of it.
oh.. ouch. so much for that maybe...
Basically 2023_03_30.csv or whatever
It's terrible
basically I got like 500GB of photos that I have yet to upload... so been watching it like a hawk when I upload in small batches. that takes like watching it for weeks. time wasted when it reboot loops while I sleep.
Yeah, super annoying.
I wonder if you could copy/paste the file with tomorrows date
i'm ok with cron scripts... thats an idea
You could either do that at midnight utc or just maintain current day + tomorrows day
I haven't looked at the download code in awhile, but I think that would work.
sooo... docker-compose on this: - /mnt/immich/micro:/usr/src/app/.reverse-geocoding-dump:ro
seems to be working... too early to tell. but I left it as it is and recreated the container
seems to be holding
lemme leave it for another day b4 I declare "semi-victory" for a workaround
i didn't rename the files with the new date name
Have you uploaded a new images with gps? It only runs reverse geocoding on demand.
I just did on a new pic upload. it worked with GPS details.
quite honestly this is like really a hacked hack. so I won't technically recommend as I'm just messing around it. for now it won't bootloop so I am happy!