Comment 31 for bug 1623853

> can you compare what powerd used to do with what repowerd is doing now in this scenario

Based on jibel's theory from comment #23:

With powerd the timeout logic was in USC, so if USC hasn't started (e.g. because of apparmor recompilation in this case?) the device won't suspend.

With repowerd all the timeout logic is in repowerd itself; USC is used only as a source of events (e.g. power button, touches). In this case, since repowerd doesn't get any requests to disallow suspending, it correctly suspends after the normal timeout.

I think a sensible solution would be to disallow suspending until at least USC (and possibly unity8) is up and running. This could be achieved by acquiring and releasing a suspend blocker from repowerd at the init system level, with a prohibit_suspend_at_boot upstart/systemd job: on "repowerd started" acquire a suspend blocker, on "usc/unity8 started" release the blocker.

Even without the suspend issue, the initial delay after first boot due to apparmor recompilation or whatnot does not provide a good experience, since there is no visual indication that something is going on for a significant amount of time. This brings up the following questions:

0. Why do we need to recompile the profiles at first boot?
1. Could we start USC before the recompilation and other time consuming tasks start, so at least the user would be able to see the dots animating (and incidentally this would also solve the suspend issue)?