Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 720010 - xfce-base/xfce4-session Xfce screen does not lock
Summary: xfce-base/xfce4-session Xfce screen does not lock
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: XFCE Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-29 12:50 UTC by jorge
Modified: 2020-04-30 12:59 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jorge 2020-04-29 12:50:17 UTC
The screen locking functionality of Xfce is still buggy. On a fresh installation of Xfce on Gentoo, the screen will not -always- lock when the screen is closed. Sometimes it gets locked, and sometimes it displays the error message 

"None of the screen locks ran successfully, the screen will not be locked." 

even if the screen got locked. Other times it just doesn't lock. This happens with the standard shipped configuration: the xfce4-session property "LockCommand" is blank (null string) and systemd is not allowed to handle this request (property login-handle-lid-switch is set to FALSE in xfce4-power-manager). By the way, I am using systemd.

The user can request a software screen-lock with none of the aforementioned problems: the two methods I tested are: 1) clicking the lock screen in the "Actions Buttons" item on panel, and 2) by running xflock4 shell script on /usr/bin/xflock4.

This last option is by running the script as a normal user, not root, otherwise an error occurs: "Failed to init libxfconf: The connection is closed." This leads me to believe that, maybe, the bug is related to the permissions of whatever process is calling the script. Whenever the script is run by software and by an user, the screen always locks with no problems.

Since the bug report https://bugs.gentoo.org/604624 the Xfce environment now comes with with the xscreensaver FLAG enabled, and so it installed by default (or so I believe). No screen lock managers need to be installed in the system. For the record, i tried installing one by one each of alock, slock and xlockmore to test the hypothesis that the problem was with the screensavers, but the same problems persisted as if they were not installed.
Comment 1 jorge 2020-04-30 04:51:37 UTC
What I found out, to the best of my abilities, I hope it helps:

After some more testing, the error message only appears after the laptop is unlocked and when the unlocked state came from closing the lid. If the screen locks via the manual running of xflock4 or by "locking the screen" in the panel (as described before), the error message does not appear after the laptop gets unlocked. A curious behavior: the error message is not displayed immediately afterwards the unlocking, rather like 10 seconds after.

From what I've investigated, the error comes from the program built from the file  xfpm-manager.c a source file from the power manager app. The offending lines are (453-458):

if (!xfce_screensaver_lock (manager->priv->screensaver))
{
    xfce_dialog_show_error (NULL, NULL,
			    _("None of the screen lock tools ran "
			      "successfully, the screen will not "
			      "be locked."));
}

as you can see, this is executed only if the xfce_screensaver_lock method returns FALSE. This method is found on the source file xfce-screensaver.c (also of the power manager app). The important lines (501-525):

switch (saver->priv->screensaver_type) {
    case SCREENSAVER_TYPE_FREEDESKTOP:
    case SCREENSAVER_TYPE_MATE:
    case SCREENSAVER_TYPE_GNOME:
    case SCREENSAVER_TYPE_XFCE:
    {
        GVariant *response = NULL;
        response = g_dbus_proxy_call_sync (saver->priv->proxy,
                                           "Lock",
                                           g_variant_new ("()"),
                                           G_DBUS_CALL_FLAGS_NONE,
                                           -1,
                                           NULL,
                                           NULL);
        if (response != NULL)
        {
            g_variant_unref (response);
            return TRUE;
        }
        else
        {
            return FALSE;
        }
        break;
   }

in my case I'm using the default xfce4-screensaver, so the case statement must have landed there. If this method is returning FALSE, it means that the response was NULL. This means that the call g_dbus_proxy_call_sync somehow always return NULL in my system. An odd thing is that the variable saver->priv->proxy is not declared in this method, so maybe the problem lies around there.

Well that's the best of my current abilities. Hope it helps.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-04-30 08:31:18 UTC
Could you report your findings upstream (https://bugzilla.xfce.org)?  Alternatively, I could proxy it for you but I think it'd be easier if you talked ot them directly ;-).
Comment 3 jorge 2020-04-30 12:59:46 UTC
Of course! https://bugzilla.xfce.org/show_bug.cgi?id=16782