Project

General

Profile

Bug #9059

Feature #14568: Additional Software Packages

Feature #5551: Remember installed packages

"Additional software" locks the opening of the desktop

Added by sajolida over 2 years ago. Updated 14 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Start date:
03/15/2015
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
Type of work:
Research
Blueprint:
Easy:
Affected tool:
Additional Software Packages

Description

From PostLogin.default in the Greeter, tails-additional-software install is run when the desktop is started. This can take several minutes during which the desktop is unresponsive. This should instead be done in the background.

See a patch in attachment that corrects this behavior, but I'm not knowledgeable about the GNOME internal to know if that's a good idea.

Team: alan (code), sajolida (ux), kurono (reviewer), segfault (reviewer), u (maybe)

0001-Start-tails-additional-software-install-in-the-backg.patch View (784 Bytes) sajolida, 03/15/2015 06:47 PM


Related issues

Related to Tails - Bug #11319: There should be user feedback when the session is loading Duplicate 04/04/2016
Related to Tails - Feature #9819: Check for updates of "additional software" only once Confirmed 07/29/2015

History

#2 Updated by intrigeri over 2 years ago

From PostLogin.default in the Greeter, tails-additional-software install is run when the desktop is started. This can take several minutes during which the desktop is unresponsive. This should instead be done in the background.

Two bits of historical information: the reason why we've designed this two-stages process (install before starting the session, upgrade after the network is up) is that some software needs to be installed before the session is started to be useful at all, e.g. things that wrap the call to gnome-session. It's certainly debatable whether the benefits (for very few users, likely, if any at all) are worth the annoyance (for many others), but it's worth making it clear that this proposal breaks previously supported usecases, at least in theory.

The obvious (?) solution to that would be to split the additional software config file into two, one that would list software installed before session startup, the other one would list software installed post-session-startup. I find it doubtful that it would be worth the effort.

I've no strong opinion regarding what we should do, but well, now you have more information to make up your mind :)

(Note that Alan's Redmine notifications are apparently disabled, so I'm not sure he'll see this ticket.)

#3 Updated by sajolida over 2 years ago

Thanks for the additional information, I didn't know about that.

  • Could we come up with some examples of useful packages that would be broken by this? What could they be?

Regarding your possible solution, we could:

  • Disable pre-login by default.
  • Keep `live-additional-software.conf` as the post-login list, so that most people don't have to change anything.
  • Try to document a workaround and ask people to complain.
  • See if people complain.
  • Then implement a special pre-login list if we really feel the need either by identificating useful packages that would be broken or by having people report on issues for them.

#4 Updated by intrigeri over 2 years ago

  • Could we come up with some examples of useful packages that would be broken by this? What could they be?

I'm too busy to add this to my plate, but at least I can help you find the answer yourself:

  • There are things that wrap the X session (e.g. all kinds of agents such as monkeysphere-validation-agent, gpg-agent, ssh-agent, some input methods and accessibility stuff). Most of the files that land into /etc/X11/Xsession.d/ are affected: http://codesearch.debian.net/results/etc%2FX11%2FXsession.d/page_0. These ones would be entirely broken if we install packages in a non-blocking way.
  • There are things that start automatically with the X session. They generally live in /etc/xdg/autostart/: http://codesearch.debian.net/results/etc%2Fxdg%2Fautostart/page_0. These ones will have surprising, racy behaviour if we install packages in a non-blocking way: sometimes the program will be automatically started, sometimes not.

Now, one should check in a real Tails the theory I'm coming up with here. It might be that the current implementation of additional software doesn't fully support one of these use cases.

Regarding your possible solution, we could:

  • Disable pre-login by default.
  • Keep `live-additional-software.conf` as the post-login list, so that most people don't have to change anything.
  • Try to document a workaround and ask people to complain.
  • See if people complain.
  • Then implement a special pre-login list if we really feel the need either by identificating useful packages that would be broken or by having people report on issues for them.

ACK. And hopefully we won't have to implement the pre-login list thingie, ever.

In any case, implementation-wise I'd like to avoid:

  • Introducing race conditions -prone behaviour, but I didn't look at the patch so I don't know if it's the case. Off the top of my head, we should install additional packages e.g. once GNOME has started.
  • Avoid triggering more "not enough memory available" errors from Tails Upgrader => likely one must make either Tails Upgrader wait for the additional software to be installed, or the opposite.

#5 Updated by sajolida over 2 years ago

  • Assignee deleted (alant)
  • Type of work changed from Code to Research

I'm too busy to work on this actively right now, but that's a lot for all the useful info.

I'm marking this as a Research ticket. It's bothering me enough so I'll keep it in mind even if not assigned to me. I'll try to dig into codesearch but I would be very happy if someone do that faster than me.

#6 Updated by alant over 2 years ago

sajolida wrote:

See a patch in attachment that corrects this behavior, but I'm not knowledgeable about the GNOME internal to know if that's a good idea.

This patch is likely to break any software that is autostarted or relies on session-wide environnment.

As already written above, the question here is: do we want startup speed or compatibility with more software.

#7 Updated by intrigeri over 2 years ago

alant wrote:

As already written above, the question here is: do we want startup speed or compatibility with more software.

I'm now in favour of startup speed, especially with the careful plan sajolida described in #9059#note-3.

#8 Updated by sajolida about 2 years ago

I'm bringing in some data on this issue. These are tests I made on a X200 with Tails 1.4.1 on a fast SD card:

  • 55 seconds between boot menu and Tails Greeter
  • 16 seconds between Greeter and GNOME without additional packages
  • 63 (+47) seconds between Greeter and GNOME with only `sm` as additional package
  • 114 (+51) seconds with my list of additional packages

Having even a single additional package more than double the waiting time at boot. Most of this is probably due to unpackaging and building the APT database again. Could we do that earlier? In parallel with the Greeter? Could we store this information in persistence and save us some time then?

#9 Updated by sajolida about 2 years ago

  • Assignee set to sajolida
  • QA Check set to Info Needed

We did some more testing and found out that /var/cache/apt/archives/ was stored in persistence while we could store all /var/cache/apt/ and hope for some performance improvements. Unfortunately this didn't change much and we couldn't fine any other low-hanging fruit.

Maybe installing the additional software packages could be started right after persistence is unlock, so we could gain a few seconds while the user after that might choose other options in the Greeter (like a root password).

As a next step, I'll provide with a syslog for installing a single additional package.

#10 Updated by sajolida about 2 years ago

  • Description updated (diff)
  • Target version set to 2016

#11 Updated by sajolida about 2 years ago

  • Related to Bug #9050: Persistence preset: additional software added

#12 Updated by sajolida about 2 years ago

  • Related to Feature #5996: Additional software configuration GUI added

#13 Updated by sajolida about 2 years ago

  • Related to Feature #9819: Check for updates of "additional software" only once added

#14 Updated by intrigeri about 2 years ago

Related to Feature #5996: Additional software configuration GUI added

Do you want a new "Affected tool" for this feature? It would be cleaner than added tons of "Related to" relationships.

#15 Updated by sajolida about 2 years ago

Do you want a new "Affected tool" for this feature? It would be cleaner than added tons of "Related to" relationships.

Yes please, that would be sweet :)

#16 Updated by sajolida about 2 years ago

  • Description updated (diff)

#17 Updated by intrigeri about 2 years ago

Yes please, that would be sweet :)

Done => please apply it instead of these "related to" relationships :)

#18 Updated by sajolida about 2 years ago

  • Related to deleted (Feature #5996: Additional software configuration GUI)

#19 Updated by sajolida about 2 years ago

  • Related to deleted (Feature #9819: Check for updates of "additional software" only once)

#20 Updated by sajolida about 2 years ago

  • Related to deleted (Bug #9050: Persistence preset: additional software)

#21 Updated by sajolida about 2 years ago

  • Affected tool changed from Greeter to Additional Software Packages

#22 Updated by sajolida about 2 years ago

  • Description updated (diff)

#23 Updated by Dr_Whax about 1 year ago

  • Description updated (diff)
  • Target version changed from 2016 to 2017

#24 Updated by sajolida about 1 year ago

  • Related to Bug #11319: There should be user feedback when the session is loading added

#25 Updated by BitingBird 24 days ago

  • Target version changed from 2017 to 2018

#26 Updated by BitingBird 24 days ago

  • Related to Feature #9819: Check for updates of "additional software" only once added

#28 Updated by sajolida 15 days ago

  • Assignee changed from sajolida to alant

Alan will solve this :)

#29 Updated by u 14 days ago

  • Parent task set to #14568

#30 Updated by u 14 days ago

  • Parent task changed from #14568 to #5551

#31 Updated by u 14 days ago

  • Target version changed from 2018 to Tails_3.4

Setting a target version - is this solvable while working on the Offline mode feature? Otherwise, change target version.

#32 Updated by intrigeri 14 days ago

Setting a target version - is this solvable while working on the Offline mode feature? Otherwise, change target version.

FWIW I think it can be solved independently from the offline mode.

Also available in: Atom PDF