@Steve: I think I understand what happens. On package upgrade, if the job is disabled, then, there is an upstart .override file written to disable it and so, that behavior shouldn't be triggered. I guess this case happens currently if you disable through ubuntu-control-center after a new installation as I discovered that there is another library (another source package), using that file: whoopsie-preferences that can read/set values in this file.
However, I see that there is another value about report_metrics that we don't use for job enablement status. I propose to do the following on ubuntu-control-center: report crashes -> add the override and call systemctl disable if installed, change whoopsie-preferences to be aware of those files and detect usptart/systemd for current values. This should prevent whoopsie to loop when the job is disabled and only have the current enablement state in one place (through libwhoopsie- preferences). I can set the other changes that you described as well to fix the upstart job, just following what you see as I'm in no way an upstart expert :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1412719 Title: wait-for-state restarts whoopsie every 30sec To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1412719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
