Sign up ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

I'm trying to set up an Upstart job to run on system startup, and that can also be started/stopped by members of a group other than sudo. With a previous version, I usedupdate-rc.d and scripts stored in /etc/init.d/ to get this working by adding %Group ALL = NOPASSWD: /etc/init.d/scriptname to my sudoers file, but I can't seem to get an equivalent working for Upstart.

I tried adding %Group ALL = NOPASSWD: /sbin/initctl start jobname to the sudoers file, but trying to run the command start jobname produces this error:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

As near as I can tell, that's a complaint about how my user account isn't given the power to send 'Start' messages in the D-Bus config file for Upstart. I haven't been able to actually find any information on how to edit that file to give a group permission to access a specific service--does such an option exist? Is there a way to edit the Sudoers file so I can run the job without editing the config file? Am I better off just sticking with the previous version?

share|improve this question

4 Answers 4

You can start with finding out where the D-Bus configuration specific for Upstart is kept. See that destination="com.ubuntu.Upstart" snippet from the error message? Now try to grep it in the folder with D-Bus config files:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />

That Upstart.conf file has some examples of policies. I guess you could try to figure out the format of a policy from them. Then try to allow your specific user just the actions that it needs. For instance, as in:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"

This should permit the pope_benedict user to start that job.

Note that the values for the 'allow' policy attributes are listed in your original error message.

share|improve this answer
Oh, and don't forget to restart D-Bus after this! :) – Iuliu Pascaru Dec 25 '12 at 15:10
I found this a bit bewildering, but this helped:… – Mike Campbell Sep 8 at 8:21

I'm personally using the following line in /etc/sudoers.d/jobname_myuser file:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

as described here:

share|improve this answer

Such option does not exist in sudo.

The difference between Sysv scripts and Upstart configuration files is just that: Sysv scripts are scripts, executables in their own right and you can tell sudo to allow some group to execute them. In the other hand, Upstart configuration files are merely just configuration files, not executables, so the execution of start (symlink to initctl) is the thing sudo allows. Your issue here is that allowing people to run initctl you allow them to initctl everything.

Solution is though simple if your concern in merely a single job. Make a script, say /usr/bin/ with

initctl $1 jobname

then chmod 755 /usr/bin/ and finally add that executable to your sudoers file:

%Group ALL = NOPASSWD: /usr/bin/

This way, everyone can call start or stop to control this specific job. You might want to add some checking to allow only start and stop parameters etc.

share|improve this answer
In other words, my issue isn't that the system denies group members the ability to run initctl, but that Upstart refuses any signals sent by users/groups not explicitly given an Allow policy entry in Upstart.conf? And there's no way to provide any more granularity than an all-jobs-or-none setting in the config file? – Angle O'Saxon Jan 9 '13 at 22:05
Initctl in your case is running fine even without sudoers change, Upstart is just refusing the messages from it if you don't specifically allow it for non-root users. See the other two answers. You can define dbus policy on per-job basis (see the com.ubuntu.Upstart0_6.<JOB> part) in the Upstart.conf. Depending on your needs, it might be simpler to make this kind of script for it instead of writing dbus policies and restarting dbus etc. Dbus policy is obviously the "right" thing to do, but depending on a case, simple script might go a long way with less trouble. – Tuminoid Jan 10 '13 at 6:34
Editing the DBus policy to use com.ubuntu.Upstart0_6.jobname as the send_interface produced the same error message as before. If I'm right in guessing that the error output contains the signal information, it looks interface or destination don't reflect the Upstart service that the signal refers to. I think that the service information is just arguments in the D-Bus method call message, and I'm not sure I can edit the D-Bus policy for Upstart to make decisions based on argument values. – Angle O'Saxon Jan 11 '13 at 1:17
A script of the sort you suggest is working pretty well for me, with one caveat: I've been needing to run it as sudo start, so that Upstart sees the request as coming from the root user.I'm making an effort to try to do this the "right" way (thus the move away from Sys-V scripts in the first place), so I'd like to get this working through a D-Bus policy or some other Upstart configuration option, but if I can't get that working I'll accept this answer. – Angle O'Saxon Jan 11 '13 at 1:23
Yes, you need to call it with sudo. The change in sudoers allows people to call the script as root to fix initctl requirements. If you implement this in production, please add checks for valid $1, or otherwise its huge security hole! At minimal [ "$1" = "start" -o "$1" = "stop" ] && initctl $1 jobname is required. – Tuminoid Jan 11 '13 at 6:30

As pointed above dbus daemon has a configuration file that specializes it for a particular application.

ls /etc/dbus-1/system.d/

The configuration file also establishes resource limits, security parameters, and so forth.

For details see dbus-daemon-1(1) - Linux man page

To allow a group to start/stop Upstart jobs add following policy to /etc/dbus-1/system.d/Upstart.conf

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_type="method_call" send_member="Stop" />

You should consider security implications of such policy before changing default policy. Members of the YourGroupName will be able to start/stop all Upstart jobs.

share|improve this answer
But is there a way to limit the jobs they can control? Or is that not possible because D-Bus doesn't pay attention to message content? – Angle O'Saxon Jan 9 '13 at 21:44
I tried adding that policy to Upstart.conf (replacing the groupname with my actual groupname), restarted D-Bus, and got start: You do not have permission to modify job: jobname when I tried to start the service. – Angle O'Saxon Jan 11 '13 at 0:53
OK. That means that policy is successfully applied. It appears that yourjob.conf is in /etc/init. User jobs should be in ~/.init. Is it plausible in your use case to place yourjob.conf in ~/.init? – schkovich Jan 11 '13 at 12:45
In regards of your first question: Policy defines which interfaces and members can be accessed. It does define which content/arguments can be sent/passed. Current restrictive policy has been eased down upstream. See cannot get upstart to run user job – schkovich Jan 11 '13 at 12:56

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.