Bug #10403

Screen blanking breaks some tests in Jessie

Added by anonym 2015-10-21 06:19:05 . Updated 2015-12-05 04:44:08 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
Tails_1.8
Start date:
2015-10-21
Due date:
% Done:

100%

Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
268

Description

E.g. the ‘I update APT using Synaptic’ step can result in a >5 minute wait without mouse/keyboard interaction => screen blanking kicks in and no further Sikuli screen scanning is possible so the ‘Installing packages through APT’ scenario fails.

Subtasks

History

#1 Updated by anonym 2015-10-21 06:19:57

I’ve tried this:

--- a/features/step_definitions/common_steps.rb
+++ b/features/step_definitions/common_steps.rb
@@ -292,6 +292,8 @@ Given /^Tails Greeter has dealt with the sudo password$/ do
 end

 Given /^the Tails desktop is ready$/ do
+  $vm.execute_successfully(
+    'gsettings set org.gnome.desktop.session idle-delay 0', LIVE_USER)
   case @theme
   when "windows"
     desktop_started_picture = 'WindowsStartButton.png'


but screen blanking still kicks in.

#2 Updated by anonym 2015-10-21 06:20:38

  • blocks #8668 added

#3 Updated by intrigeri 2015-10-23 08:19:28

> I’ve tried this:

I suspect that the gsettings command must be run in an environment closer to the active GNOME session (e.g. with access to the session D-Bus daemon, or something). But anyway, as long as we have no screen locker, I think we should just disable screen blanking entirely, as it provides a false belief of security.

#4 Updated by anonym 2015-11-09 16:04:58

intrigeri wrote:
> > I’ve tried this:
>
> I suspect that the gsettings command must be run in an environment closer to the active GNOME session (e.g. with access to the session D-Bus daemon, or something).

Indeed. We miss an appropriate DBUS_SESSION_BUS_ADDRESS. The stuff in ~/.dbus/session-bus/5ae29ba096384ae8b8223fb9ac6069ae-0 are not good. I wonder where good values can be obtained (?).

> But anyway, as long as we have no screen locker, I think we should just disable screen blanking entirely, as it provides a false belief of security.

Locking, yes, but screen blanking is still desirable for some, I guess. E.g. to save battery or whatever.

#5 Updated by anonym 2015-11-11 16:09:07

anonym wrote:
> We miss an appropriate DBUS_SESSION_BUS_ADDRESS.

Actually, we don’t. The remote shell sets it (and the rest of the environment) identically to what we see in e.g. gnome-terminal. For the amnesia user in both cases.

#6 Updated by intrigeri 2015-11-16 07:20:30

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

anonym wrote:
> anonym wrote:
> > We miss an appropriate DBUS_SESSION_BUS_ADDRESS.
>
> Actually, we don’t. The remote shell sets it (and the rest of the environment) identically to what we see in e.g. gnome-terminal.

Really? In the code it seems that we set the environment to what we see after su (commit:126f4a8), which is not the same as inside the desktop session.

Setting idle-delay to 0 from within the desktop session has the expected outcome here, so I think we’re back to “gsettings needs a D-Bus session bus connection to write changes to the dconf database” (gsettings(1)).

The easiest way to do that is probably via a systemd user service (config/chroot_local-includes/usr/lib/systemd/user/), that would be guarded with ConditionKernelCommandLine=autotest_never_use_this_option like config/chroot_local-includes/lib/systemd/system/tails-autotest-remote-shell.service. Want to give it a try, or should I?

#7 Updated by intrigeri 2015-11-16 09:14:29

Also see how we’ve already addressed a similar problem in tails-notify-user, by the way.

#8 Updated by anonym 2015-11-18 08:09:37

  • Assignee changed from anonym to intrigeri
  • % Done changed from 10 to 50
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to feature/jessie

intrigeri wrote:
> anonym wrote:
> > anonym wrote:
> > > We miss an appropriate DBUS_SESSION_BUS_ADDRESS.
> >
> > Actually, we don’t. The remote shell sets it (and the rest of the environment) identically to what we see in e.g. gnome-terminal.
>
> Really? In the code it seems that we set the environment to what we see after su (commit:126f4a8), which is not the same as inside the desktop session.

I was experimenting with the remote shell script, and had restarted it in a gnome-terminal, where these things are set. Oop, sorry for the noise!

> Setting idle-delay to 0 from within the desktop session has the expected outcome here, so I think we’re back to “gsettings needs a D-Bus session bus connection to write changes to the dconf database” (gsettings(1)).
>
> The easiest way to do that is probably via a systemd user service (config/chroot_local-includes/usr/lib/systemd/user/), that would be guarded with ConditionKernelCommandLine=autotest_never_use_this_option like config/chroot_local-includes/lib/systemd/system/tails-autotest-remote-shell.service. Want to give it a try, or should I?

I think your other approach is nicer because I think we need this in a few other scripts too, not only in the automated test suite.

> Also see how we’ve already addressed a similar problem in tails-notify-user, by the way.

Ah, indeed! It might even be that I implemented that hack. :) Any way, I’ve refactored that part out to the shell library:

0ef77da Refactor GNOME/X env exporting to Tails' shell library.
8c4a14e Grab the rest of the variables from gnome-shell's environment.
b415650 Include the GNOME/X environment in the remote shell.
fc5155a Disable screen blanking in the automated test suite.
e5baad0 Don't use static DISPLAY.
598a0bf Remove useless code.


What do you think? (The last two commits aren’t really related, but I found them (and thought they were wrong) while greping for instances to use the new refactored code in.)

#9 Updated by intrigeri 2015-11-18 08:38:40

  • Assignee changed from intrigeri to anonym
  • % Done changed from 50 to 80

> What do you think?

Excellent, thanks for putting all this care into our codebase!
I’ll let you confirm with the test suite that this doesn’t break anything and then mark this ticket as resolved :)

#10 Updated by intrigeri 2015-11-24 11:00:52

  • Deliverable for set to 268

#11 Updated by intrigeri 2015-11-24 16:25:26

  • blocks #8538 added

#12 Updated by intrigeri 2015-12-05 04:44:08

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 80 to 100
  • QA Check changed from Ready for QA to Pass

I didn’t see any breakage caused by these changes while running the test suite recently.