Hi Morten, Thanks for that detailed response. I'll look at options on moving postgres. However, on one point:
Also, supervisord will eventually cease with the restart attempts when smsd fails too many times (seems to be about 6 times for me).
I'm certainly not seeing this behaviour. The container has currently been running for just short of 3 days, and it's still spawning smsd every second (will look at how to configure supervisord). In fact, it's now also spawning alertengine, eventengine and snmptrapd every second also (it wasn't doing this when the container first booted). Not sure whether it starting to respawn those tallies with the gaps starting, but conceivably the CPU or IO usage from trying to run several python scripts every second could cause postgres issues when sharing those resources? (or even the fact they're not running?)
Having looked at why those other services (other than smsd) were respawning, they thought they were already running. I've been able to recreate this. If I stop and start the container (rather than destroying and recreating it via docker-compose) then there are still .pid files for alertengine, eventengine, pping and snmptrapd in /tmp, some or all of which are datestamped for an earlier container start. It doesn't do this for all of those services every time though - guessing that if a service is busy and hasn't exited before the container stops, it doesn't clean its pid file? Or maybe it only causes an issue if there's a (different) process running on the same PID when it next starts.
Curiously, pping (and on the most recent restart of the container, apache - again, there's another process running on the same PID as Apache's lockfile) *do* get flagged by supervisord as being restarted too many times, and aborted as you had noted. Maybe there's a difference if it's a python script rather than a compiled executable (i.e. python starts cleanly but the script doesn't)
As a kludge workaround I added commands to the entrypoint script which deleted all of the PID files on the basis that at container start, the processes shouldn't be running. That seemed to make it start cleanly, but not sure if there is a better or more 'Docker'ish way to do it?
Steve.