Bug 984333

I don't see this issue on baremetal. You're are running MATE in a VM?

No, I'm seeing this baremetal on a Thinkpad X230.

Did the issue still exits with mate-screensaver-1.6.1-2.fc19 ?

Yes.  Hit it just a minute ago.

voom:~$ rpm -q mate-screensaver
mate-screensaver-1.6.1-2.fc19.x86_64

May be related to the fact I have an unusual windowmanager (xmonad).

(In reply to David Gibson from comment #4)
> Yes.  Hit it just a minute ago.
> 
> voom:~$ rpm -q mate-screensaver
> mate-screensaver-1.6.1-2.fc19.x86_64
> 
> May be related to the fact I have an unusual windowmanager (xmonad).

Is there a reason for using xmonad?
Can you test if the issue exits if you use normal mate-window-manager (marco) in mate?

Well, because I'm far more productive with xmonad.  I'll see what I can do about testing with marco - since the problem doesn't hit every time, it will be a bit awkward.

any news?

No, haven't had a chance to test with marco.  I still hit the bug multiple times every day.

Maybe this update helps.
https://admin.fedoraproject.org/updates/mate-screensaver-1.6.1-3.fc19?_csrf_token=66b637a6fc54773853b4aedc2fd0093b54ec534c

Alas, it does not.

How often does it happen?  (eg how many times out of 10 say?
and what kind of timeframe?)

Can it be reproduced by manually locking the screen?

(In reply to David Gibson from comment #0)
> Suspect this may be related to some other windows on the locked desktop
> which attempt to grab all focus (e.g. VM console from virt-manager) but I
> don't have confirmation or a clear reproducer yet.

Does killing virt-manager say instead of mate-screensaver help?

I just got a chance to try, and no it doesn't help.  I'm actually pretty sure I've hit this problem without virt-manager running anyway, so I no longer think that's a good theory.  However I think it may have something to do with workrave.  I'll try killing that instead of the screensaver when it next happens.

I haven't been able to reproduce by manually locking the screen.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I've seen this at least once in Fedora 21.  Updating version.

mate-screensaver-1.8.1-1.fc21.x86_64

(In reply to David Gibson from comment #15)
> I've seen this at least once in Fedora 21.  Updating version.
> 
> mate-screensaver-1.8.1-1.fc21.x86_64

Is this still a problem with mate-screensaver-1.10.x

Yes, I'm still seeing this quite often with Fedora 22 and mate-screensaver-1.10.2-1.fc22.x86_64.  I'd say it happens maybe 60-70% of the times the screensaver activates.

I forward it to upstream
https://github.com/mate-desktop/mate-screensaver/issues/82
Can you please comment there for getting notification if upstream has a question?

Btw. How can i install xnomad session to reproduce it?

I believe you can install the xmonad-mate package (I currently have xmonad-mate-0.11-13.fc22.x86_64 installed), then select the xmonad/mate session from the gdm menu.

I'll attach by xmonad.hs config file, although I don't know if that is relevant.

Created attachment 1078092 [details]
xmonad config file

Installing xmonad isn't user friendly.
Why are the 2 needed yum/dnf groups in comps unvisible?
Anyways, it runs in a f21 VM now.
But i couldn't reproduce the issue until yet.
So, some more questions: 
Does it only happens if the session is looked?
Do i need to wait longer, ie 2 hours or 6 hours, before i try to unlock the session?
Does it happens when the box boot from hibernate/suspend state?

I tested it also on bare metal several times, no luck.
Which graphic are you using?
I tested it with nvidia driver from rpmfusion.
But sorry, i can't use xmonad on my main box whole the day for testing more ;)
But it seems you're not alone, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785739

PS: you can try out latest mate-screensaver build which have improvements for systemd-login.
https://bodhi.fedoraproject.org/updates/FEDORA-2015-5b345be5b9

> Installing xmonad isn't user friendly.
> Why are the 2 needed yum/dnf groups in comps unvisible?

I can't answer that.

> Anyways, it runs in a f21 VM now.

Ok, as noted above, I'm still seeing the problem with f22.

> But i couldn't reproduce the issue until yet.
> So, some more questions: 
> Does it only happens if the session is looked?

Sorry, I don't understand that question.

> Do i need to wait longer, ie 2 hours or 6 hours, before i try to unlock the session?

No, I've rarely left the session locked that long, and I've frequently hit the problem when it has only been locked for seconds.

> Does it happens when the box boot from hibernate/suspend state?

When I resume from suspend-to-ram, I think the problem has sometimes happened, but certainly not more frequently than any other time.

I'm not regularly using hibernate at the moment, so I don't know about that.

> I tested it also on bare metal several times, no luck.
> Which graphic are you using?

I'm using Intel Graphics on a Thinkpad T520.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

I also encountered the problem on my previous laptop, which was a Thinkpad X230, also with Intel graphics.

> I tested it with nvidia driver from rpmfusion.

I don't have any nvidia machines I could cross test with.


Another thought occurred to me: I also have workrave installed.  I don't know if it is relevant, but it's possible.  Often mate-screensaver activates when I am taking a workrave enforced rest break.  I'm pretty sure I've had this problem occur other times as well, but I'm not certain.

(In reply to David Gibson from comment #22)
> Ok, as noted above, I'm still seeing the problem with f22.
> 
For some reasons xmonad-mate didn't start in my f22 VM.
> Another thought occurred to me: I also have workrave installed.  I don't
> know if it is relevant, but it's possible.  Often mate-screensaver activates
> when I am taking a workrave enforced rest break.  I'm pretty sure I've had
> this problem occur other times as well, but I'm not certain.

After installing xmonad-mate on my notebook MSI FX600 with intel graphic i could reproduce the issue after a long day of testing.
Late in evenning i couldn't unlock the session anymore.
Running 'journlctl -b 0 -f --no-tail' shows me that the fprintd.service was running.
This is complete weird/bad because my notebook doesn't have a fingerprint-reader.
After stoping the service i could unlock the session :)

fprintd.service is a static service wich will call by another service if needed, so i tried to mask the service.
But today i run in the issue again, so masking the service isn't enough.
Dbus tried to load the mask service, which failed of course.
But the lookscreen was unselectable again.
Reason enough to uninstall unneeded fprintd.
Now the lookscreen works until yet.

So the question is why is fprintd.service running on a system w/o a hardware for it, and which other service or appliction call it?

Looks for me more like a fprintd or maybe a systemd issue.

Can confirm that uninstalling fprintd helps?

Looks like it is enough to disable fingerprint support with authconfig-gtk, maybe.

(In reply to Wolfgang Ulbrich from comment #23)
> Can confirm that uninstalling fprintd helps?
error......can you confirm please uninstalling fprintd helps?
Or using authcofig-gtk to disable it?

Sorry, I never had fprintd installed, so I'm pretty sure that's not the problem in my case.

voom:~$ rpm -qa | grep -i fprint
voom:~$

[root@mother rave]# rpm -qa | grep -i fprint
libfprint-0.6.0-1.fc22.x86_64
fprintd-pam-0.6.0-1.fc22.x86_64
fprintd-0.6.0-1.fc22.x86_64


Weird, 'fprind' is in standard installation.
After i disabled the service with authconfig-gtk, i couldn't reproduce the issue anymore with my notebook running useless only for debugging this issue.
I suggest to run 'journlctl -b 0 -f --no-tail' in a second console.
There must be a hint.
Only you knows what happens on your notebook.
That the lockscreen change to 'sensitive' is a normal behaviour if typing a password isn't needed.
See https://github.com/mate-desktop/mate-screensaver/blob/master/src/gs-lock-plug.c#L1606

> Weird, 'fprind' is in standard installation.

Yes, but I habitually prune my install fairly heavily.

> After i disabled the service with authconfig-gtk, i couldn't reproduce the issue anymore with my notebook running useless only for debugging this issue.
> I suggest to run 'journlctl -b 0 -f --no-tail' in a second console.

Ok, I'll run that and see what I can find.

Finally reproduced for me with the journalctl running.  Not sure if you can make anything from this:

ct 07 21:09:08 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed
Oct 07 21:09:08 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: _weather_info_fill: assertion '((info == NULL) && (location != NULL)) || ((info != NULL) && (location == NULL))' failed
Oct 07 21:10:15 voom kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
Oct 07 21:10:15 voom kernel: [drm:intel_dp_complete_link_train [i915]] *ERROR* failed to start channel equalization
Oct 07 21:10:17 voom mate-session[15478]: WARNING: Detected that screensaver has left the bus
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: pam_unix(mate-screensaver:auth): conversation failed
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: pam_unix(mate-screensaver:auth): auth could not identify password for [dwg]
Oct 07 21:10:17 voom mate-screensaver-dialog[30404]: gkr-pam: no password is available for user
Oct 07 21:10:17 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed
Oct 07 21:10:17 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: _weather_info_fill: assertion '((info == NULL) && (location != NULL)) || ((info != NULL) && (location == NULL))' failed
Oct 07 21:10:18 voom org.mate.panel.applet.ClockAppletFactory[15435]: (clock-applet:15663): MateWeather-CRITICAL **: weather_info_abort: assertion 'info != NULL' failed

See https://github.com/mate-desktop/mate-screensaver/issues/82#issuecomment-170186186
Do you have Conky running?

No, I don't (in fact, never heard of it until now).

$ rpm -qa | grep conky
$ 

Sorry.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.