]> git.ipfire.org Git - thirdparty/systemd.git/commit
logind: save /run/systemd/users/UID before starting user@.service 265/head
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 17 Jun 2015 15:45:49 +0000 (16:45 +0100)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 17 Jun 2015 16:04:26 +0000 (17:04 +0100)
commit71161305f191d1fe1242ccca47657f9ab51caad4
treea8bbcd7703e14af5556ca93a5ea492d467587510
parenteef8c1f6fd712749ff0204097eef9545d90842a2
logind: save /run/systemd/users/UID before starting user@.service

Previously, this had a race condition during a user's first login.
Some component calls CreateSession (most likely by a PAM service
other than 'systemd-user' running pam_systemd), with the following
results:

- logind:
  * create the user's XDG_RUNTIME_DIR
  * tell pid 1 to create user-UID.slice
  * tell pid 1 to start user@UID.service

Then these two processes race:

- logind:
  * save information including XDG_RUNTIME_DIR to /run/systemd/users/UID

- the subprocess of pid 1 responsible for user@service:
  * start a 'systemd-user' PAM session, which reads XDG_RUNTIME_DIR
    and puts it in the environment
  * run systemd --user, which requires XDG_RUNTIME_DIR in the
    environment

If logind wins the race, which usually happens, everything is fine;
but if the subprocesses of pid 1 win the race, which can happen
under load, then systemd --user exits unsuccessfully.

To avoid this race, we have to write out /run/systemd/users/UID
even though the service has not "officially" started yet;
previously this did an early-return without saving anything.
Record its state as OPENING in this case.

Bug: https://github.com/systemd/systemd/issues/232
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
src/login/logind-user.c