7

I user lightdm and xfce on my laptop. It's a new installation. Every time the screen turns off from inactivity (or close the lid), I would see the lightdm login screen. However, after I log in, and after a few seconds, a window simply titled "Error" would pop up.

I would see the error too if I close the lid, unlock, then close the lid again in a few seconds. I don't even know where the error came from.

The error message "None of the screen lock tools ran successfully, the screen will not be locked"

2
  • 1
    I'm getting the same error message, also using arch linux and xfce. It's been happening the past two weeks or so. I wonder if it's a recently introduced package bug.
    – Trevor Jex
    Mar 31, 2020 at 6:20
  • ls -ltr /var/log/ should list some useful logs to paste the tail from. May 19, 2020 at 10:34

4 Answers 4

5

I don't use ArchLinux specifically but the problem keeps on appearing on different distros running XFCE DE due to possibly different reasons (not clearly known to me at the moment). Recently it appeared in Ubuntu when I installed Clight. With Clight disabled, locking works fine.

By default xfce4-power-manager does not log any helpful output to syslog or .xsession-errors. In order to troubleshoot the problem, kill the auto-started daemon and start in foreground in debugging mode:

~$ xfce4-power-manager --quit
~$ xfce4-power-manager --no-daemon --debug

The following message appears when xfce_screensaver_lock is called from xfpm_power_sleep or xfpm_manager_lid_changed_cb and returns failure:

None of the screen lock tools ran successfully, the screen will not be locked. Do you still want to continue to suspend the system?

So look into your screensaver, xfconf-query -c xfce4-session -p /general/LockCommand setting, and commands: xflock4, xdg-screensaver, xscreensaver-command etc.

However a simple solution is to not use XFCE Power Manager's Lock screen when system is going to sleep setting at all. Define a systemd service to run lock command before going to sleep and/or hibernate. An additional benefit is that this would lock the screen even if you suspend the system from commandline.

# /etc/systemd/system/[email protected]

[Unit]
Description=Autolock screen before sleep, hibernate and hybrid-sleep
Before=sleep.target hibernate.target hybrid-sleep.target

[Service]
User=%i                       # may also hardcode username here
Type=forking
Environment=DISPLAY=:0        # replace this with your $DISPLAY value
ExecStart=/usr/bin/xtrlock    # use whatever lock command
ExecStartPost=/bin/sleep 1

[Install]
WantedBy=sleep.target hibernate.target hybrid-sleep.target

Enable the service:

~$ sudo systemctl enable screen_lock@<username>.service
0

Got hit by this as well on some but not all of my Debian Buster installations (xfce4-power-manager v1.6.1-1). Did not dig deeper, but 'fixed' it by changing the source-code to always call xflock4: In xfce-screensaver.c modify function xfce_screensaver_lock so it looks like:

gboolean
xfce_screensaver_lock (XfceScreenSaver *saver)
{
  /* maybe better use whole code of SCREENSAVER_TYPE_OTHER... */
  g_spawn_command_line_async ("xflock4", NULL);
  return TRUE;
}

I'm using mate-screensaver (yep, in xfce) and suspect that for some reason the g_dbus_proxy_call_sync in case SCREENSAVER_TYPE_MATE fails...

0

In my case the issue was the presence of the cinnamon-screensaver DBus service files, even though it wasn't running. I found that out by running dbus-monitor --session | grep -v '^ ' to see messages on DBus when I tried to suspend, and saw Lock commands being sent to org.cinnamon.ScreenSaver even though I don't use cinnamon-screensaver -- that seemed suspicious. I also saw an error message like Type of message, "(yb)", does not match expected type "(b)" when using another suspend path (through keyboard shortcut / xfce4-session).

Since I'm not using Cinnamon, my workaround was just to uninstall cinnamon-screensaver to remove the DBus configuration files that confused XFCE:

$ sudo apt purge cinnamon-screensaver
$ grep -r org.cinnamon.ScreenSaver /usr/share/dbus-1/
  # should not find any matches
# now re-login to make sure the session-wide DBus picks up the change
0

The issues is also addressed here: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/142

According to the referenced issue the problem might be caused due to the D-Bus interface org.freedesktop.ScreenSaver not having a method called Lock.

Sebastian @giwiniswut summerizes the issue as follows:

  • If locking the screen via the D-Bus interface fails the xfce4-power-manager doesn't try to fall back to the user-specified
    command line. [...]
  • The xfce4-power-manager has support for a number of specific screensaver D-Bus interfaces but prioritises
    org.freedesktop.ScreenSaver over most of them. Screensavers which
    provide this interface without exposing all of their methods there as well won't work properly. This currently affects the Cinnamon and
    GNOME screensavers but presumable the MATE screensaver as well. There is currently no proposed patch that changes this behavior.

In my case this also affects xscreensaver.

I created an AUR package for Arch Linux which uses the patch suggested by @maratbn in the linked issue:

https://aur.archlinux.org/packages/xfce4-power-manager-git-xsccomp

This solves the problem for me.

The patch seems to be only a temporary solution. It makes xfce4-power-manager handle the SCREENSAVER_TYPE_FREEDESKTOP case the same as SCREENSAVER_TYPE_OTHER and thereby invoking the xfconf LockCommand

EDIT: Unfortunately this seems not to work reliably. On my system after the a resume from suspend. xfce4-power-manager spawns endless xflock4 processes.

EDIT2: For me it works fine when setting the xfce4-session/general/LockCommand in xfconf to

xscreensaver-command -lock
2
  • Welcome to SuperUser! Please do not post link only answers as the linked site might change, rendering your answer useless. Instead quote the most important parts from the linked sites and provide the links for reference only. Jan 31, 2023 at 21:56
  • @DarkDiamond Thanks for the hint. I added some more detailed information.
    – heleon
    Feb 2, 2023 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .