Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an upstart service to start bluepill (Ruby gem to monitor processes). The upstart config is below.

description "Start up the bluepill service"

start on runlevel [2]
stop on runlevel [016]

exec sudo /home/deploy/.rvm/wrappers/<app_name>/bluepill load /home/deploy/websites/<app_name>/current/config/server/staging/delayed_job.bluepill

I want bluepill to be started as root.

All upstart configs are run as root, when the machine boots, right? So, no sudo should be needed in the upstart config's exec line.

The above script works just fine, and bluepill starts on system boot. But if I remove the sudo on the exec line, bluepill does not start on system boot. Looking at the log, it seems like bluepill is starting as a non-privileged user and thus fails.

Can anybody explain why?

I don't want sudo to be used, because, when I give respawn, upstart tracks the PID of the sudo process and not the PID of the actual bluepill process.

share|improve this question

I seriously doubt that your job is starting correctly. Most likely you would find in /var/log/upstart/yourjobconfigname.log following line:

sudo: sorry, you must have a tty to run sudo

sudo is meant to be used interactively. See How should I use sudo from an upstart script? for details.

You should reconsider your design. It will be much better to create dedicated system user that will run your job process and apply needed permissions. In your job configuration you would need to add setuid and perhaps setgid stanzas.

description "Start up the bluepill service"

start on runlevel [2]
stop on runlevel [016]

setuid bluepill
setgid bluepill
exec sudo /home/deploy/.rvm/wrappers/<app_name>/bluepill load /home/deploy/websites/<app_name>/current/config/server/staging/delayed_job.bluepill

bluepill is added designated system user. See adduser for details.

sudo adduser --system --group --no-create-home bluepill

Based on the tickets mentioned in the comment adding expect daemon stanza might be helpful. When starting bluepill process starts as daemon e.g. there will be two forks. Without expect daemon stanza Upstart cannot track PIDs properly. As said in entry on expect stanza This stanza is extremely important.

share|improve this answer
My job definitely starts with sudo. If it makes any difference, I have allowed the deploy user to execute /home/deploy/.rvm/wrappers/<app_name>/bluepill using sudo without a sudo password. But this really shouldn't matter, because the upstart job is supposed to be run as root anyway. So, no sudo should be required at all. I don't understand how running bluepill as a separate, new user will help. Bluepill has to be run as root only, and its recommended by the bluepill authors. There is a --no-privileged option, but it is broken currently. – Anjan Jul 17 '13 at 18:48
I hit enter accidentally before finishing comment. :( From **Remove Password Prompt For sudo**Please do not suggest this to others unless you personally are available 24/7 to support the user if they have issues as a result of running a shell as Root. I would say that there is a slight difference between runing program as root and removing password prompt for sudo. Requirement to remove password is coming from Capistrano script that is controlling unicorn and resque. Using pre-start pre-stop might be better approach. Based on tickets adding expect daemon stanza might be helpful. – Goran Miskovic Jul 18 '13 at 2:38
I am not sure what you are suggesting. Yes, I agree with you that I have removed the sudo password for executing the bluepill wrapper only to make the capistrano recipe work. That's because capistrano scripts are run as the deploy user. But upstart jobs should not need sudo at all, right? Why do I need sudo in an upstart job to run as root when upstart jobs are supposed to be run as root anyway? I know about expect daemon, this whole question has come because that is not working. See here. – Anjan Jul 18 '13 at 17:56
1. Quoted link about expect fork stanza and as far as I can understand bluepill code and quoted bug reports, bluepill runs as a daemon, e.g. expect daemon stanza should be used. Otherwise Upstart will have misleading information and would track wrong PIDs 2. Removing password prompt for sudo has security implications which should be seriously consider in particular in server environment. – Goran Miskovic Jul 18 '13 at 18:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.