summaryrefslogtreecommitdiff
path: root/src/login/logind-seat.c
diff options
context:
space:
mode:
authorSimon McVittie <simon.mcvittie@collabora.co.uk>2015-06-17 16:45:49 +0100
committerSven Eden <yamakuzure@gmx.net>2017-03-14 10:03:48 +0100
commit31e57d94c86e0a4f332f30033b10e402fec4aac7 (patch)
tree8b896253f123793c08b45f77b11c912ba9245876 /src/login/logind-seat.c
parent7b3cb911e7ddb15cc8f7b1bf0a19c5619b58e23c (diff)
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>
Diffstat (limited to 'src/login/logind-seat.c')
0 files changed, 0 insertions, 0 deletions