Comment 5 for bug 1412719

The second part of the patch proposed to upstart's wait-for-state job is reasonable, but has nothing to do with the behavior shown here. And the first part of the patch is wrong. It's not appropriate to change the default wait-for-state behavior that other packages are relying on.

/etc/init/whoopsie.conf has:

    status network-manager >/dev/null 2>&1 && start wait-for-state WAITER=whoopsie WAIT_FOR=network-manager GOAL=start || :

- 'GOAL' is incorrect; the variable name is 'TARGET_GOAL', but start is the default so this is a cosmetic issue.
- because network-manager runs a service, WAIT_STATE=running needs to be specified here.
- changing any of this will not cause whoopsie to stop respawning. All of the wait-for-state handling happens in a *pre-start* script which has been written to ignore any failure from wait-for-state. The logs in this bug clearly show that there is a main process which is exiting.

[14103.317598] init: whoopsie main process ended, respawning

This means that whoopsie itself is exiting for some reason and then being respawned. wait-for-state is in no way causing whoopsie to be restarted; the only thing wait-for-state is doing is causing enough of a delay in the pre-start that the respawn limit is never hit, causing this to loop indefinitely. But the real issue is whatever is causing whoopsie to exit in the first place.