[bug] exec: "realtime": executable file not found in $PATH

[PovilasID]

Issue Type

• [x] Bug report
• [ ] Feature request
• [ ] Question / Support

Description

Fails to launch.

Steps to Reproduce (for bugs)

1. Pull latest image
2. docker compose up -d

Expected behavior

To start the container

Actual behavior

exits with code 1

Environment

Version Information (build date)

Current dev build afb7adb3e0cdbcae7178b82cbd013ac8fc681c74

System Information

• Device:
  • [ ] Raspberry Pi (specify model, e.g., Raspberry Pi 4 Model B)
  • [ ] Other SBC (please specify)
  • [x ] PC/Server (please specify)
• OS: OpwnWRT Running in docker

LOGS

I was running container in host mode previously and after update I got this log:

stdout: Starting BirdNET-Go with UID:1000, GID:1000
stdout: Creating group birdnet with GID 1000
stdout: Adding group `birdnet' (GID 1000) ...
stdout: Done.
stdout: Creating user birdnet with UID 1000
stdout: Adding user `birdnet' ...
stdout: Adding new user `birdnet' (1000) with group `birdnet (1000)' ...
stdout: Creating home directory `/home/birdnet' ...
stdout: Copying files from `/etc/skel' ...
stdout: Adding new user `birdnet' to supplemental / extra groups `users' ...
stdout: Adding user `birdnet' to group `users' ...
stdout: Starting BirdNET-Go as user birdnet (1000:1000)
stderr: error: exec: "realtime": executable file not found in $PATH

I was not using user setting but I tried to but still got same error - BIRDNET_UID=0 - BIRDNET_GID=0

stdout: Starting BirdNET-Go with UID:0, GID:0
stdout: Starting BirdNET-Go as user root (0:0)
stderr: error: exec: "realtime": executable file not found in $PATH

Docker compose file

version: "3.9"
services:
  birdnet:
    image: ghcr.io/tphakala/birdnet-go:dev 
    container_name: birdnet
    network_mode: host
    volumes:
      - ./config:/config
      - ./data:/data
    command: realtime --rtsp rtsp://192.168.1.1:/doors?audio=any 

Additional context

Possibly related issue https://github.com/tphakala/birdnet-go/issues/657 Something has changed in user handling

Possible Solution

Reverting to older versions worked

[hillbicks]

I think my problem is related to this issue. I forgot to save the error message, but it was related to the clips directory. For some reason it wanted to start /usr/bin/clips. Reverting to 20250421 solved the issue for me. I'm also using a docker compose file. I can try once again with the current image and provide the exact error message if that helps.

[y8s]

OK I had this same issue and just fixed it. (specific to using RTSP stream from a URL)

Here's where I noticed weirdness:

1. I removed the command: realtime -rtsp rtps://url line from docker (it's still in the config.yaml under realtime: rtsp: urls:
2. in my config.yaml , my locale was set to en but a new installation set it to en-us locale: en becomes locale: en-us
3. in my config.yaml , realtime audio source was set to "" and in the new install the source was commented.

realtime:
  audio:
    source: "" # this was also "sysdefault" in some examples

becomes

realtime:
  audio:
#    source: ""

4. maybe a change, maybe not, but i was saving clips to an NFS mount and the update broke it. for example, I put /mnt/docker/birdnet/clips but it failed with a permission error. I had to map the location in docker as - /mnt/docker/birdnet/clips:/data/clips and just left the default value.

~~

after those changes it all works.

[PovilasID]

@y8s Commuting out command: line in my docker compose seams to have worked. I used it because in previous versions I had issues with RSTP streams not surviving container updates but for not it seams ok. Has the command functionality been deprecated and this can be closed or is it supposed to work and moving the config to config file only is just a temporary fix?

[y8s]

@y8s Commuting out command: line in my docker compose seams to have worked. I used it because in previous versions I had issues with RSTP streams not surviving container updates but for not it seams ok. Has the command functionality been deprecated and this can be closed or is it supposed to work and moving the config to config file only is just a temporary fix?

Since my config is stored in a bind mount it doesn't go anywhere and all the settings are retained. There's also no reason it would be overwritten and so should retain the streaming URL and associated settings unless you destroy the volume it's stored in or otherwise remove it.

Either way, there's a provision to set the audio source in the web UI (it stores it in config.yaml) in case you need to fix it later.

[PovilasID]

@y8s Oh I had it mounted too maybe it was a much earlier issue when config structure was more fluid. Basically I pulled dev a couple of times and would just wipe config. Even now en vs en-us thing... not too reliable between versions