Repository navigation
If finding update frequency fails the startup process fails but container still reports as running #23
Description
The reason I'm running into this is probably a bit niche so I understand if this is closed without action. And I already have a workaround.
If detecting the frequency fails an error is thrown and bubbles up to entrypoint.sh
Overpass-API/src/bin/run_osm3s.sh
Line 915 in 19e16e9
Here the container is put in zombie mode when run_osm3s.sh errors
Overpass-API/src/bin/entrypoint.sh
Line 287 in 19e16e9
This behavior seems intentional? #8
In my setup this causes issues as when the container is starting there is no network connection yet. This connection is established a bit later. For now I have fixed this by adding a delay on my side. The container is managed through a systemd service but that service cannot restart the container as it still seems running from the perspective of the monitoring service (Podman's conmon in this case).
I realize this will probably not be an issue in a normal server scenario where the network connection is always assumed to be available. However even if the network is up the source of the data that is fetched with curl (Geofabrik in this case) could experience a temporary outage. Maybe the detection of the update frequency could have some retry mechanism to deal with his?
Activity
b1tw153 commentedon Oct 24, 2026
I would suggest setting
OVERPASS_UPDATE_FREQUENCYto bypass the update frequency check but apparently that code isn't working as originally intended. So, that needs a fix.However, after that,
fetch_osc.shwill try to verify that it has been configured with a valid replication source. It fails fast (intentionally) if the replication source is not available at startup. That startup check could get some better timeout and retry settings.And yes, the zombie mode in #8 was intentional because diagnosing failures is difficult when the container exits and is automatically removed. It also prevents automatic restarts of a container that can't run, which gets ugly very quickly.
In your case, how long does it normally take to establish the network connection?
esteinmann commentedon Oct 25, 2026
Thanks for the quick response!
I am not sure how long it takes exactly. The required delay also depends on the chosen target for the systemd service to run after. If I let the service start after
graphical-session.targetthen a delay of 10 seconds is enough. Handling podman and systemd is a me problem ;) AddingExecStartPre=/bin/sleep 10sto the systemd service file was enough to make it work for now.A fix for passing OVERPASS_UPDATE_FREQUENCY to circumvent detection from the remote source could benefit other users too so that would be great.