Skip to content
  • intrigeri's avatar
    Convert a few X session startup programs to `systemd --user' units. · 9fb0136e
    intrigeri authored
    This is merely preparatory work that lays down some foundations.
    For now, we're using two targets:
     * 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
     * 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 (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
    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