Don't think this is a bug in indicator-session. Basically indicator-session is just calling two dbus methods on org.gnome.ScreenSaver; Lock and SimulateUserActivity. It seems that the SimulateUserActivity call is not returning immediately. I can illustrate this with a simple script:
which when run, locks the screen and then shows the lock screen immediately. When you unlock the screen, the script will still be blocked until the timeout is reached, where we get:
method return sender=:1.79 -> dest=:1.103 reply_serial=2
Error org.freedesktop.DBus.Error.NoReply: 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.
The first line is from the successful call to Lock. The call to SimulateUserActivity is also successful since the lock screen appears immediately, but we never get a reply.
A decent workaround might be to set the timeout to some low value, say 1 second. It seems to work when setting --reply-timeout=1 in the script, I'm going to try rebuilding indicator-session with that value and see if it helps (though I am curious why we never get a reply).
Don't think this is a bug in indicator-session. Basically indicator-session is just calling two dbus methods on org.gnome. ScreenSaver; Lock and SimulateUserAct ivity. It seems that the SimulateUserAct ivity call is not returning immediately. I can illustrate this with a simple script:
#!/bin/bash
dbus-send --session --print-reply --dest= org.gnome. ScreenSaver \ gnome/ScreenSav er org.gnome. ScreenSaver. Lock org.gnome. ScreenSaver \ gnome/ScreenSav er org.gnome. ScreenSaver. SimulateUserAct ivity
/org/
dbus-send --session --print-reply --dest=
/org/
which when run, locks the screen and then shows the lock screen immediately. When you unlock the screen, the script will still be blocked until the timeout is reached, where we get:
method return sender=:1.79 -> dest=:1.103 reply_serial=2 .DBus.Error. NoReply: 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.
Error org.freedesktop
The first line is from the successful call to Lock. The call to SimulateUserAct ivity is also successful since the lock screen appears immediately, but we never get a reply.
A decent workaround might be to set the timeout to some low value, say 1 second. It seems to work when setting --reply-timeout=1 in the script, I'm going to try rebuilding indicator-session with that value and see if it helps (though I am curious why we never get a reply).