The new helper combines a bunch of steps every invocation of
unsetenv_erase() did so far: getenv() + strdup() + unsetenv_erase().
Let's unify this into one helper that is harder to use incorrectly. It's
in inspired by TAKE_PTR() in a way: get the env var out and invalidate
where it was before.
Fixes regression introduced in 599be274c1
Moving the Xen check before the CPUID check, in order to handle the case where
a Xen domain is nested within a hypervisor which can be detected by via the
CPUID check, had an unintended consequence of causing Dom0 to report as a Xen
VM when it is not nested.
This patch stops further checks once it has been determined that Dom0 is not
nested within another hypervisor, meaning that the non-nested case matches its
previous logic (where it does not report as a VM).
Also, tidy the conditionals for the Xen and UML checks by removing handling of
a VIRTUALIZATION_VM_OTHER result, which has no code path.
Fixes#22511
On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
This effectively disables warnings about type/mode/ownership of existing
directories when recursively creating parent directories. (Or files. If there's
a file in a place we expect a directory, the code will later try to create
a file and fail. This follows the general pattern where we do (void)mkdir()
if the mkdir() is immediately followed by opening of a file.)
I was recently debugging an issue with the fstab-generator [1], and it says:
'Directory "/tmp" already exists, but has mode 0777 that is too permissive (0644 was requested), refusing.'
which is very specific but totally wrong in this context.
This output was added in 37c1d5e97d, and I still
think it is worth to do it, because if you actually *do* want the directory, if
there's something wrong, the precise error message will make it much easier to
diagnose. And we can't easily pass the information what failed up the call chain
because there are multiple things we check (ownership, permission mask, type)…
So passing a param whether to warn or not down into the library code seems like
the best solution, despite not being very elegant.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2051285
Even though ISO C11 doesn't mandate in which order the type specifiers
should appear, having `unsigned` at the beginning of each type
declaration feels more natural and, more importantly, it unbreaks
Coccinelle, which has a hard time parsing `long unsigned` and others:
```
init_defs_builtins: /usr/lib64/coccinelle/standard.h
init_defs: /home/mrc0mmand/repos/systemd/coccinelle/macros.h
HANDLING: src/shared/mount-util.c
: 1: strange type1, maybe because of weird order: long unsigned
```
Most of the codebase already "complies", so let's fix the remaining
"offenders".
Fixes a regression caused by 3008a6f21c.
Before the commit, when `mkdir_parents_internal()` is called from `mkdir_p()`,
it uses `_mkdir()` as `flag` is zero. But after the commit, `mkdir_safe_internal()`
is always used. Hence, if the path contains a symlink, it fails with -ENOTDIR.
To fix the issue, this makes `mkdir_p()` calls `mkdir_parents_internal()` with
MKDIR_FOLLOW_SYMLINK flag.
Fixes#22334.
Kernel commit dea2903719283c156b53741126228c4a1b40440f exposed (and
renamed) CIFS_MAGIC_NUMBER as CIFS_SUPER_MAGIC along with
SMB2_SUPER_MAGIC.
This fixes the following build fail on current Fedora Rawhide:
```
../src/basic/meson.build:389:8: ERROR: Problem encountered: found unknown filesystem(s) defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: CIFS_SUPER_MAGIC
Filesystem found in kernel header but not in filesystems-gperf.gperf: SMB2_SUPER_MAGIC
```
log_parse_environment() uses should_parse_proc_cmdline() to determine whether
it should parse settings from the kernel command line. But the checks that
should_parse_proc_cmdline() apply to the whole process, and we could get a positive
answer also when log_parse_environment() was called from one of the nss modules.
In case of nss-modules, we don't want to look at the kernel command line.
log_parse_environment_variables() that only looks at the environment variables
is split out and used in the nss modules.
Fixes#22020.
When the support for "synthetic errno" was added, we started truncating
the errno value to just the least significant byte. This is generally OK,
because errno values are defined up to ~130.
The docs don't really say what the maximum value is. But at least in principle
higher values could be added in the future. So let's stop truncating
the values needlessly.
The kernel (or libbpf?) have an error where they return 524 as an errno
value (https://bugzilla.redhat.com/show_bug.cgi?id=2036145). We would
confusingly truncate this to 12 (ENOMEM). It seems much nicer to let
strerror() give us "Unknown error 524" rather than to print the bogus
message about ENOMEM.
When chattr_full tries to apply flags one-by-one, and one fails,
record which errno was returned. But record EOPNOTSUPP(&friends)
only if no other error is observed, and return it only in that case
(otherwise keep returning ENOANO), so that callers can respond
appropriately to EOPNOTSUPP vs more relevant errors.
For example, this lets tmpfiles.d log at debug level when a filesystem
flag cannot be applied because the filesystem does not support it,
but at warning level if something else went wrong when applying it.
Restores logging behaviour of tmpfiles.d to pre-250.
Follow-up for: https://github.com/systemd/systemd/commit/c1631ee124a30abfb9c71e2a1534b8afffc3b6a7
Fixes: https://github.com/systemd/systemd/issues/21901
Lennart Poettering
Luca Boccassi
Richard Neill
Yu Watanabe
Matija Skala
Zbigniew Jędrzejewski-Szmek
Frantisek Sumsal
Franck Bui
Anita Zhang
Jan Janssen
Michal Koutný
Pigmy-penguin
Luca Boccassi
Mike Gilbert