Comment 35 for bug 1623853

> Can repowerd simply hold a lock until the screen dbus service is connected?

(I am assuming you are referring to a display-on lock, which also disallows suspends).

repowerd could hold a lock, but, IMO:

1. repowerd is the wrong place to put this logic. repowerd shouldn't have to know, even implicitly, about the boot time dependencies. As an example of why this is fragile, if we decide to move USC before or in parallel with apparmor reprofiling (which I suggest we do), this logic will stop having the desired effect. It would be much better to use a suspend block during the whole boot process (repowerd started -> unity8 started) using the init system facilities, as described in comment #31.

2. this lock by itself would only improve the user experience very slightly, since it would brighten the backlight but the screen would still remain black and unresponsive to power keys for some time until USC starts.

I think the best solution from a UX and cleanliness perspective would be:

1. Start USC before or in parallel with apparmor reprofiling, so the user gets some visual indication that the system is working and can at least turn the screen on/off. This is optional, but I think improves UX a lot.
2. Acquire a suspend blocker (using an init job) when repowerd starts, release when unity8 (not USC) has started or failed to start.

I'll try to find a way to recreate the "profiles need recompilation" scenario without flashing a new image, so we can test easily. I will provide a prototype for the proposed solution for people to try out.