On a system with a shared home directory, I'm getting a bunch of warnings:
systemd-xdg-autostart-generator[76]: Exec binary '/usr/bin/flatpak' does not exist: No such file or directory
systemd-xdg-autostart-generator[76]: /home/zbyszek/.config/autostart/org.signal.Signal.desktop: not generating unit, error parsing Exec= line: No such file or directory
systemd-xdg-autostart-generator[76]: Exec binary '/usr/bin/flatpak' does not exist: No such file or directory
systemd-xdg-autostart-generator[76]: /home/zbyszek/.config/autostart/im.riot.Riot.desktop: not generating unit, error parsing Exec= line: No such file or directory
systemd-xdg-autostart-generator[76]: Exec binary '/usr/libexec/gnome-tweak-tool-lid-inhibitor' does not exist: No such file or directory
systemd-xdg-autostart-generator[76]: /home/zbyszek/.config/autostart/ignore-lid-switch-tweak.desktop: not generating unit, error parsing Exec= line: No such file or directory
systemd-xdg-autostart-generator[76]: Exec binary '/usr/bin/flatpak' does not exist: No such file or directory
systemd-xdg-autostart-generator[76]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop: not generating unit, error parsing Exec= line: No such file or directory
This isn't really a problem. Let's just print an info message.
If we're waiting for the debugger process to exit and receive SIGTERM,
propagate it to all processes in our process group, including the
debugger, so we can follow it up with a proper cleanup.
Resolves: #28772
Let's make kernel-install a bit easier to use:
If the kernel version is not specified, let's imply "uname -r", so that
we regnerate the entries for the current kernel.
If the kernel image is not specified let's imply using
/usr/lib/modules/$version/vmlinuz, i.e. the location distros like Fedora
drop the kernel into, which we generally recommend people to use.
If the kernel is not found there, don't try to automatically pick the
kernel path, and fail, as before.
Let's be friendly in what we accept: whenever we define a JSON
structure, let's also allow decimal strings where we want an integer.
This patch purely replaces JSON_VARIANT_UNSIGNED by
_JSON_VARIANT_TYPE_INVALID in the various JsonDispatch[] tables, so that
we'll happily accept any type in json_dispatch(), so that
json_dispatch_uint64() and related tools can do their thing.
This does not switch over OCI (as a JSON structure not defined by us).
JSON famously is problematic with integers beyond 53 bits, because
JavaScript stores everything in double precision floating points.
Various implementations in other languages can deal with signed 64 bit
integers, and a few can deal with unsigned 64bit too (like ours).
Typically program that need more then 53 bit of accuracy encode integers
as decimal strings, to make sure that even if consumers can't really
process larger values they at least won't corrupt the data while passing
it along. This is also recommended by JSON-I (RFC 7493)
To maximize compatibility with other implementations let's add 1st class
parsing support for such objects in the json_dispatch() API.
This makes json_dispatch_uint64() and related calls parse such
integers-formatted-as-decimal-strings as uint64_t. This logic will only
be enabled if the "type" field of JsonDispatch is left unspecified (i.e.
set to negative/_JSON_VARIANT_TYPE_INVALID) though, hence alone does not
change anything in effect.
This purely is about consuming such values, whether we should genreate
them also is a discussion for a separate PR.
When starting a service with a non-root user and a SystemCallFilter and
other settings (like ProtectClock), the no_new_privs flag should not be set.
Also, test that CapabilityBoundingSet behaves correctly, since we need
to preserve some capabilities to do the seccomp filter and restore the
ones set by the service before executing.
Until now, using any form of seccomp while being unprivileged (User=)
resulted in systemd enabling no_new_privs.
There's no need for doing this because:
* We trust the filters we apply
* If User= is set and a process wants to apply a new seccomp filter, it
will need to set no_new_privs itself
An example of application that might want seccomp + !no_new_privs is a
program that wants to run as an unprivileged user but uses file
capabilities to start a web server on a privileged port while
benefitting from a restrictive seccomp profile.
We now keep the privileges needed to do seccomp before calling
enforce_user() and drop them after the seccomp filters are applied.
If the syscall filter doesn't allow the needed syscalls to drop the
privileges, we keep the previous behavior by enabling no_new_privs.
With ResolveUnicastSingleLabel=yes, a scope's search domains are affixed to the
query even when a routing domain matches the single-label query name,
preventing the use of dotless single-label domains entirely.
This changes dns_scope_name_wants_search_domain() to return false when the
scope contains an exact match of the single-label name in the query, allowing
lookups for dotless domains with ResolveUnicastSingleLabel enabled.
Linux's Control Group v2 interfaces exposes memory.peak, which contains the
"max memory usage recorded for the cgroup and its descendants since the
creation of the cgroup."
This commit adds a new property "MemoryPeak" for units and makes "systemctl
show" display this value if it is available.
Fixes#29878.
Signed-off-by: Florian Schmaus <flo@geekplace.eu>
Also, don't panic when both optional arguments are empty. This should
make the syntax compatible-ish with the dracut one from dracut.cmdline(7).
Resolves: #29855
Previously only the first entered passphrase would be used. Add the ability to check all the passwords entered by the user. The total number of passwords entered is still limited by passphrase entry limit.
I am sorry, I totally forgot adding emojis reflecting the state of each
PCR. I hope I can do better in future, and hereby I'd like to rectify
the situation a bit.
In mkosi, we can't use kernel-install directly but we do want to
mimick its behavior as much as possible. Let's make that easier by
making it easy to fetch data from kernel-install as JSON.
To get all the necessary data, we extend the inspect verb to also
allow passing in a kernel version and initrds, to mimick the "add"
verb. The kernel version is used to determine the "Entry Directory",
and in absence of auto-detection of kernel version in kernel-install
we have to allow users to pass it.
We also add --no-pager while we're at it.
This changes how the "extra" command line arguments passed to vmspawn
are handled.
Previously they were appended to the QEMU command line directly.
Now they are appended to the kernel command line using SMBIOS instead.
This reverts commit 0ba8374bb8.
- link->network->ipv6_hop_limit must not be updated, as it may be used
by multiple interfaces,
- We may receive multiple RA from multiple routers with different hop
limit, and we should not make the default hop limit flicking,
- First of all, there is no reason that we need to update the default hop
limit,
- The original issue should be caused by the hash and compare functions
for Route object.
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Frantisek Sumsal
Antonio Alvarez Feijoo
Iago López Galeiras
Mike Yuan
Daan De Meyer
Tad Fisher
Florian Schmaus
Peter Hutterer
jjimbo137
Sam Leonard