I just noticed that session_manager doesn't re-register its suspend delay with powerd when powerd restarts. We don't intentionally restart powerd, but it can happen if the process crashes or is restarted manually.

It shows up like this in powerd's logs:

powerd.20161130-151625: Registering suspend delay 93847555 (session_manager) of 1000 ms on behalf of :1.3
powerd.20161130-151625: Got notification that delay 93847555 (session_manager) is ready for suspend request 93847553 from :1.3
[here's where I restarted powerd]
powerd.20161202-174609: Got notification that delay 93847555 (unknown) is ready for suspend request 438829057 from :1.3
powerd.20161202-174609: Ignoring readiness notification for suspend delay 93847555, which we weren't waiting for
powerd.20161202-174648: Unregistering suspend delay 93847555 (unknown) on behalf of :1.3
powerd.20161202-174648: Ignoring request to remove unknown suspend delay 93847555

The side effect of this is that powerd may not bother waiting for session_manager to freeze ARC before suspending.

I think that the right fix would be by doing something like what Chrome does in chromeos/dbus/power_manager_client.cc:

    power_manager_proxy_->SetNameOwnerChangedCallback(
        base::Bind(&PowerManagerClientImpl::NameOwnerChangedReceived,
                   weak_ptr_factory_.GetWeakPtr()));

When this fires, discard the old suspend delay ID and register a new one.

If you don't have time to work on this, feel free to reassign it to me. It's an edge case but something we ought to handle. (powerd uses its PID as a base when assigning suspend delay IDs, so I don't think we need to worry much about session_manager accidentally responding with a stale ID that now belongs to another process.)