immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Immich Unresponsive After Initial Boot #3967

New Issue
Closed
opened 2026-02-05 09:32:33 +03:00 by OVERLORD · 12 comments
OVERLORD commented 2026-02-05 09:32:33 +03:00
Owner
Copy Link

Originally created by @SummitPatel on GitHub (Jul 26, 2024).

The bug

Hi,

I've been trying to get the Unraid version of Immich up and running for a few days no with no luck. After installing the docker image and running the container, everything seems to boot as expected initially. After a few minutes however, my CPU cores are maxed out. I am not able to access the webUI.

I've had this issue since v1.108.0 when I initially tried to set this up. After 2 versions and the same behavior happening, I'm not sure if this a user issue or something with Immich itself.

The OS that Immich Server is running on

Unraid 6.12.10

Version of Immich Server

v1.110.0

Version of Immich Mobile App

N/A

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

#
# WARNING: 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:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, openvino] 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, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:328fe6a5822256d065debb36617a8169dbfbd77b797c525288e465f56c1d392b
    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:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --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=/mnt/user/data/media/photos
# The location where your database files are stored
DB_DATA_LOCATION=/mnt/user/appdata/immich/postresql/data

# 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=Etc/UTC

# 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
DB_PASSWORD=REDACTED

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=REDACTED
DB_DATABASE_NAME=REDACTED

Reproduction steps

1. I run `Compose Up` through the Unraid GUI
2. Wait for containers to start. Press `Done` once I receive the `Connection Closed` message
3. Try to hit the webUI and am met with a black screen

Relevant log output

immich_postgres

2024-07-26 18:24:00.865 UTC [1] LOG:  redirecting log output to logging collector process
2024-07-26 18:24:00.865 UTC [1] HINT:  Future log output will appear in directory "log".

PostgreSQL Database directory appears to contain a database; Skipping initialization


immich_redis

1:C 26 Jul 2024 18:23:49.558 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 26 Jul 2024 18:23:49.558 # Redis version=6.2.14, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 26 Jul 2024 18:23:49.558 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 26 Jul 2024 18:23:49.559 * monotonic clock: POSIX clock_gettime
1:M 26 Jul 2024 18:23:49.560 * Running mode=standalone, port=6379.
1:M 26 Jul 2024 18:23:49.560 # Server initialized
1:M 26 Jul 2024 18:23:49.560 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 26 Jul 2024 18:23:49.560 * Ready to accept connections


immich_machine_learning

[07/26/24 18:24:04] INFO     Starting gunicorn 22.0.0                           
[07/26/24 18:24:04] INFO     Listening at: http://[::]:3003 (8)                 
[07/26/24 18:24:04] INFO     Using worker: app.config.CustomUvicornWorker       
[07/26/24 18:24:04] INFO     Booting worker with pid: 9


immich_server

Detected CPU Cores: 4

Additional information

Please let me know if there is any other information I can provide to help troubleshoot.

