Currently we consider any framebuffer device as enough to have a
valid graphical session, but this might lead to many false postives
like in the case of framebuffer devices that have a linked drm card
which is still in the process of being added, or for vesa fb, and
so it doesn't ensure us that we can have a proper graphical session.
Since these days we normally don't consider anything without a DRM
card able to provide a full graphical session, let's not set this
at this level.
Drivers which can provide a graphical session with the sole fb are
still free to mark any device as `master-of-seat`
Fixes#10435
Let's be more careful with what we serialize: let's ensure we never
serialize strings that are longer than LONG_LINE_MAX, so that we know we
can read them back with read_line(…, LONG_LINE_MAX, …) safely.
In order to implement this all serialization functions are move to
serialize.[ch], and internally will do line size checks. We'd rather
skip a serialization line (with a loud warning) than write an overly
long line out. Of course, this is just a second level protection, after
all the data we serialize shouldn't be this long in the first place.
While we are at it also clean up logging: while serializing make sure to
always log about errors immediately. Also, (void)ify all calls we don't
expect errors in (or catch errors as part of the general
fflush_and_check() at the end.
This makes use of rlimit_nofile_bump() in all tools that access the
journal. In some cases this replaces older code to achieve this, and
others we add it in where it was missing.
Let's be safe than sorry, in particular as logind doesn't set it up
anymore, but user-runtime-dir@.service does, and logind doesn't really
track success of that.
This heavily borrows from @intelfx' PR #5546, but watches all three
units that are associated with a user now: the slice, the user@.service
and user-runtime-dir@.service.
The logic and reasoning behind it is the same though: there's no value
in keeping lingering users around if all their three services are gone.
Replaces: #5546Fixes: #4162
Let's make this a bit prettier, and propagate unexpected access() errors
correctly.
(The callers of this function will suppress them, but it's nicer of they
do that, rather than us doing that twice in both the callers and the
callees)
This is useful so that during shutdown scope units are always terminated
before the mounts necessary for the home directory.
(Ideally we'd also add a similar dependency from the user@.service
instance to the home directory, but this isn't as easy as that service
is defined statically and not dynamically, and hence not easy to modify
dynamically, in particular when it comes to deps)
I think this is a slightly cleaner approach than parsing the
configuration file at multiple places, as this way there's only a single
reload cycle for logind.conf, and that's systemd-logind.service's
runtime.
This means that logind and dbus become a requirement of
user-runtime-dir, but given that XDG_RUNTIME_DIR is not set anyway
without logind and dbus around this isn't really any limitation.
This also simplifies linking a bit as this means user-runtime-dir
doesn't have to link against any code of logind itself.
Instead of managing it explicitly, let's simplify things and rely on
regular Wants=/Requires= dependencies to pull in these units from
user@.service and the session scope, and StopWhenUneeded= to stop these
auxiliary units again. This way, they can be pulled in easily by
unrelated units too.
This simplifies things quite a bit: for each session we now only need to
manage the session scope, and for each user the user@.service, the other
units are not something we need to manage anymore.
This patch also makes sure that if user@.service of a user is masked we
will continue to work, and user-runtime-dir@.service will still be
correctly pulled in, as it is now a dependency of the scope unit.
Fixes: #9461
Replaces: #5546
Let's propagate errors from stopping sessions via seat_stop(). This is
similar to how we propagate such errors in user_stop() for all sessions
associated with a user.
Note that we propagate these errors, but we don't abort the function.
let's make sure we log about every failure
Also, complain about systems where /dev/tty0 exists but
/sys/class/tty/tty0/active does not. Such systems (usually container
environments) are pretty broken as they mount something that is not a VC
to /dev/tty0 and they really shouldn't.
Systems should either have a VC or not, but not badly fake one by
mounting things wildly.
This just adds a warning message, as before we'll simply turn off VC
handling in this case.
Previously this was serialized as part of the user object. This didn't
work however, as we load users first, and sessions seconds and hence
referencing a session from the user load logic cannot work.
Fix this by storing an IS_DISPLAY property along with each session, and
make the session with this set display session when it is loaded.
Let's update things a bit to follow current practices:
- User structure initialization rather than zero-initialized allocation
- Always propagate proper errors from allocation functions
- Use _cleanup_ for freeing objects when allocation fails half-way
- Make destructors return NULL
Also, while we are at it, beef it up, by adding json-seq support (i.e.
https://tools.ietf.org/html/rfc7464). This is particularly useful in
conjunction with jq's --seq switch.
For non-`seat0` seats, attaching a graphics card to a seat can
lead to it getting created. This is because the graphics device
is a "master device" which means that device is a seat-defining
device.
`seat0` may get created, even before the graphics driver is loaded,
though. This is because the graphics driver is loaded
asynchronously at startup, and `seat0` is the primary seat of
system, associated with the system VTs.
When a graphics card is attached to a seat the `CanGraphical`
property on that seat will flip to `true`.
For seats that haven't been created yet (non-`seat0` seats), this
leads to `seat_start` getting called which ultimately causes the
seat to get serialized to `/run/systemd/seats`.
For `seat0`, which is already created, `seat_start` will return
immediately, which means the updated `CanGraphical` state will
never get written to `/run/systemd/seats`.
The end result is that clients querying `sd_seat_can_graphical`
won't get the correct answer for `seat0` in cases where the
graphics device takes a long time to load until some other peice
of seat state is updated.
This commit fixes the problem by calling `seat_save` explicitly
for already running seats at the time a graphics device is
attached.
