While the agents are quite resilient they can crash once in a while, or can even self kill from the All Processes view.
I've written an upstart script that I'm sharing here. It should start the agent automatically on reboot as well as keeping it alive if it crashes.
Save it as /etc/init/glu-agent.conf and you should be good to go.
Note that you will have to update the 'env' lines as well as 'setuid', 'setgid' and 'chdir'.
Tested on Ubuntu 12.04 LTS.
description "Glu agent"
author "Stephane Odul"
# based on http://tad-do.net/2013/07/24/writing-upstart-script-for-forky-java-application/
start on (filesystem and net-device-up IFACE=lo)
stop on runlevel [!2345]
# respawn the job up to 10 times within a 5 second period.
respawn limit 10 5
# Note: the variables do not expand for setuid, setgid or chdir in upstart config files.
# Start the app in the pre-start script
echo "$(date): calling $APP_SCRIPT stop (pre-start)"
echo "$(date): calling $APP_SCRIPT start"
# Main script is actually tracking the process
echo "$(date): trackApp: tracking $APP_USER org.linkedin.glu.agent-server"
while [ $(pgrep -U $APP_USER -c -f org.linkedin.glu.agent-server) -gt 0 ]; do
echo "$(date): trackApp: no $APP_USER org.linkedin.glu.agent-server process"
# Graceful shutdown
echo $(date) calling $APP_SCRIPT stop
exec $APP_SCRIPT stop
I actually do not know, we do not use the autoupgrade feature since our Glu agent files are deployed and managed by Salt (similar to Puppet but in Python).
I'll try to find some time to run the tutorial on a VM and see what needs to happen with the auto-upgrade procedure. My guess is that the auto-upgrade would replace some steps with 'sudo stop glu-agent', perform the upgrade, then 'sudo start glu-agent'.
I've forked the flu-contrib project and will pull/push the upstart script under setups.
Note: the respawn rule is not very good. It is set to stop if it fails 10 times over 5s. Since we have some 'sleeps' in there I should probably rewrite it as failing 5 times over 10s.