Project

General

Profile

Bug #14250

Applications menu stops working some times

Added by goupille 4 months ago. Updated 24 days ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
08/20/2017
Due date:
% Done:

10%

QA Check:
Info Needed
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

A few users reported that during some sessions, the 'Applications' menu button stops working moments after Tails finishes to start. Apparently, opening 'Places' then moving to 'Applications' works.

I could not reproduce myself but I have a user's whisperback report containing gnome-session error and warnings


Related issues

Blocks Tails - Feature #13244: Core work 2017Q4: Foundations Team Confirmed 06/29/2017

History

#1 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to anonym

(Sharing Foundations Team work.)

#2 Updated by intrigeri 3 months ago

  • Target version set to Tails_3.3

Putting this more obviously on anonym's radar.

#3 Updated by goupille 3 months ago

  • Status changed from New to Confirmed

switching this one to confirmed since it was reported by several sources

#4 Updated by intrigeri about 1 month ago

  • Priority changed from Normal to Elevated

This was 2nd on the list of hot topics for help desk in September, and according to them it keeps being one of the top reported problems => bumping priority.

#5 Updated by intrigeri about 1 month ago

  • Assignee changed from anonym to goupille
  • QA Check set to Info Needed

goupille wrote:

I could not reproduce myself but I have a user's whisperback report containing gnome-session error and warnings

I have no email with this ticket ID in the subject in my inbox. What's the report ID?

#6 Updated by goupille about 1 month ago

I have no email with this ticket ID in the subject in my inbox

that's probably because I forgot to send it :)

I just sent it to you with the ticket number in the subject

#7 Updated by goupille about 1 month ago

  • Assignee changed from goupille to intrigeri

#8 Updated by intrigeri about 1 month ago

  • QA Check deleted (Info Needed)

(Requested info was provided.)

#9 Updated by intrigeri about 1 month ago

#10 Updated by intrigeri about 1 month ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to goupille
  • Target version changed from Tails_3.3 to Tails_3.5
  • % Done changed from 0 to 10
  • QA Check set to Info Needed

In the logs I see nothing fishy. One notable thing though is that the system time was changed twice (once by tordate, once by htpdate) and both times towards the past:

Sep 23 14:34:15 amnesia time[17824]: A Tor consensus file now contains a valid time interval.
Sep 23 14:34:15 amnesia time[17827]: We do not have a Tor verified consensus, let's use the unverified one.
Sep 23 14:34:15 amnesia time[17828]: Waiting for the chosen Tor consensus file to contain a valid time interval...
Sep 23 14:34:15 amnesia time[17830]: The chosen Tor consensus now contains a valid time interval, let's use it.
Sep 23 14:34:15 amnesia time[17834]: Tor: valid-after=2017-09-23 11:00:00 | valid-until=2017-09-23 14:00:00
Sep 23 14:34:15 amnesia time[17837]: Current time is 2017-09-23 14:34:15
Sep 23 14:34:15 amnesia time[17842]: Current time is not in valid Tor range, setting to middle of this range: [2017-09-23 12:30:00]
Sep 23 12:30:00 amnesia systemd[6610]: Time has been changed
[…]
Sep 23 12:30:13 amnesia systemd[1]: Starting Setting time using HTP...
[…]
Sep 23 11:34:43 amnesia systemd[6610]: Time has been changed

I suspect that GNOME Shell (or something else down the stack) might not be super happy with going back in time. I wish there was a reliable way to tell wether the hardware clock is in UTC or in local time but sadly AFAIK that's impossible :/ I wonder if we should kill GNOME Shell (to force it to restart) when we do go back in time like this.

goupille, do you have more such reports? If so please send them to me, I'd like to check if there's a correlation between this problem and going back in time.

Apparently, opening 'Places' then moving to 'Applications' works.

This feels weird though. Is this the case for strictly more than one affected users?

I doubt we'll fix it in time for 3.3 so postponing.

#11 Updated by goupille about 1 month ago

  • Assignee changed from goupille to intrigeri
  • QA Check deleted (Info Needed)

I just sent you another report. it is from the user mentioning the 'places' workaround, and he or she said that the time was never set to GMT and that it needed to be set manually.

#12 Updated by intrigeri 25 days ago

  • Assignee changed from intrigeri to goupille
  • QA Check set to Info Needed

goupille wrote:

I just sent you another report. it is from the user mentioning the 'places' workaround, and he or she said that the time was never set to GMT and that it needed to be set manually.

I can't find this. The only related report I have received is "[related to #14250]Re: Bug report: 2eec54c8d51f21f68b806d55fdbd68d2".

#13 Updated by goupille 24 days ago

  • Assignee changed from goupille to intrigeri
  • QA Check deleted (Info Needed)

my bad, I just resend it now

#14 Updated by intrigeri 24 days ago

  • Assignee changed from intrigeri to goupille
  • QA Check set to Info Needed

goupille wrote:

my bad, I just resend it now

Right, but you didn't attach the full debug log and your MUA trimmed it.

#15 Updated by goupille 24 days ago

  • Assignee changed from goupille to intrigeri
  • QA Check deleted (Info Needed)

now you should have them :)

#16 Updated by intrigeri 24 days ago

  • Assignee changed from intrigeri to goupille
  • QA Check set to Info Needed

In the logs (ec826c287aaee84f677f11f65d4dca4f) I see that the user changed the system clock manually (org.gnome.controlcenter.datetime.configure) first thing after login, before Tails had any chance to do so automatically. So this does not help me understand the "she said that the time was never set to GMT and that it needed to be set manually" part. It might be that Tails would manage to set the timezone to GMT if the user waited enough; it might be that Tails would fail, and then it would be interesting to have this user report a bug about this, without tweaking the timezone manually. If you can have them do that, please file a dedicated ticket.

Regardless, in this case as well we go back in time, so my "GNOME Shell (or something else down the stack) might not be super happy with going back in time" hypothesis still holds.

I would like to see more reports, as 2 reports is a bit short wrt. validating my hypothesis: this was 2nd on the list of hot topics for help desk in September, so I assume there were surely more than 2 bug reports, no? Feel free to reassign to whoever was on Help Desk duty back then (or whoever felt they had enough data to classify this ticket this way).

Also available in: Atom PDF