Originally created by @SummitPatel on GitHub (Jul 26, 2024). ### The bug Hi, I've been trying to get the Unraid version of Immich up and running for a few days no with no luck. After installing the docker image and running the container, everything seems to boot as expected initially. After a few minutes however, my CPU cores are maxed out. I am not able to access the webUI. I've had this issue since v1.108.0 when I initially tried to set this up. After 2 versions and the same behavior happening, I'm not sure if this a user issue or something with Immich itself. ### The OS that Immich Server is running on Unraid 6.12.10 ### Version of Immich Server v1.110.0 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML # # WARNING: 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: - ${UPLOAD_LOCATION}:/usr/src/app/upload - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - 2283:3001 depends_on: - redis - database restart: always immich-machine-learning: container_name: immich_machine_learning # For hardware acceleration, add one of -[armnn, cuda, openvino] 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, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable volumes: - model-cache:/cache env_file: - .env restart: always redis: container_name: immich_redis image: docker.io/redis:6.2-alpine@sha256:328fe6a5822256d065debb36617a8169dbfbd77b797c525288e465f56c1d392b 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:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_USER: ${DB_USERNAME} POSTGRES_DB: ${DB_DATABASE_NAME} POSTGRES_INITDB_ARGS: '--data-checksums' volumes: - ${DB_DATA_LOCATION}:/var/lib/postgresql/data healthcheck: test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --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 ```Shell # 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=/mnt/user/data/media/photos # The location where your database files are stored DB_DATA_LOCATION=/mnt/user/appdata/immich/postresql/data # 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=Etc/UTC # 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 DB_PASSWORD=REDACTED # The values below this line do not need to be changed ################################################################################### DB_USERNAME=REDACTED DB_DATABASE_NAME=REDACTED ``` ### Reproduction steps ```bash 1. I run `Compose Up` through the Unraid GUI 2. Wait for containers to start. Press `Done` once I receive the `Connection Closed` message 3. Try to hit the webUI and am met with a black screen ``` ### Relevant log output ```shell immich_postgres 2024-07-26 18:24:00.865 UTC [1] LOG: redirecting log output to logging collector process 2024-07-26 18:24:00.865 UTC [1] HINT: Future log output will appear in directory "log". PostgreSQL Database directory appears to contain a database; Skipping initialization immich_redis 1:C 26 Jul 2024 18:23:49.558 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 26 Jul 2024 18:23:49.558 # Redis version=6.2.14, bits=64, commit=00000000, modified=0, pid=1, just started 1:C 26 Jul 2024 18:23:49.558 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf 1:M 26 Jul 2024 18:23:49.559 * monotonic clock: POSIX clock_gettime 1:M 26 Jul 2024 18:23:49.560 * Running mode=standalone, port=6379. 1:M 26 Jul 2024 18:23:49.560 # Server initialized 1:M 26 Jul 2024 18:23:49.560 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 1:M 26 Jul 2024 18:23:49.560 * Ready to accept connections immich_machine_learning [07/26/24 18:24:04] INFO Starting gunicorn 22.0.0 [07/26/24 18:24:04] INFO Listening at: http://[::]:3003 (8) [07/26/24 18:24:04] INFO Using worker: app.config.CustomUvicornWorker [07/26/24 18:24:04] INFO Booting worker with pid: 9 immich_server Detected CPU Cores: 4 ``` ### Additional information Please let me know if there is any other information I can provide to help troubleshoot.
OVERLORD commented 2026-02-05 09:32:37 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jul 26, 2024):

@zackpollard Please correct me if I am wrong; when the server starts up, microservices get the updated information for geocoding data and update the table. Depending on your CPU/Disk setup, the finish time might differ.

@alextran1502 commented on GitHub (Jul 26, 2024): @zackpollard Please correct me if I am wrong; when the server starts up, microservices get the updated information for geocoding data and update the table. Depending on your CPU/Disk setup, the finish time might differ.
OVERLORD commented 2026-02-05 09:32:38 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Jul 26, 2024):

@zackpollard Please correct me if I am wrong; when the server starts up, microservices get the updated information for geocoding data and update the table. Depending on your CPU/Disk setup, the finish time might differ.

The server should still boot if I remember correctly, but microservices won't process any exif data until that stuff finishes importing.

@zackpollard commented on GitHub (Jul 26, 2024): > @zackpollard Please correct me if I am wrong; when the server starts up, microservices get the updated information for geocoding data and update the table. Depending on your CPU/Disk setup, the finish time might differ. The server should still boot if I remember correctly, but microservices won't process any exif data until that stuff finishes importing.
OVERLORD commented 2026-02-05 09:32:40 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jul 26, 2024):

Yeah, the server should still boot, unless the CPU of this server is very underpowered so it is using everything to read/write the data to the database and block the requests

@alextran1502 commented on GitHub (Jul 26, 2024): Yeah, the server should still boot, unless the CPU of this server is very underpowered so it is using everything to read/write the data to the database and block the requests
OVERLORD commented 2026-02-05 09:32:43 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 26, 2024):

Appreciate the quick replies!

The server should still boot if I remember correctly, but microservices won't process any exif data until that stuff finishes importing.

Is this something that would happen on existing images? Because I should say that this is a brand new server with 0 images inside of it. If not, I'll try and let this run for a few minutes to see if it eventually starts up.

I'm just worried about letting my CPUs run at 100% for an extended period of time 😅

@SummitPatel commented on GitHub (Jul 26, 2024): Appreciate the quick replies! > The server should still boot if I remember correctly, but microservices won't process any exif data until that stuff finishes importing. Is this something that would happen on existing images? Because I should say that this is a brand new server with 0 images inside of it. If not, I'll try and let this run for a few minutes to see if it eventually starts up. I'm just worried about letting my CPUs run at 100% for an extended period of time 😅
OVERLORD commented 2026-02-05 09:32:45 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jul 26, 2024):

