5

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

3 Answers 3

3

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/screen_lock@.service

[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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.