I found a very, very, very helpful upstart script for people that are having problems in the future. Put this into /etc/init/
# /etc/init/debug.conf
start on ( starting JOB!=debug \
or started JOB!=debug \
or stopping JOB!=debug \
or stopped JOB!=debug )
script
exec 1>>/tmp/log.file
echo -n "$UPSTART_JOB/$UPSTART_INSTANCE ($0):$$:`date`:"
echo "Job $JOB/$INSTANCE $UPSTART_EVENTS. Environment was:"
env
echo
end script
This script basically logs all jobs that start or stop. I have found that CentOS 6 does not 'emit' anything about runlevels. (nor some of the other common events I had tried.'). Looking the log file that debug job creates in /tmp/log.file was very helpful. By changing the start of my script from:
start on runlevel [345]
to
start on started sshd
all my jobs appear to start up correctly. This was a pain in the rear, since every example I found used the former syntax..
So first off, upstart runs all jobs as root, so you don't need sudo, get rid of that.
Second, it would appear that your monitored program is exitting, hence the 'unknown instance' error. You should get something in /var/log/syslog telling you that the process exitted. You can add the word 'respawn' and upstart will try to start it back up again, but if it keeps exitting rapidly, upstart will give up eventually.
You are ending your line with &, which means "run this in the background". Given that, upstart will see that your shell exit (since job control is not active in a non-interactive shell, & will effectively daemonize any jobs). If you want upstart to keep this process running, and to be able to kill it, drop the &.
Also, your start on is way too explicit, and your stop on is based on an event that doesn't exist. You can just start on runlevel [2345], and stop on runlevel [^2345], and that will help your job work better in later releases as Ubuntu evolves. As of Ubuntu 11.10, it also means that it will start after all network interfaces are up, not just eth0.
More fun, you can use the 'chdir' stanza, so you don't have to use a shell at all.
So the original job is best written as:
start on runlevel [2345]
stop on runlevel [^2345]
respawn
chdir /home/ubuntu/node-monitor/run
exec /usr/local/bin/node client.js ec2=true debug=false console=true cloudwatch=true >> /var/log/node-monitor.log 2>&1
For bonus points, when Ubuntu 12.04 is released, you can use the new 'console log' feature and take out the >> /var/log/node-monitor.log , though it will write to /var/log/upstart/node-monitor.log instead.
And finally, there are no actual "alestic" AMI's anymore. Eric Hammond keeps a table of the same AMI ids which are listed on https://cloud-images.ubuntu.com.. compare http://alestic.com to http://cloud-images.ubuntu.com/query/lucid/server/released.current.txt for instance.
Best Answer
Assuming you know what files you have deleted, you can:
if you don't have a backup, you can locate the package that provides the file using either:
(if you still have the package installed; you should, you just deleted a file from it)
(if you don't have the packaged installed anymore, for whatever reason)
You can also use the Ubuntu Packages Search web site.
Afterwards, when you know which package that file you deleted came from, you can just
and the file will be there again and you will be able to stop your processes normaly.