8

If you only experience this problem when using VLC see this question

When the screen is blocked, the xscreensaver (version 5.35) password prompt pops out without any mouse/touchpad movement. It just appears, blinks out when the time is gone (there is also a message like "the PAM timeout is cancelled") and appears again. Then the cycle is repeated.

I tried to reinstall it which was not helpful. I'm using Arch (4.7.6-1-ARCH) on a laptop.

Here are the log messages (I removed xscreensaver: in the beginning of all lines). The event I did not trigger is ClientMessage at 10:48:47:

10:48:29: 0: grabbing keyboard on 0xd4... AlreadyGrabbed.
10:48:30: 0: grabbing keyboard on 0xd4... GrabSuccess.
10:48:30: 0: grabbing mouse on 0xd4... GrabSuccess.
10:48:47: DEACTIVATE ClientMessage received.
10:48:47: user is active (ClientMessage)
10:48:47: pam_start ("xscreensaver", "xenohunter", ...) ==> 0 (Success)
10:48:47:   pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)
10:48:47:   pam_authenticate (...) ...
10:48:47:     pam_conversation (ECHO_OFF="Password: ") ...
10:48:47: 0: mouse is at 1047,514.
10:48:47: 0: creating password dialog ("")
10:48:47: grabbing server...
10:48:47: 0: ungrabbing mouse (was 0xd4).
10:48:47: 0: grabbing mouse on 0x140003c... GrabSuccess.
10:48:47: ungrabbing server.
10:49:17: input timed out.
10:49:17:     pam_conversation (...) ==> PAM_CONV_ERR
10:49:17:   pam_authenticate (...) ==> 20 (Authentication token manipulation error)
10:49:17: pam_end (...) ==> 0 (Success)
10:49:17: authentication via PAM timed out.
10:49:17: grabbing server...
10:49:17: 0: ungrabbing mouse (was 0x140003c).
10:49:17: 0: grabbing mouse on 0xd4... GrabSuccess.
10:49:17: ungrabbing server.
10:49:17: 0: moving mouse back to 1047,514.
10:49:17: discarding MotionNotify event.
10:49:17: 0: destroying password dialog.

UPD 2016-10-11

I printed journalctl -p 3 -xb and got tons of such lines:

Oct 08 14:02:57 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): conversation failed
Oct 08 14:02:57 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): auth could not identify password for [xenohunter]
Oct 08 14:03:37 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): conversation failed
Oct 08 14:03:37 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): auth could not identify password for [xenohunter]
Oct 08 14:04:17 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): conversation failed
Oct 08 14:04:17 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): auth could not identify password for [xenohunter]
Oct 08 14:04:57 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): conversation failed
Oct 08 14:04:57 regulus xscreensaver[12913]: pam_unix(xscreensaver:auth): auth could not identify password for [xenohunter]

The cycle is always 40 seconds which is likely to be the time the password prompt reappears.

I did evtest /dev/input/event${X} where ${X} is every id from xinput list. Plus, I did the same for event streams with id=0 and id=1 which are physical mouse and keyboard. All those streams are empty when the password prompt appears.

10
  • 2
    What does the log file report when you run xscreensaver with the -log argument and capture stdout and stderrr to a file? jwz.org/xscreensaver/man1.html – StandardEyre Oct 7 '16 at 23:06
  • 1
    How do you know you did not trigger it? (That actually is a tough question). Maybe it is as simple as a truck was passing close by? For example, an optical mouse will react to the vibrations of a truck. My arch does that all the time if I sit on a desk where enough vibrations from the street nearby happen. – grochmal Oct 8 '16 at 23:06
  • 1
    Hmm... you have a process that must be hitting some input IRQ. Some ioctls may do it. One way to check whether any input event occur is to use evtest (it is a package in Arch). For every event file in /dev/input you can do evtest /dev/input/event0 > /root/log.0 (as root) and then wait for the problem. evtest produces timestamps which you can then compare. This will give you a hint whether it is the keyboard (normally event0), mice (normally event1) or something else (every event file is described by evtest). – grochmal Oct 9 '16 at 17:56
  • 1
    Did you check every /dev/input*, i'm insisting on that because xscreensaver will look at (almost) every input device. It could be as stupid as an unmutted microphone. xscreensaver should pool every device in the list provided by xinput list – grochmal Oct 11 '16 at 13:48
  • 1
    That's a good point. But, since you are on arch the process should not be hard to find. You have the easy way: try all session programs (e.g. use a simple window manager for a time) and then try all systemd daemons one by one. Or the hard way: enable auditd to log all system calls (this requires some config), then use xdotool to find all possible syscalls and seach for them in the logs. – grochmal Oct 11 '16 at 21:57
7

I know this is an old thread but disabling Presentation mode in xfce4-power-manager applet fixed this

Power Manager Applet

2
  • Incredible this is amazing. Problem identified. – Evan Carroll Jun 21 '18 at 0:59
  • 1
    The problem has resolved itself because of the reinstalled Arch, and the fact that xfce4 has now a good built-in screensaver (so, no xscreensaver anymore). Though as far as I can tell, this answer is the most relevant to the actual solution. – Phil Filippak Dec 4 '19 at 9:58
3

Since I am new I am unable to add a comment and ask you if you are using XFCE4. I had this same exact problem and tracked the problem to xfce4-power-manager causing this exact same issue.

Taken from the Xscreensaver FAQ:

Starting in early 2016, I began receiving reports that a program called xfce4-power-manager occasionally loses its mind and decides that it's very important that your screen never, ever blank, and it does this by simulating fake KeyPress events hither and yon. I don't know why. Your best bet would be to kill and/or uninstall that program.

Killing xfce4-power-manager solved my issue that you were having but I have a second issue of DPMS not working which you can see here: DPMS Stopped Working Arch (nvidia drivers - xfce4)

3
  • Yes, I use xfce4. My bad I didn't mention it. I'll check power manager ASAP. – Phil Filippak Dec 16 '16 at 6:47
  • @PhilFilippak Any update on whether this fixed it for you? – Sparhawk Nov 11 '17 at 9:37
  • Having same issue as reporter (screensaver wouldn't start, and when I force started it, auth dialog would pop up every 40 seconds) and this solved it for me. – phemmer Nov 24 '17 at 22:10
1

I had same problem on Arch Linux 4.14.15-1 using XFCE on a laptop. I went into the Settings editor and reset all the xfce4-power-man settings to their default values. Problem went away.

1
  • 1
    I suspect you got downvoted because there's no context as to which exact setting caused it or if this only peripherally helped resolve the issue. This helped me. One of the other answers implies also that you should kill/stop xfce4-power-manager ; but simply removing all the config (as you suggested) achieves the same. – zaTricky Aug 24 '20 at 15:31

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.