Oh your CPU will max out for a long time for initial ingestion :D

@alextran1502 commented on GitHub (Jul 26, 2024): Oh your CPU will max out for a long time for initial ingestion :D
OVERLORD commented 2026-02-05 09:32:47 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 26, 2024):

Yeah, the server should still boot, unless the CPU of this server is very underpowered so it is using everything to read/write the data to the database and block the requests

I'm running a Intel® Celeron® N5105 @ 2.00GHz.

This is all happening on an Asustor Lockerstor 4 Gen2 AS6704T.

I've actually ordered some RAM that I plan to install so maybe that will help with the load, but for right now it's running at the base 4GB of RAM.

@SummitPatel commented on GitHub (Jul 26, 2024): > Yeah, the server should still boot, unless the CPU of this server is very underpowered so it is using everything to read/write the data to the database and block the requests I'm running a Intel® Celeron® N5105 @ 2.00GHz. This is all happening on an Asustor Lockerstor 4 Gen2 AS6704T. I've actually ordered some RAM that I plan to install so maybe that will help with the load, but for right now it's running at the base 4GB of RAM.
OVERLORD commented 2026-02-05 09:32:48 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 26, 2024):

Oh your CPU will max out for a long time for initial ingestion :D

Ok let me let this run for 30 minutes. I'll report back and see what happens

@SummitPatel commented on GitHub (Jul 26, 2024): > Oh your CPU will max out for a long time for initial ingestion :D Ok let me let this run for 30 minutes. I'll report back and see what happens
OVERLORD commented 2026-02-05 09:32:52 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 26, 2024):

Everything is still running at 100% 😓

Should I expect to see anything new in the logs? Nothing has changed in the machine learning or immich server logs so far

@SummitPatel commented on GitHub (Jul 26, 2024): Everything is still running at 100% 😓 Should I expect to see anything new in the logs? Nothing has changed in the machine learning or immich server logs so far
OVERLORD commented 2026-02-05 09:32:56 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Jul 26, 2024):

I wouldn't expect it to have issues like this on initial boot, not sure what exactly it could be doing to be honest.

@zackpollard commented on GitHub (Jul 26, 2024): I wouldn't expect it to have issues like this on initial boot, not sure what exactly it could be doing to be honest.
OVERLORD commented 2026-02-05 09:32:57 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Jul 26, 2024):

It looks to me that it never actually created the microservices or server workers for some reason...

@zackpollard commented on GitHub (Jul 26, 2024): It looks to me that it never actually created the microservices or server workers for some reason...
OVERLORD commented 2026-02-05 09:32:58 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 26, 2024):

Maybe this is helpful, maybe not, but I was also trying to get up and running with the community maintained image last week. The same issue was happening, but I was able to get some more logs to display.

Additionally, I could at least get into the webUI for a few seconds. But then it would hang again and lock up as it's currently doing.

https://github.com/imagegenius/docker-immich/issues/418

@SummitPatel commented on GitHub (Jul 26, 2024): Maybe this is helpful, maybe not, but I was also trying to get up and running with the community maintained image last week. The same issue was happening, but I was able to get some more logs to display. Additionally, I could at least get into the webUI for a few seconds. But then it would hang again and lock up as it's currently doing. https://github.com/imagegenius/docker-immich/issues/418
OVERLORD commented 2026-02-05 09:33:00 +03:00
Author
Owner
Copy Link

@SummitPatel commented on GitHub (Jul 29, 2024):

Ok I think I can confidently say that this was an issue caused by low RAM. I upgraded from 4GB to 16GB over the weekend and now I am able to get past the initial boot sequence in under 2 minutes and everything remains stable.

I see on the Requirements page that 4GB is the minimum, but I would humbly ask to consider bumping that up to 6GB.

If this seems like a good idea, let me know and I can submit a PR to update the docs.

Cheers!

@SummitPatel commented on GitHub (Jul 29, 2024): Ok I think I can confidently say that this was an issue caused by low RAM. I upgraded from 4GB to 16GB over the weekend and now I am able to get past the initial boot sequence in under 2 minutes and everything remains stable. I see on the [Requirements page](https://immich.app/docs/install/requirements) that 4GB is the minimum, but I would humbly ask to consider bumping that up to 6GB. If this seems like a good idea, let me know and I can submit a PR to update the docs. Cheers!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#3967
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?