[Support]: Hangs on "Starting migrations"

Describe the problem you are having

Frigate never fully initializes, and is stuck on peewee migrate.

Version

0.11.0-3846a13

Frigate config file

mqtt:
    # Required: host name
    host: hass.lan

  logger:
    # Optional: default log level
    default: debug
    
  database:
    # Specified in docker-compose.yml
    path: /db/frigate.db

  cameras:
    cam01-front_door:
      ffmpeg:
        inputs:
          - path: rtsp://username:password@10.1.30.11:554/cam/realmonitor?channel=1&subtype=0
            roles:
              - record
              - rtmp
              - detect
      detect:
        width: 3840
        height: 2160

Relevant log output

ryanb@k8s01:~/git/homelab/k3s$ kubectl logs -n frigate deployment.apps/frigate
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[2022-10-11 21:29:10] frigate.app                    INFO    : Starting Frigate (0.11.0-3846a13)
[2022-10-11 21:29:10] frigate.app                    INFO    : Creating directory: /media/frigate/recordings
[2022-10-11 21:29:10] frigate.app                    INFO    : Creating directory: /media/frigate/clips
[2022-10-11 21:29:10] frigate.app                    INFO    : Creating directory: /tmp/cache
Starting migrations
[2022-10-11 21:29:10] peewee_migrate                 INFO    : Starting migrations
[2022-10-11 21:29:10] peewee                         DEBUG   : ('CREATE TABLE IF NOT EXISTS "migratehistory" ("id" INTEGER NOT NULL PRIMARY KEY, "name" VARCHAR(255) NOT NULL, "migrated_at" DATETIME NOT NULL)', [])

FFprobe output from your camera

n/a

Frigate stats

n/a

Operating system

Debian

Install method

Docker Compose

Coral version

CPU (no coral)

Network connection

Wired

Camera make and model

Amcrest

Any other information that may be helpful

Basically, it hangs at this “migrate” step, even if I start completely fresh with an empty /db folder.

Also important (maybe?) to note - I installed via Helm: https://github.com/blakeblackshear/blakeshome-charts/tree/master/charts/frigate

# values.yaml
config: |
  mqtt:
    host: hass.lan

  logger:
    default: debug
    
  database:
    path: /db/frigate.db

  cameras:
    cam01-front_door:
      ffmpeg:
        inputs:
          - path: rtsp://admin:Imsoin11@10.1.30.11:554/cam/realmonitor?channel=1&subtype=0
            roles:
              - record
              - rtmp
              - detect
      detect:
        width: 3840
        height: 2160

extraVolumes:
- name: frigate-db
  nfs: 
    server: omv.lan
    path: /export/k8s_storage/frigate

extraVolumeMounts:
- name: frigate-db
  mountPath: /db

When I run the container, and it gets stuck, you can see that it did create the frigate.db:

ryanb@docker:~$ ls -anl /mnt/omv-k8s_storage/frigate/
total 0
drwxr-sr-x 2 1000 100 24 Oct 11 16:27 .
drwxrwsr-x 6 1000 100 66 Oct 10 14:37 ..
-rw-r--r-- 1    0 100  0 Oct 11 16:27 frigate.db

More Kubernetes stuff:

ryanb@k8s01:~/git/homelab/k3s$ kubectl describe -n frigate deployments/frigate
Name:               frigate
Namespace:          frigate
CreationTimestamp:  Tue, 11 Oct 2022 16:35:25 -0500
Labels:             app.kubernetes.io/instance=frigate
                    app.kubernetes.io/managed-by=Helm
                    app.kubernetes.io/name=frigate
                    app.kubernetes.io/version=0.11.0
                    helm.sh/chart=frigate-7.0.0
Annotations:        deployment.kubernetes.io/revision: 1
                    meta.helm.sh/release-name: frigate
                    meta.helm.sh/release-namespace: frigate
Selector:           app.kubernetes.io/instance=frigate,app.kubernetes.io/name=frigate
Replicas:           1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType:       Recreate
MinReadySeconds:    0
Pod Template:
  Labels:       app.kubernetes.io/instance=frigate
                app.kubernetes.io/name=frigate
  Annotations:  checksum/configmap: b1fca42fc8b936b5ebc1447ad4c31ac5b9894fd71bf47651577f76f5e4f25916
  Containers:
   frigate:
    Image:        blakeblackshear/frigate:0.11.0
    Ports:        5000/TCP, 1935/TCP
    Host Ports:   0/TCP, 0/TCP
    Liveness:     http-get http://:http/ delay=30s timeout=10s period=10s #success=1 #failure=5
    Readiness:    http-get http://:http/ delay=30s timeout=10s period=10s #success=1 #failure=5
    Environment:  <none>
    Mounts:
      /config from config (rw)
      /data from data (rw)
      /db from frigate-db (rw)
      /dev/shm from dshm (rw)
  Volumes:
   config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      frigate
    Optional:  false
   data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
   dshm:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     Memory
    SizeLimit:  1Gi
   frigate-db:
    Type:      NFS (an NFS mount that lasts the lifetime of a pod)
    Server:    omv.lan
    Path:      /export/k8s_storage/frigate
    ReadOnly:  false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      False   MinimumReplicasUnavailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:  <none>
NewReplicaSet:   frigate-78cb9fdc88 (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  4s    deployment-controller  Scaled up replica set frigate-78cb9fdc88 to 1

[SlothCroissant]

Can confirm that not mapping any volumes at all (so Frigate just writes to ephemeral storage within the container itself) allows frigate to boot properly - likely a permissions issue on my side.

I’ll keep digging around. Could be a nice feature request to have this fail more gracefully 😃

Thanks for your help, @NickM-27 !

[NickM-27]

We usually recommend keeping the db file itself on a local drive. We’ve seen users who had issues running the db file on an NFS share