Repository navigation
Endless restarting of immich-server on v1.132.1 #17874
Description
I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.
- Yes
The bug
I'm running Docker on a Mac mini M1
The OS that Immich Server is running on
macOS Sequoia 15.3
Version of Immich Server
v1.132.1
Version of Immich Mobile App
N/A
Platform with the issue
- Server
- Web
- Mobile
Your docker-compose.yml content
#
# WARNING: To install Immich, follow our guide: https://immich.app/docs/install/docker-compose
#
# Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
name: immich
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
# extends:
# file: hwaccel.transcoding.yml
# service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
volumes:
# Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
- ${UPLOAD_LOCATION}:/usr/src/app/upload
- /etc/localtime:/etc/localtime:ro
env_file:
- .env
ports:
- '2283:2283'
depends_on:
- redis
- database
restart: always
healthcheck:
disable: false
immich-machine-learning:
container_name: immich_machine_learning
# For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
# Example tag: ${IMMICH_VERSION:-release}-cuda
image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
# extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
# file: hwaccel.ml.yml
# service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
volumes:
- model-cache:/cache
env_file:
- .env
restart: always
healthcheck:
disable: false
redis:
container_name: immich_redis
image: docker.io/valkey/valkey:8-bookworm@sha256:42cba146593a5ea9a622002c1b7cba5da7be248650cbb64ecb9c6c33d29794b1
healthcheck:
test: redis-cli ping || exit 1
restart: always
database:
container_name: immich_postgres
image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:739cdd626151ff1f796dc95a6591b55a714f341c737e27f045019ceabf8e8c52
environment:
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_USER: ${DB_USERNAME}
POSTGRES_DB: ${DB_DATABASE_NAME}
POSTGRES_INITDB_ARGS: '--data-checksums'
volumes:
# Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
- ${DB_DATA_LOCATION}:/var/lib/postgresql/data
healthcheck:
test: >-
pg_isready --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" || exit 1; Chksum="$$(psql --dbname="$${POSTGRES_DB}" --username="$${POSTGRES_USER}" --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1
interval: 5m
start_interval: 30s
start_period: 5m
command: >-
postgres -c shared_preload_libraries=vectors.so -c 'search_path="$$user", public, vectors' -c logging_collector=on -c max_wal_size=2GB -c shared_buffers=512MB -c wal_compression=on
restart: always
volumes:
model-cache:Your .env content
# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables
# The location where your uploaded files are stored
UPLOAD_LOCATION="/Volumes/4TB G-Drive/Photos/Immich"
# The location where your database files are stored
DB_DATA_LOCATION=./postgres
# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
TZ=America/Chicago
# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release
# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=postgres
# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immichReproduction steps
- Execute
docker compose pull && docker compose up -dto get v1.132.1 - If you catch the server while it is running, you will see an Immich error that says "Importing a module script failed. - 500 undefined"
- If you monitor the docker logs for immesh-server you will see that it restarts every 8-10 seconds, though no errors are logged.
...
Relevant log output
[Nest] 17 - 04/25/2025, 4:00:32 AM LOG [Api:RouterExplorer] Mapped {/api/view/folder/unique-paths, GET} route
[Nest] 17 - 04/25/2025, 4:00:32 AM LOG [Api:RouterExplorer] Mapped {/api/view/folder, GET} route
[Nest] 17 - 04/25/2025, 4:00:32 AM LOG [Api:NestApplication] Nest application successfully started
[Nest] 17 - 04/25/2025, 4:00:32 AM LOG [Api:Bootstrap] Immich Server is listening on http://[::1]:2283 [v1.132.1] [production]
Initializing Immich v1.132.1
Detected CPU Cores: 8
Starting api worker
Starting microservices worker
Initializing Immich v1.132.1
Detected CPU Cores: 8
Starting api worker
Starting microservices worker
[Nest] 7 - 04/25/2025, 4:01:03 AM LOG [Microservices:EventRepository] Initialized websocket server
[Nest] 17 - 04/25/2025, 4:01:03 AM LOG [Api:EventRepository] Initialized websocket server
[Nest] 7 - 04/25/2025, 4:01:03 AM LOG [Microservices:DatabaseRepository] Running migrations, this may take a while
[Nest] 7 - 04/25/2025, 4:01:03 AM LOG [Microservices:MetadataService] Bootstrapping metadata service
[Nest] 7 - 04/25/2025, 4:01:03 AM LOG [Microservices:MetadataService] Initializing metadata serviceAdditional information
In the log I attached you will see that the server becomes reachable, however 30 seconds later it has begun the startup process again indicated an exception is crashing the whole app.
Reverting to v.1.132.0 causes the error described in #17818 . Reverting to v.1.131.3 restored functionality again.
Activity
[-]Endless restarting of immesh-server on 1.132.1[/-][+]Endless restarting of immich-server on 1.132.1[/+][-]Endless restarting of immich-server on 1.132.1[/-][+]Endless restarting of immich-server on v1.132.1[/+]bo0tzz commentedon Apr 25, 2025
Please run
docker compose upwithout the -d, to get the complete log including any errors.alextran1502 commentedon Apr 25, 2025
And the app is called Immich btw 😅 not Immesh
MajorLazer2142 commentedon Apr 25, 2025
Hi,
I'm experiencing an issue where Immich does not start properly after updating to version 1.132.1. The server seems to initialize, but it gets stuck, and the application is not accessible. From the logs, it appears that the database migrations might be causing the issue, as the last log entry mentions "Running migrations, this may take a while." There are no explicit error messages, but the server does not complete the startup process.
I've checked that all containers (immich_server, immich_postgres, immich_redis, immich_machine_learning) are running, and there are no obvious network or resource issues. Could you help identify what might be causing this? Are there known issues with v1.132.1 migrations or configuration changes required for this version?
Attached are the relevant logs for reference:
Any guidance on troubleshooting this issue or checking the migration status would be greatly appreciated!
Thanks
bo0tzz commentedon Apr 25, 2025
How long did you wait for? Like it says, it might take a while.
MajorLazer2142 commentedon Apr 25, 2025
I waited for over 30 minutes, and the Immich server is still stuck on "Running migrations, this may take a while" with no further log entries or errors. Given the extended time, it seems like the migration process might be stalled. Any suggestions on how to diagnose or resolve this?
alextran1502 commentedon Apr 25, 2025
@extreme4u What version did you update from and what is the size of your library?
MajorLazer2142 commentedon Apr 25, 2025
I updated from version v1.131.0, and my library has a size of 153 GB.
alextran1502 commentedon Apr 25, 2025
Have you try brought down the stack then up again?
MajorLazer2142 commentedon Apr 25, 2025
Yes, I have tried bringing down the stack and starting it up again.
mmomjian commentedon Apr 25, 2025
Please enter the
DB_DATA_LOCATIONfolder (the postgres database) and take a look at the contents of thelogs/folder there, uploading the most recent entries.MajorLazer2142 commentedon Apr 25, 2025
``
Okay, here are the last logs of the folder. No wonder I anonymized the owner ID and checksum.
I think we found the problem. At the moment, I don't really know how to handle it.
DJFriar commentedon Apr 26, 2025
Here are the logs from doing this. Note that when I did this I did not have any browser attempting to load Immich, and as soon as I opened one I got an error and then the loops started.
These logs show the initial pull and start, then the first load, the crash, and then one loop of it crashing on it's own with no further action from me.
Logs Start Here
Yxini-p commentedon Apr 26, 2025
Yxini-p commentedon Apr 26, 2025
Yxini-p commentedon Apr 26, 2025
bo0tzz commentedon Apr 26, 2025
This is very strange. Code 0 means it's exiting cleanly, not crashing.
In your first post you mentioned
But I don't see that anywhere in these logs.
Are you running anything that might be 'managing' your containers? Portainer, watchtower, or something else?
Yxini-p commentedon Apr 26, 2025
i use Portainer、Dockge but i dont use them to managing immich
rupekeshan commentedon Apr 26, 2025
Getting this error:
[Nest] 7 - 04/26/2025, 5:20:07 PM ERROR [Microservices:MetadataService] Unable to initialize reverse geocoding: PostgresError: null value in column "modificationDate" of relation "geodata_places" violates not-null constraint PostgresError: null value in column "modificationDate" of relation "geodata_places" violates not-null constraint at ErrorResponse (/usr/src/app/node_modules/postgres/cjs/src/connection.js:790:26) at handle (/usr/src/app/node_modules/postgres/cjs/src/connection.js:476:6) at Socket.data (/usr/src/app/node_modules/postgres/cjs/src/connection.js:315:9) at Socket.emit (node:events:518:28) at addChunk (node:internal/streams/readable:561:12) at readableAddChunkPushByteMode (node:internal/streams/readable:512:3) at Readable.push (node:internal/streams/readable:392:5) at TCP.onStreamRead (node:internal/stream_base_commons:189:23) Error: Metadata service init failed at MetadataService.init (/usr/src/app/dist/services/metadata.service.js:95:19) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async MetadataService.onBootstrap (/usr/src/app/dist/services/metadata.service.js:74:9) at async EventRepository.onEvent (/usr/src/app/dist/repositories/event.repository.js:126:13) at async MicroservicesModule.onModuleInit (/usr/src/app/dist/app.module.js:83:9) at async callModuleInitHook (/usr/src/app/node_modules/@nestjs/core/hooks/on-module-init.hook.js:51:9) at async NestApplication.callInitHook (/usr/src/app/node_modules/@nestjs/core/nest-application-context.js:242:13) at async NestApplication.init (/usr/src/app/node_modules/@nestjs/core/nest-application.js:100:9) at async NestApplication.listen (/usr/src/app/node_modules/@nestjs/core/nest-application.js:170:13) at async bootstrap (/usr/src/app/dist/workers/microservices.js:25:5) microservices worker error: Error: Metadata service init failed, stack: Error: Metadata service init failed at MetadataService.init (/usr/src/app/dist/services/metadata.service.js:95:19) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async MetadataService.onBootstrap (/usr/src/app/dist/services/metadata.service.js:74:9) at async EventRepository.onEvent (/usr/src/app/dist/repositories/event.repository.js:126:13) at async MicroservicesModule.onModuleInit (/usr/src/app/dist/app.module.js:83:9) at async callModuleInitHook (/usr/src/app/node_modules/@nestjs/core/hooks/on-module-init.hook.js:51:9) at async NestApplication.callInitHook (/usr/src/app/node_modules/@nestjs/core/nest-application-context.js:242:13) at async NestApplication.init (/usr/src/app/node_modules/@nestjs/core/nest-application.js:100:9) at async NestApplication.listen (/usr/src/app/node_modules/@nestjs/core/nest-application.js:170:13) at async bootstrap (/usr/src/app/dist/workers/microservices.js:25:5) microservices worker exited with code 1dwantstocode commentedon Apr 26, 2025
+1. seeing this same issue suddenly as of this AM. All the jobs were stuck, so I restarted my immich stack in portainer and now immich-server and immich-db wouldn't start successfully. Immich-redis and immich-learning are starting okay.
DJFriar commentedon Apr 28, 2025
No I do not. Just a basic Docker Desktop install and then I manually copy/paste the docker-compose.yaml and the .env contents from the GitHub and modify as needed (though I don't believe I have made any modifications to the docker-compose.yaml; the one in use is copied in the first post).
Not sure if it makes a difference, but this is running on an M1 Mac mini with macOS Sequoia (15.4). If I change the .env file to use 1.131.3 everything works fine, but as soon as I put it back to latest, I get the constant restart issue. I
MZAccount commentedon Apr 29, 2025
+1, though this is my first time running Immich. The server is on Linux Portainer, and I tried the portainer guide from the docs, with the docker-compose.yml and example.env from github.
Edit: I downgraded to v1.130.3 and the stack works for me (the postgres container did need a restart).
TrezOne commentedon Apr 29, 2025
Similar issue here; in order to get
immich-serverrunning, I have to restart the-dband-machine-learningcontainers. My setup is in Docker Compose with some modifications and the addition of thepublic-proxyandpower-toolscontainers.DJFriar commentedon Jun 9, 2025
Version 1.134.0 does not appear to exhibit this behavior and is working fine on my system now.