Running XFCE on Xubuntu 13.04 and noticed that suspend + lock screen doesn't always work as expected. When I'm suspending the system and the option "Lock screen when going for suspend/hibernate" is used, the system seeems to suspend normally. However, when waking up the system yet again, I see a short glance of the desktop that was on when suspending. Only after that I get the lock screen password prompt. This happens randomly, not always.
Running 'xflock4 && xfce4-session-logout -s' is a workaround
Downstream report: https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1054299
The caller of xflock4 should wait until xflock4 exits, i.e. not run xflock4 in background.
This is an issue with xfce4-power-manager, as well.
Please, see https://bugzilla.xfce.org/show_bug.cgi?id=6413
Especially comments 1 and 2.
Please note that even the workaround given in Comment 1 does not work in principle, if xflock4 uses one of the lockers that start in background. Those include xlock, slock, slimlock or any locker configured with xautolock, when considering the proposed xflock4:
(featured within https://bugzilla.xfce.org/show_bug.cgi?id=10217)
(In reply to siukola.antti from comment #1)
> Running 'xflock4 && xfce4-session-logout -s' is a workaround
Yes, if xflock4 uses xscreensaver, but if it uses light-locker, the script doesn't work according to my experience in Ubuntu Studio 14.04: the logout command requests password in background.
(In reply to siukola.antti from comment #0)
> Running XFCE on Xubuntu 13.04 and noticed that suspend + lock screen doesn't
> always work as expected. When I'm suspending the system and the option "Lock
> screen when going for suspend/hibernate" is used, the system seeems to
> suspend normally. However, when waking up the system yet again, I see a
> short glance of the desktop that was on when suspending. Only after that I
> get the lock screen password prompt. This happens randomly, not always.
If I have understood correctly, xfce4-session nowadays waits until xflock4 finishes, before it suspends. The problem was especially with xscreensaver, since it can be configured to fade screen given time and it may slow anyway . However, since current xflock4 runs 'xscreensaver-command -lock' in foreground, it waits until the fading is complete.
I have to take words back. In Xubuntu 16.04 and 18.04 system does not wait until xflock4 finishes before suspending, so the bug seems to be present in Xfce 4.12
The bug is in xfce4-session/xfce-screensaver.c (and in xfce4-session/xfsm-systemd.c before git commit 9fa8c63b4377bcb46b8471da509ff8bd909c4bf0).
A locker should be called syncronously, not by g_spawn_command_line_async (), but by g_spawn_command_line_sync () or directly by g_spawn_sync(), and the provided exit_status should be taken into account.
I.e. something like this:
g_spawn_command_line_sync ("xflock4", NULL, NULL, exit_status, NULL);
if (exit_status != NULL && *exit_status == 0) return TRUE;
I have provided a patch for xfce4-session 4.12.1 at https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1054299/comments/39
However, when the patch is applied, there is some issue with error handling. Besides, Xubuntu 18.04 does not have pm-utils installed (and thus pm-suspend does not work): https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1054299/comments/47
So could g_spawn_command_line_sync be used in case of SCREENSAVER_TYPE_OTHER in xfce_screensaver_lock?
So I wrote a patch for 4.14.  I have not tested it, as I don't know how to start my xfce4-session. startxfce4 should maybe have some configuration options to point it to another xfce4-session.
Note: maybe the 2 second wait here can be removed now. I don't know, when this lock_screen() function is called, though.
Created attachment 9607
Not really tested.
Created attachment 9608
Ok, so I tested the 4.14 patch by suspending once. My xscreensaver dimmed the screen until it was completely black and than the pc suspended.
That sounds great! I which that fix could be released soon and even backported.
-- GitLab Migration Automatic Message --
This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-session/-/issues/15.
Please create an account or use an existing account on one of our supported OAuth providers.
If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests
Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev