Bug #12098

Spurious screensaver activation while synchronizing the system clock

Added by intrigeri 2016-12-29 11:47:15 . Updated 2017-05-11 11:44:35 .

Status:
Rejected
Priority:
Normal
Assignee:
intrigeri
Category:
Time synchronization
Target version:
Start date:
2016-12-29
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

So, here’s the thing: sometimes, in the first few minutes after I’ve logged into the GNOME desktop, the screensaver activates. I’m pretty sure this happens before the screensaver activation timeout (5 minutes IIRC). Which makes me guess that this is caused by the screensaver idle counter being confused by the system time changing under its feet, due to our time synchronization process.

I’ve been experiencing this regularly for a while, but have been too lazy until now to report it properly. I assume that I’m not an isolated example, and that other people suffer from it too. This behaviour is surprising, and I expect that new users will be confused if they have to learn how to exit the screensaver that early in their initial Tails experience.

I propose we disable the screensaver activation entirely for now (and revert commit:fc5155af587d3f1161db8a7b54a3dd7c9bd73406 since the default settings will then fit the needs of the test suite): it can potentially confuse any user in the general case, and the kind of people who already use the (unsupported so far) screen locking feature should be able to re-enable this timeout if they desire so.

Later on, whenever the screen locking implementation is completed, if the idea is to have it self-activate based on this timeout, then this activation system should probably be disabled during time synchronization, otherwise we’ll be re-introducing this bug.

Subtasks

Related issues

Related to Tails - Feature #5684: Screen locker Resolved 2014-12-03
Related to Tails - Feature #5799: Deactivate screensaver until time is set Rejected

History

#1 Updated by intrigeri 2016-12-29 11:47:41

#2 Updated by anonym 2017-01-04 17:59:00

Interesting, cause I haven’t seen this myself since what feels like when Tails was running GNOME 2 so I have just assumed that the mechanism used to measure idle time moved to a monotonic clock (or similar) in GNOME 3.

I looked around in various GNOME sources (using https://codesearch.debian.net/ — awesome stuff!) and found something that might be related (although I doubt it) but still seems like it might be relevant for us:

/**
 * If you are setting org.gnome.desktop.session.idle-delay directly in dconf,
 * rather than through System Settings, you also need to set
 * org.gnome.settings-daemon.plugins.power.sleep-display-ac and
 * org.gnome.settings-daemon.plugins.power.sleep-display-battery to the same value.
 * This will ensure that the screen blanks at the right time when it fades out.
 * https://bugzilla.gnome.org/show_bug.cgi?id=668703 explains the dependency.
*/


That said, I still didn’t find how the time is measured (monotonic or not) and I’m not sure I’ll have another look (so don’t wait on me!).

#3 Updated by intrigeri 2017-01-06 08:53:52

>
> /
> * If you are setting org.gnome.desktop.session.idle-delay directly in dconf,
> * rather than through System Settings, you also need to set
> * org.gnome.settings-daemon.plugins.power.sleep-display-ac and
> * org.gnome.settings-daemon.plugins.power.sleep-display-battery to the same value.
> * This will ensure that the screen blanks at the right time when it fades out.
> * https://bugzilla.gnome.org/show_bug.cgi?id=668703 explains the dependency.
> */
>

Thanks, I’ll try that (but it’s not super easy since I can’t reproduce this bug reliably).

#4 Updated by intrigeri 2017-01-07 13:36:42

  • related to Feature #5799: Deactivate screensaver until time is set added

#5 Updated by intrigeri 2017-01-07 13:39:06

  • Target version changed from Tails 2.10 to Tails_2.11

I guess this wasn’t discussed during the monthly meeting, so postponing. If I have extra time before the 2.10 freeze (I doubt it), I might try anonym’s findings.

#6 Updated by intrigeri 2017-03-03 19:41:47

  • Type of work changed from Discuss to Test

#7 Updated by intrigeri 2017-03-05 15:25:44

  • Target version changed from Tails_2.11 to Tails_2.12
  • Type of work changed from Test to Discuss

We don’t set /org/gnome/desktop/session/idle-delay ourselves outside of the test suite, so in Tails 2.10 it has its default value (300). So I don’t think that this code comment applies to us. Besides, the org.gnome.settings-daemon.plugins.power.sleep-display-ac and org.gnome.settings-daemon.plugins.power.sleep-display-battery keys are not declared by any schema in Tails 2.10. That comment was added 5 years ago, and it seems to be outdated. In org.gnome.settings-daemon.plugins.power we now have sleep-inactive-ac-timeout and sleep-inactive-battery-timeout that might replace those though (not sure). In Tails 2.10 they’re set to 0, which means “never”.

So, we run with the default Jessie settings, and I’ve never heard of any such problem on “normal” Jessie systems. Hence my quick guess pointing to the way we synchronize the time as the likely cause of this problem.

So I’m reiterating my initial proposal, i.e. disable the screensaver activation entirely for now (and revert commit:fc5155af587d3f1161db8a7b54a3dd7c9bd73406 since the default settings will then fit the needs of the test suite):

  • the current behavior can potentially confuse any user;
  • those who already use the (unsupported so far) screen locking feature should be able to re-enable this timeout if they want automatic screen locking.

Of course, identifying the root cause of the problem would be nicer if we had infinite resources. We haven’t, so my proposal is to very cheaply fix the problem that any user can currently see, and only slightly harms (presumably very few) people who use an unsupported feature.

#8 Updated by intrigeri 2017-03-05 15:25:58

  • Assignee deleted (intrigeri)

#9 Updated by intrigeri 2017-04-20 06:43:22

  • Target version deleted (Tails_2.12)

Added to the monthly meeting agenda.

#10 Updated by Anonymous 2017-05-03 20:50:40

Notes from the monthly meeting of May:

There don’t seem to be any bug reports about this issue, so some of us are wondering if users are really confused by this.

Currently, the screen does not get locked if no root password is set, which means, that the screensaver gets activated but not locked. A simple key stroke will disable it again.

As a side note, segfault has been working on a tool which will allow to set a password if the user has not set a root password but he will have no time to debug this soon, see https://labs.riseup.net/code/issues/5684#note-57
As he’s not been able to reproduce the issue, we might want to ask for help on tails-dev or tails-testers.

Segfault would prefer disabling the screensaver for now - if there are more people than intrigeri who have experienced this. But it looks like none of us has seen this, nor have there been any bug reports about it (some of us don’t use Tails on a daily basis though).

So we do currently agree that the issue is not important enough to totally disable the screenlocker for those who have a root password set. Some of us use this feature or think that it’s important to keep it. Even if it’s not documented. It seems to be an asked for feature as there are even howtos on Reddit on how to install other screensavers on Tails.

Next steps: investigate further, but don’t revert this.

#11 Updated by intrigeri 2017-05-11 09:28:57

  • Assignee deleted (None)
  • QA Check set to Info Needed

First, thanks a lot for these detailed minutes! There’s only one bit that I need clarification about, see below.

> But it looks like none of us has seen this, nor have there been any bug reports about it (some of us don’t use Tails on a daily basis though).

Note that one has very little chance to reproduce the problem on a system whose clock is set to a timezone close enough to UTC. This might explain why you folks have never seen it :) So basically the only users who could have reported this are Windows users living in places far enough from UTC.

> So we do currently agree that the issue is not important enough to totally disable the screenlocker for those who have a root password set. Some of us use this feature or think that it’s important to keep it. Even if it’s not documented. It seems to be an asked for feature as there are even howtos on Reddit on how to install other screensavers on Tails.

Fair enough.

> Next steps: investigate further, but don’t revert this.

I can do that, if I’m told what the people at the meeting felt should be investigated further.

But I would be fine with simply rejecting this ticket (and reopen if/when I can come up with a better explanation of what’s happening, and an assessment of how many users are affected).

#12 Updated by Anonymous 2017-05-11 11:44:35

  • Status changed from Confirmed to Rejected
  • Assignee set to intrigeri
  • QA Check deleted (Info Needed)

intrigeri wrote:
> Note that one has very little chance to reproduce the problem on a system whose clock is set to a timezone close enough to UTC. This might explain why you folks have never seen it :) So basically the only users who could have reported this are Windows users living in places far enough from UTC.

I see. In any case it seems that our helpdesk has never heard about it.

> > Next steps: investigate further, but don’t revert this.
>
> I can do that, if I’m told what the people at the meeting felt should be investigated further.

I think I meant to write, if you think it’s important, than you may investigate why it happens, but don’t simple deactivate the screensaver.

> But I would be fine with simply rejecting this ticket (and reopen if/when I can come up with a better explanation of what’s happening, and an assessment of how many users are affected).

Yes, let’s reject it for now. It seems more important to fix https://labs.riseup.net/code/issues/5684 instead.