I have a process xyz, whose upstart script is as below
description "Run the xyz daemon"
author "xyz"
import SETTINGS
start on (
start-ap-services SETTINGS
)
stop on (
stop-ap-services SETTINGS
) or stopping system-services
respawn
oom score 0
script
. /usr/share/settings.sh
# directory for data persisted between boots
XYZ_DIR="/var/lib/xyz"
mkdir -p "${XYZ_DIR}"
chown -R xyz:xyz "${XYZ_DIR}"
if [ "${SETTING}" = 1 ]
ARGS="$ARGS --enable_stats=true"
fi
# CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE.
exec /sbin/minijail0 -p -c 0x0402 -u xyz -g xyz \
-G /usr/bin/xyz ${ARGS}
else
exec sleep inf
fi
end script
# Prevent the job from respawning too quickly.
post-stop exec sleep 3
Now, due to OOM issue. xyz is killed based on it's OOM score and it gets respawned as expected. After a several restart of xyz, the post-stop sleep is killed after which xyz is never respawned.
How can this be prevented or Is there any solution to this?
Note: Name xyz is a dummy process name used only to mention my actual doubt.
I haven't worked on upstart scripts before. Any help would be of greater help.
Upstart can get confused when post-stop, pre-start, and post-start sections remain running across respawns.
I prefer to keep any command that takes longer than a few hundred milliseconds in a main job section, using auxiliary jobs if necessary.
For example, this will stall a job
xyzthat is being respawned or otherwise stopped:This has the same effect as your post-stop stanza, except that Upstart can better handle the state tracking for the simplified main job.