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.

Evan Carroll
  • 28,578
  • 45
  • 164
  • 290
Phil Filippak
  • 195
  • 1
  • 7
  • 2
    What does the log file report when you run xscreensaver with the `-log` argument and capture stdout and stderrr to a file? https://www.jwz.org/xscreensaver/man1.html – StandardEyre Oct 07 '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 08 '16 at 23:06
  • @grochmal well, I led an experiment: I switched off the touchpad and plugged the mouse out. The behaviour persists. – Phil Filippak Oct 09 '16 at 09:05
  • 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 09 '16 at 17:56
  • @grochmal I tried to track event streams from the basic periphery such as keyboard, mouse, and touchpad and those streams are empty while the password prompt appears. Also, I used `journalctl -p 3 -xb` and got some logs which are now in the post. Googling those logs got me nowhere, except for topics on xscreensaver password misinterpreting. – Phil Filippak Oct 11 '16 at 00:48
  • 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
  • @grochmal now, yes. I checked all of them (details are added to the post) and all of them have nothing. I got a tip on a local forum: it may be a program which uses some kind of a system call to prevent automatic screen blocking. Only I have no idea which program could behave like that. – Phil Filippak Oct 11 '16 at 21:21
  • 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](https://wiki.archlinux.org/index.php/Audit_framework)), then use `xdotool` to find all possible syscalls and seach for them in the logs. – grochmal Oct 11 '16 at 21:57
  • 1
    I have the same problem. Did you found out what was it? Could you please update if you did? thanks. – Esteban Feldman Dec 23 '16 at 05:40
  • Can we have a moderator clean this up and nuke these comments? – Evan Carroll Jun 21 '18 at 01:06

3 Answers3

7

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

Power Manager Applet

Evan Carroll
  • 28,578
  • 45
  • 164
  • 290
kborkows
  • 86
  • 1
  • 2
  • Incredible this is amazing. Problem identified. – Evan Carroll Jun 21 '18 at 00: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 04 '19 at 09: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)

Evan Carroll
  • 28,578
  • 45
  • 164
  • 290
droid guy
  • 41
  • 3
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.

grscheller
  • 21
  • 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