Project

General

Profile

Feature #5666

Test suite: reliably wait for post-Greeter hooks

Added by Tails over 6 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Test suite
Target version:
Start date:
Due date:
07/31/2016
% Done:

100%

Feature Branch:
test/5666-wait-for-greeter-PostLogin
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:
Greeter

Description

In the I log in to a new session step we should do something which waits for all Tails Greeter post-hooks to finish so we can rid ourselves of steps like Tails Greeter has dealt with the sudo password.

This may include making changes to Tails Greeter, e.g. having it create a file when it's done that we can wait for in the end of the I log in to a new session step.

It may be that opening a new GNOME session (which happens right after tails-greeter is done IIRC) creates such a file that we could poll for.

Associated revisions

Revision ec37d112 (diff)
Added by anonym over 3 years ago

Reliably wait for the Greeter's PostLogin script.

Historically we've tried to e.g. use the sudo password before it has
been properly set, so let's introduce a step that explicitly waits for
the PostLogin script to finish, which is implied by a logind session
having been opened for the LIVE_USER.

Will-fix: #5666

Revision 60140f3c
Added by bertagaz over 3 years ago

Merge remote-tracking branch 'origin/test/5666-wait-for-greeter-PostLogin' into stable

Fix-committed: #5666

History

#1 Updated by intrigeri over 6 years ago

  • Category set to Test suite
  • Starter set to No

#2 Updated by BitingBird over 5 years ago

  • Subject changed from test suite: reliably wait for post tails-greeter hooks to Test suite: reliably wait for post tails-greeter hooks

#3 Updated by intrigeri over 5 years ago

  • Subject changed from Test suite: reliably wait for post tails-greeter hooks to Test suite: reliably wait for post-Greeter hooks

#4 Updated by BitingBird about 5 years ago

  • Affected tool set to Greeter

#5 Updated by anonym about 5 years ago

  • Target version set to Tails_2.4

#7 Updated by intrigeri over 4 years ago

  • Due date set to 07/31/2016

#9 Updated by anonym over 4 years ago

  • Assignee set to anonym

Alternatively we modify these tests so they are done as a user would do them, i.e. not via the remote shell, but via gnome-terminal. Or we do it with the remote shell, but after the the Tails desktop is ready step.

#11 Updated by intrigeri over 3 years ago

  • Priority changed from Normal to Elevated

#13 Updated by intrigeri over 3 years ago

  • Priority changed from Elevated to High

#14 Updated by anonym over 3 years ago

  • Target version changed from Tails_2.4 to Tails_2.5

#15 Updated by intrigeri over 3 years ago

  • Status changed from Confirmed to In Progress
  • Target version changed from Tails_2.5 to Tails_2.6
  • % Done changed from 0 to 10

It seems that a session being registered with systemd-logind for the "amnesia" user is precisely the signal we must wait for, as GDM tells PAM that the session is open only after PostLogin has exited:

Jul 21 13:13:33 amnesia gdm-session-worker[2144]: Leaving PostLogin
Jul 21 13:13:33 amnesia gdm-autologin][2144]: pam_unix(gdm-autologin:session): session opened for user amnesia by (unknown)(uid=0)
Jul 21 13:13:33 amnesia systemd-logind[1692]: New session 1 of user amnesia.

Note that some PAM sessions are open earlier as user "amnesia", but they are non-interactive sudo calls, and are thus not registered with logind.

We can either poll using loginctl, or subscribe to some D-Bus signal.

Also, thanks to fc777723 that we did in May, the "Tails Greeter has dealt with the sudo password" step is now run from one single place, which eases reasoning about this problem a lot :)

#16 Updated by anonym over 3 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to test/5666-wait-for-greeter-PostLogin

Thanks for the suggestion, intrigeri!

Since you proposed this approach (=> you know the details already and hence only have to check the implementation), would you mind review'n'merging? Otherwise please reassign it to me so I can find someone else (hah!).

#17 Updated by intrigeri over 3 years ago

  • Assignee changed from intrigeri to bertagaz

Reassigning to bertagaz, who committed to do quick reviews for anonym's test suite stuff.

#18 Updated by intrigeri over 3 years ago

Ping?

#19 Updated by anonym over 3 years ago

  • Target version changed from Tails_2.6 to Tails_2.7

#20 Updated by bertagaz over 3 years ago

  • Status changed from In Progress to 11
  • % Done changed from 50 to 100

#21 Updated by bertagaz over 3 years ago

  • Assignee deleted (bertagaz)
  • QA Check changed from Ready for QA to Pass

bertagaz wrote:

Applied in changeset 60140f3ca76aef3dce3fa48e06b6ba3b6c692c68.

intrigeri wrote:

Reassigning to bertagaz, who committed to do quick reviews for anonym's test suite stuff.

Ran it extensively and it does seem to work well. It does feel more robust. On Jenkins the only time there are related failures, that's because of #11816. So it's now merged, congrats!

#22 Updated by bertagaz about 3 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF