-
intrigeri authored
This is merely preparatory work that lays down some foundations. For now, we're using two targets: * basic.target sets up things that should be done as early as possible, don't need access to X, notifications, nor D-Bus ; it is automatically started by `systemd --user' when the logind session is created. Note that this happens after persistence has been set up, when the GDM autologin is triggered, and before /etc/gdm3/Xsession is run: - tails-add-GNOME-bookmarks.service - tails-create-tor-browser-directories.service * desktop.target: we're starting it via xdg/autostart during the GNOME session startup. There are a few units wanted by this target so far: - tails-configure-keyboard.service - tails-virt-notify-user: ideally, this should have something like After=notifications-ready.target (and then, most other things that wait for GNOME Shell to be ready to handle notifications could do the same instead of grep'ing the process list). - tails-warn-about-disabled-persistence.service - tails-upgrade-frontend.service: the idea is to later use systemd units ordering to make it run at a time that increases chances for the system having enough free memory; e.g. as soon as possible once the session is ready, Tor has bootstrapped, and some other memory-hungry programs we run at session startup time have completed. - tails-security-check.service: similarly, the idea is that we could get rid of the wrapper — that merely waits for Tor to have finished bootstrapping — given another systemd unit. Most of these units exit early unless they're run by the `amnesia' user. Otherwise they break e.g. Tails Greeter startup, and probably worse. Also note that the units that may take ages to complete have Type=simple. With Type=oneshot, systemd would wait for them to complete before running any follow-up units, and before considering the target they're part of has been reached. Two of our units can take minutes to complete, so the desktop.target startup would fail. Now, using Type=simple has one drawback: it makes it harder to order other units relatively to tails-security-check-wrapper's and tails-upgrade-frontend-wrapper's completion. This doesn't feel too bothering, though: it's more likely that we want to configure these units to start after others, than the opposite. Also, when the GNOME session is initialized, we import the relevant D-Bus, X11 and locales variables into systemd --user's environment, so that our units can use them. We do that immediately before starting desktop.target.
9fb0136e