We've changed them to return additional values, which may be a breaking
change for desktop environments. In practice, it doesn't seem to be a
major issue. However, let's make sure to document the changes in the
NEWS anyway!
Currently, there's no way for a desktop environment to detect when a
systemd inhibitor has been added or removed. This means that a desktop
environment that wishes to show current inhibitors to the user will be
either forced to poll systemd or just use stale data.
Now, the desktop can listen for changed events on NCurrentInhibitors and
call GetInhibitors() in response to that.
Desktops cannot currently tell the difference between a power action
being set to challenge permanently (i.e. because the sysadmin wanted to
restrict the given user) and a power action being set to challenge
because it's temporarily inhibited.
Thus, a desktop might take an action that is valid in the first case but
not the second case. For instance: GNOME hides all of its automatic
suspend settings from the UI whenever a sleep inhibitor is active.
This now returns a new state: "inhibited". It communicates to the
desktop that the action is available normally, but at the moment the
desktop isn't allowed to perform the action due to an inhibitor.
Related: https://github.com/systemd/systemd/issues/37311
* 89a825b80e Install new files for upstream build
* 38b1a75eaa systemd.postinst: update journal catalog after reexecing managers
* 9420ffa0dd Install new files for upstream build
* cb5fdf4df0 Install sd-report from new path
* 2501efe312 homed: drop dependency satisfied since bookworm/noble
* 424262b674 d/control: add TODO
* 9aaa01c99d d/libsystemd-shared.preinst: refuse to upgrade without unified cgroupv2 hierarchy
* 7d0ac8a4b8 Install new files for upstream build
* 7e55d41841 Do not install legacy.conf in upstream builds
* 190387958e d/e/checkout-upstream: try to install build deps with sudo in case it fails
* 2a4aa9f426 Disable installing runlevel targets for upstream build
* e02600f2d9 Install new files for upstream build
* 0f1a56cf10 Update changelog for 259.1-1 release
* e463300b1a d/e/checkout-upstream: try to install build deps again after switching to CI branch
* b3f72821e5 Install ask-password polkit policy file
* 8219d561ae Restrict the tpm2-generator manpage to arches where it is built
* 30a0f27283 systemd.postinst: reexec system manager before user instances
* 1fc9ea2790 systemd.postinst: reexec before restarting any service
* d9991aeb22 d/control: use libarchive13t64 | libarchive13 for bookworm/jammy
* b750346711 d/control: make systemd-container Depends: libarchive13t64
Fixes https://github.com/systemd/systemd/issues/40777
Now that it’s been replaced by `Acquire()` and `Install()`, there’s no
need to expose it as a separate method. Wrappers around `sysupdated` can
still expose an ‘update’ convenience verb by calling those two methods.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
This further expands the sysupdate test to run the suite a fourth time,
testing that `updatectl update` behaves the same as `sysupdate update`
and `sysupdate acquire; sysupdate update --offline`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than calling `Update()`. This should allow us to eventually drop
`Update()`.
This should just be an internal change, and should not result in any
user-visible changes to the behaviour of `updatectl update`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
These mirror the `sysupdate acquire` and `sysupdate update --offline`
verbs, which are themselves a split of `sysupdate update` into
downloading and installing stages.
The existing `sysupdated` `Update()` method is kept for now, for
convenience. It might be dropped in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: https://github.com/systemd/systemd/issues/34814
xfsprogs 6.17.0 added support for populating xfs filesystems from
directories. As this supports extended attributes unlike our current
hack with protofiles. Let's make use of the new feature in mkfs-util.c
As there's no clean way to do feature detection on the mkfs.xfs binary,
we drop support for the old hack with protofiles that we had before.
Useful for packaging scripts, when units are removed.
When multiple markers are assigned without +/-, the last one wins.
When using +/-, the job merging logic is followed to the extent possible.
If we include a verity signature but the corresponding key is not in
the kernel keyring or userspace, try to get polkit auth similar to how
we do the same if the image doesn't pass the policy.
Note that SD_VARLINK_ERROR_INVALID_PARAMETERS requires
the invalid param name to be specified, hence we would
otherwise have reported an invalid INVALID_PARAMETERS
error ;)
* Make sure ret is initialized on success return
* Drop unneeded 'object' variable
* No need to ref/unref json objects when constructing
intermediary array
For AF_UNIX sockets connection sources are accounted for
based on UID, hence in user scope this effectively
limits total number of connections, which is not really
desirable.
Follow-up for a109189fab
This follows the existing practice for
systemd-journal-{upload,gatewayd}.service,
as I think allocating a full-blown user
specifically for this purpose is an overkill.
And with DynamicUser=yes we can also take
advantage of implied sandboxing.
Otherwise, `<variable>location</variable>` is rendered:
```
[2365/2925] Generating man/systemd.mstack.7 with a custom command
Element variable in namespace '' encountered in para, but no template matches.
```
The removed code in device_tag_index() in fact does nothing,
as sd_device.all_tags is never cleared. Moreover, not only the code
is meaningless, but it is theoretically/logically wrong, as the symlinks
in /run/udev/tags/ should be 'sticky', hence we should even not try to
remove them.
The current tag concept has been introduced by
e77b146f82 (v247) to make symlinks in
/run/udev/tags/ are 'sticky'.
However, when TAG= (rather than TAG+=) is specified, then the tags
assigned in the previous events were also cleared.
This fixes the issue and now symlinks in /run/udev/tags/ are really
'sticky'.
Fortunately, TAG= is mostly unused. So, the issue should not affect
and the fix should not change anything on almost all systems.
journalctl: add new varlink read service to get entries
We already have some varlink support for the journal to perform
some actions like `Rotate`. It would be nice to be able to query
the journal via varlink too so this commit adds a new varlinkctl
based journal service that exposes a single GetEntries() call
to retrieve journal entries. Basic filtering is supported and
we can expand the API as needed.
This is a separate `io.systemd.JournalControl` [1] service from the
existing `io.systemd.Journald` to decouple read and write (thanks
to Lennart for suggesting this).
This also extracts some shared helper so that we do not duplicate
code when generating the json or when adding the filters.
[1] The name mirrors the bootctl->io.systemd.BootControl naming.
ref_uid is initialized to invalid, and is only set in some
circumstances. The AttachProcesses will attempt to check it,
and assert that it is valid. Check beforehand.
Reported as YWH-PGM9780-89
Follow-up for 59857b672c
We already have some varlink support for the journal to perform
some actions like `Rotate`. It would be nice to be able to query
the journal via varlink too so this commit adds a new varlinkctl
based journal service that exposes a single GetEntries() call
to retrieve journal entries. Basic filtering is supported and
we can expand the API as needed.
This is a separate `io.systemd.JournalControl` [1] service from the
existing `io.systemd.Journald` to decouple read and write (thanks
to Lennart for suggesting this).
This also extracts some shared helper so that we do not duplicate
code when generating the json or when adding the filters.
[1] The name mirrors the bootctl->io.systemd.BootControl naming.
find_ovmf_config() would do filtering based on arg_secure_boot
already, hence the mismatch can only occur if we're using
user-specified firmware. So be explicit about this in log.
I expressed the issue I have with parse_tristate_argument()
in #37751: it doesn't add any value to direct use of parse_tristate();
on the contrary, it doesn't support means to reset the arg to "auto"/-1 state.
The mere reason it existed is that we need a int type ret param.
Since the previous attempt to address this mess failed, let's
try to make the function more useful by making it accept "auto".
I figure this is useful on its own.
As requested in
https://github.com/systemd/systemd/pull/40652#discussion_r2831833996,
the function name is suffixed with _with_auto() to establish
that "auto" is handled internally.
Adrian Vovk
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Lennart Poettering
Daan De Meyer
Philip Withnall
Mike Yuan
DaanDeMeyer
Ettore Atalan
Yaron Shahrabani
Antonio Alvarez Feijoo
Yu Watanabe
Michael Vogt
Ryan Zeigler
