Comment 14 for bug 388873

First up, here's a dump of the jobs that you have registered. I've put the names followed by the goal and state in brackets. Then looked at the "cause" and "blocked" parameters, NULL means there wasn't one.

Please shout if any of this system state looks unusual to you:

rc jobs, all stopped:
  rcS (stop/waiting) NULL NULL
  rcS-sulogin (stop/waiting) NULL NULL
  rc0 (stop/waiting) NULL NULL
  rc1 (stop/waiting) NULL NULL
  rc2 (stop/waiting) NULL NULL
  rc3 (stop/waiting) NULL NULL
  rc4 (stop/waiting) NULL NULL
  rc5 (stop/waiting) NULL NULL
  rc6 (stop/waiting) NULL NULL

This is what I'd expect, the system has booted so there's no runlevel change going on right now.

tty jobs, both running:
  tty1 (start/running) NULL NULL
  tty2 (start/running) NULL NULL

Again, what we'd expect.

Now, a bunch of system services, some running, some not:
  autofs (start/running) NULL NULL
  acpid (start/running) NULL NULL
  haldaemon (start/running) NULL NULL
  messagebus (start/running) NULL NULL
  netplugd (start/running) NULL NULL
  prefdm (start/running) NULL NULL
  rsyslog (start/running) NULL NULL

  logd (stop/waiting) NULL NULL
  microcode_ctl (stop/waiting) NULL NULL
  netfs (stop/waiting) NULL NULL
  network (stop/waiting) NULL NULL
  serial (stop/waiting) NULL NULL
  sshd (stop/waiting) NULL NULL
  sulogin (stop/waiting) NULL NULL

Now your custom bits:

some jobs are stopped:
  ezono-cyclades-calibration (stop/waiting) NULL NULL
  ezono-cyclades-pre-start (stop/waiting) NULL NULL

  ezono-cyclades-t_ane (stop/waiting) NULL NULL
  ezono-cyclades-t_ccs (stop/waiting) NULL NULL
  ezono-cyclades-t_emg (stop/waiting) NULL NULL
  ezono-cyclades-t_mco (stop/waiting) NULL NULL
  ezono-cyclades-t_mse (stop/waiting) NULL NULL
  ezono-cyclades-t_par (stop/waiting) NULL NULL
  ezono-cyclades-t_pro (stop/waiting) NULL NULL
  ezono-cyclades-t_ssm (stop/waiting) NULL NULL
  ezono-cyclades-t_upg (stop/waiting) NULL NULL
  ezono-cyclades-t_xss (stop/waiting) NULL NULL

These might be "due to be started", but not yet reached, that's ok - if Upstart hasn't reached them they're not relevant yet.

some are running:
  ezono-cyclades-ac-adapter (start/running) NULL NULL
  ezono-cyclades-list-tasks (start/running) NULL NULL
  ezono-cyclades-stop-software-control (start/running) NULL NULL
  ezono-cyclades-suspend-control (start/running) NULL NULL
  ezono-cyclades-xss-control (start/running) NULL NULL
  ezono-malta-fpga-control (start/running) NULL NULL

  ezono-cyclades-t_bbd (start/running) NULL NULL
  ezono-cyclades-t_cal (start/running) NULL NULL
  ezono-cyclades-t_dso (start/running) NULL NULL
  ezono-cyclades-t_fcl (start/running) NULL NULL
  ezono-cyclades-t_fem (start/running) NULL NULL
  ezono-cyclades-t_emg-control (start/running) NULL NULL
  ezono-cyclades-t_mco-control (start/running) NULL NULL
  ezono-cyclades-t_prd (start/running) NULL NULL
  ezono-cyclades-t_scp (start/running) NULL NULL
  ezono-cyclades-t_smr (start/running) NULL NULL
  ezono-cyclades-t_ssc (start/running) NULL NULL
  ezono-cyclades-t_upg-control (start/running) NULL NULL

These are just running normally, there's no "cause" for them (ie. they're defined as services - I didn't actually verify this, for all of them, but I suspect it's true - if you could make sure that'd be great)

Now we also have some running tasks that retain their start cause:
  ezono-cyclades-gui-start-condition-control (start/running) 0x9a0d9a0 started enzono-cyclades-t_bgr (handling 1) NULL

  ezono-cyclades-t_bgr (start/running) 0x9a0ec98 restart-bgr (handling 1) NULL

  ezono-cyclades-t_wdg (start/running) 0x9a0dc68 stopped ezono-cyclades-pre-start ok (handling 1) NULL

Some jobs are starting up based on the same event:
  ezono-cyclades-t_hal (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL
  ezono-cyclades-t_rvs (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL
  ezono-cyclades-t_scv (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL
  ezono-cyclades-t_spl (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL
  ezono-cyclades-t_svs (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL
  ezono-cyclades-t_upn (start/pre-start) 0x9a0e720 start-ezono-cyclades-gui (handling 6) NULL

Which all looks ok.

And then we have three which are in valid states of starting, but have an invalid pointer for their cause:
  ezono-cyclades-t_fbs (start/pre-start) 0x9a0eb48 INVALID NULL
  ezono-cyclades-t_ime (start/pre-start) 0x9a0eb48 INVALID NULL
  ezono-cyclades-t_ltl (start/spawned) 0x9a0eb48 INVALID NULL
  ezono-cyclades-usb-storage (start/running) 0x9a0eb48 INVALID NULL

It was the third of these (start/spawned) that crashed the daemon, but any of the other two would have crashed it the minute they reached start/spawned.

I find it interesting that the fourth one is in start/running

In the events list we have:
  0x9a0dc68 stopped ezono-cylades-pre-start ok (handling 1)
  0x9a0ec98 restart-bgr (handling 1)
  0x9a0d9a0 started ezono-cylades-t_bgr (handling 1)
  0x9a0e720 start-ezono-cyclades-gui (handling 6)
  0x9aa7e20 started ezono-cyclades-t_prd (pending 0)
  0x9a0eb20 started ezono-cyclades-t_scp (pending 0)

These numbers match up to the others, so other than the mysterious 0x9a0eb48 event, the data has integrity