[split] Impossible to place snap decisions on greeter while screen is unlocked

[Tiago Salem Herrmann]

With the current greeter implementation we have a full telephony stack running as lightdm.
When an incoming call arrives the telephony-service-approver daemons try to place a snap decision either on greeter and unity8.

Everything works fine when the screen is locked (greeter displayed), but if the screen is unlocked, the approver gets stuck while calling notify_notification_show() until the screen is locked again.

notify_notification_show() has a timeout, so it fails to display the snap decision in a minute or so (which means receiving a call and not activating the greeter so it can process the snap decision).
If you run the approver manually you will get the following messages:

---------
Failed to show snap decision: Timeout was reached
Failed to get user property "IncomingCallSound" from AccountsService: "Object path cannot be empty"
Failed to get active entry from Unity Greeter: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
--------

In such case, the approver gives up on trying to show the snap decision, but in most of times, if you lock the screen to see the greeter, a snap decision is there, but the call does not exist anymore.

Steps to reproduce:
1) install dialer-app-autopilot
2) reboot your device (to get ofono-phonesim running)
3) sometimes the modem is not online, so run this command just to make sure (/usr/share/ofono/scripts/online-modem)
4) run this command with the phone locked to check if the greeter is showing snap decisions: /usr/share/ofono/scripts/dial-number 199
5) unlock the phone, repeat the previous step and let it ring until the incoming call snap decision go away.
6) wait for 30 seconds more before you lock the screen again.
7) the previous notification will be incorrectly shown on the greeter.

These steps are not 100% reproducible, sometimes you get the wrong notification, and sometimes it triggers another bug that no notifications will be displayed anymore on the greeter, not even if you restart the approver.

[Michał Sawicz (saviq)]

Is this not the same as bug #1325702?

[Michał Sawicz (saviq)]

Adding a unity-notifications task, as it might be involved in whatever solution we come up with.

[Michael Terry (mterry)]

This is different than the queued snap decision bug apparently. I'm looking at it.

[Michael Terry (mterry)]

So quick brain dump. This is due to the unity8-greeter process being SIGSTOPPED while not active, seemingly due to Mir lifecycles. While sleeping, the snap decision Notify call apparently gets "stuck" in the dbus pipe and still delivered afterward, even if the source of the notification does a close() on it.

But the unity8 shell does *not* get SIGSTOPPED when inactive. And for that matter, unity8-greeter doesn't always have this problem either, which is why this bug isn't 100% reproducable.

So some piece of logic is keeping the unity8 shell active. The greeter should probably do the same thing.

Alternately, we could figure out why the Notify call is stuck in the dbus socket and stop that from happening. But the above is also useful.

[Michał Sawicz (saviq)]

On 09.06.2014 22:08, Michael Terry wrote:
> So quick brain dump. This is due to the unity8-greeter process being
> SIGSTOPPED while not active, seemingly due to Mir lifecycles. While
> sleeping, the snap decision Notify call apparently gets "stuck" in the
> dbus pipe and still delivered afterward, even if the source of the
> notification does a close() on it.

Huh!? Are you sure it gets stopped? There's nothing that you can
describe "Mir lifecycle"... It's unity-mir that handles lifecycle. The
only thing that *could* happen, but shouldn't any more, would be blocked
rendering when greeter inactive, causing events to be queued (but
non-blocking eglSwapBuffers handled exactly that). We just need to make
sure the correct expose events are delivered to unity8 and
unity8-greeter, as applicable.

[Michael Terry (mterry)]

True, it may not be SIGSTOPPED, but just blocked on render. I'm basing my guess on a test I ran where I disabled the lifecycle code in USC and it started working again. But maybe that was coincidence. Or maybe that was related to render blocking instead of SIGSTOP.

I'm still investigating

[Michael Terry (mterry)]

OK, got it in a state and tested via "ps aux" whether it was actually SIGSTOPped and seems like no. So I'm guessing some sort of render block... non-blocking mode was supposed to fix that, but perhaps in conjunction with Mir lifecycles, something still blocks inactive sessions.It only

[Michał Sawicz (saviq)]

On 10.06.2014 18:54, Michael Terry wrote:
> OK, got it in a state and tested via "ps aux" whether it was actually
> SIGSTOPped and seems like no. So I'm guessing some sort of render
> block... non-blocking mode was supposed to fix that, but perhaps in
> conjunction with Mir lifecycles, something still blocks inactive
> sessions.It only

It only...?

In any case, I'm not aware of anything that could be dubbed "Mir
lifecycles"... Blocked rendering would be the only thing I could explain
this with.

[Michael Terry (mterry)]

I'm not sure what the "It only" fragment was supposed to be. :)

Sure, you know Mir lifecycles. The "about_to_suspend" and "resume" lifecycle events that a mirserver sends to its mirclients. Usually used between unity8 and apps, but also technically used between USC and child sessions.