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

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

For some reason I'm getting an error during apport upgrades, the cause of which is

% sudo service apport start
start: Job failed to start

Under sysvinit, I could debug this kind of problem by running eg

sudo sh -x /etc/init.d/whatever start

but that doesn't seem to map over to upstart. What should I try next?

update: it turns out there is a workaround that will let the install proceed. But I'm still interested in the general question of how you would trace the script.

share|improve this question
I'm working on a more thorough reply, but thanks for the link to the workaround, same thing happened to me updating natty today! – Mark Russell Apr 21 '11 at 0:38
Haha, and they released the fix 12 minutes ago. Isn't running Beta fun? (no really!) – Mark Russell Apr 21 '11 at 0:55
+Muhammad posted the correct answer below. – Travis R Feb 5 '14 at 19:06
up vote 24 down vote accepted

All of the following information (and quite a lot more useful Upstart help) is from The Upstart Cookbook. Section 13 covers debugging.

In this specific case of tracing a "script" stanza of an Upstart job you should add the following lines right below the word "script":

exec 2>>/dev/.initramfs/myjob.log
set -x

The reason for the odd location is that /dev/.initramfs/ is available in very early boot, before the root file system has been loaded, and continues to be available after boot. I'm guessing with apport, however, you probably don't need to use that path. Still, it's nice to know the option.

It should also be noted that all scripts are run with set -e so any command that fails will exit the script entirely. Which makes sense, as one should be very careful when running scripts as root.

I highly recommend consulting the Upstart Cookbook linked above in general for anyone working with Upstart jobs.

share|improve this answer
Thanks for that, if I hadn't seen the bug was resolved, I probably would have modified the script to turn on set -x as you suggest. I was mostly wondering if there was any cleaner way to do it. – poolie Apr 21 '11 at 0:55
Yeah, not that I know of (and if it's not in the cookbook, that means there probably just isn't). Aside from that idea, most of the debugging techniques mentioned are more about troubleshooting Upstart and Upstart events themselves, which is where I usually find myself. :) – Mark Russell Apr 21 '11 at 1:02
And yet this method will fail if setuid and setgid are used in jobs. – 0xC0000022L Jul 27 '15 at 7:27

Upstart logs your service execution in a log file by the same name in /var/log/upstart/your-service-name.log. It should be helpful.

share|improve this answer
Right, it looks like this includes the stderr of the jobs, so if I turned on set -x it would probably show up there. – poolie Sep 3 '12 at 1:34
I put in an echo based log statement in my /etc/init.d/Xservice script but it doesn't show up in this location! OS: Ubuntu 14.04 Trusty – Champ Aug 6 '15 at 20:39
Why not to syslog? May I suggest a general feature, maybe rsyslog itself, that upstart and any component would use to write to syslog if it's not available, or to a temporary place that would be transfered to syslog asap. It took me half a day to find this. Please forward this remark TIA. – Papou Jan 9 at 18:07

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.