Project

General

Profile

Bug #10403

Feature #7563: Update the automated test suite for Jessie ISO images

Screen blanking breaks some tests in Jessie

Added by anonym almost 4 years ago. Updated almost 4 years ago.

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

100%

Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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.

Associated revisions

Revision 9d8074d4 (diff)
Added by anonym almost 4 years ago

Work around screen blanking when testing Synaptic.

Updating APT may take more than the time needed for screen blanking
(and screen locking) to kick in. We prevent this by moving the mouse
every minute.

Refs: #10403

Revision fc5155af (diff)
Added by anonym almost 4 years ago

Disable screen blanking in the automated test suite.

In the automated test suite we sometimes need to wait long enough so
screen blanking activates, which can mess with Sikuli wait():ing for
some image. This is the case in e.g. the 'Install packages using
Synaptic' scenario, in which the APT update can take >5 minutes.

Will-fix: #10403

Revision fc764d63 (diff)
Added by anonym almost 4 years ago

Revert "Work around screen blanking when testing Synaptic."

This reverts commit 9d8074d44b0a095e766b40e831691e3c195b3052.

The screen blanking issue has been resolved, so the workaround is not
needed any more.

Refs: #10403

History

#1 Updated by anonym almost 4 years ago

  • Parent task set to #7563

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.

#3 Updated by intrigeri almost 4 years ago

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 almost 4 years ago

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 almost 4 years ago

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 almost 4 years ago

  • 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 (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 almost 4 years ago

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

#8 Updated by anonym almost 4 years ago

  • 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 (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 @grep@ing for instances to use the new refactored code in.)

#9 Updated by intrigeri almost 4 years ago

  • 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 :)

#12 Updated by intrigeri almost 4 years ago

  • 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.

Also available in: Atom PDF