IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's assert if we ever happen to pass 0 to one of the log functions.
With the preceding commit to return -EIO from log_*(), passing 0 wouldn't
affect the return value any more, but it is still most likely an error.
The unit test code is an exception: we fairly often pass the return value
to print it, before checking what it is. So let's assert that we're not
passing 0 in non-test code. As with the previous check for %m, this is only
done in developer mode. We are depending on external code setting
errno correctly for us, which might not always be true, and which we can't
test, so we shouldn't assert, but just handle this gracefully.
I did a bunch of greps to try to figure out if there are any places where
we're passing 0 on purpose, and couldn't find any.
The one place that failed in tests is adjusted.
About "zerook" in the name: I wanted the suffix to be unambiguous. It's a
single "word" because each of the words in log_full_errno is also meaningful,
and having one term use two words would be confusing.
Using a enum is all nice and generic, but at this point it seems unlikely that
we'll add further build modes. But having an enum means that we need to include
the header file with the enumeration whenerever the conditional is used. I want
to use the conditional in log.h, which makes it hard to avoid circular imports.
We intentionally do not inline initializations with definitions for
a bunch of _cleanup_ variables in tests, to ensure valgrind is triggered.
This triggers a lot of maybe-uninitialized false positives when -O2 and
-flto are used. Suppress them.
The warning was disabled in 8794164fed to avoid
false positives. But it is useful in finding errors, even if it sometimes
results in untrue warnings (c.f. 77fac974fe, da46a1bc3c).
After #19168, #19169, and #19175, there are no warnings with
-Dbuildtype=debug-optimized/-O2 and gcc-11.0.1-0.3.fc34.x86_64. Warnings
are reenabled for -O[23]
-O0 is good for development, and -O2 is the default optimization level for
Fedora package builds. -Os, -O3, -O1, and -Og still generate some warnings. In
fact, with -Os the number of warnings seems completely hopeless. Dozens and
dozens.
With 8f20232fcb systemd-localed supports
generating locales when required. This fails if the locale directory is
read-only, so make it writable.
Closes#19138
sd-boot has a copy of a subset of codes from libbasic. This makes
sd-boot share the code with libbasic, and dedup the code.
Note, startswith_no_case() is dropped from sd-boot, as
- it is not used,
- the previous implementation is not correct,
- gnu-efi does not have StrniCmp() or so.
There is no technical reason to support systems with split-usr, except for
backwards compatibility. Even though systemd itself makes an effort to support
this, many other tools aren't as careful. Despite those efforts, we
(collectively) get it wrong often, because doing it "wrong" on systems with
merged-usr has no consequences. Since almost all developers are on such
systems, any issues are only discovered late. Supporting this split-usr mode
makes both code and documentation more complicated. The split is purely
artificial and has no justification except to allow old installation to not
update. Mechanisms to update existing systems are available though: Fedora
did that in https://fedoraproject.org/wiki/Features/UsrMove, Debian has
the usrmerge package.
The next version of Debian will only support systems with split-usr=false,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#178:
The Technical Committee resolves that Debian 'bookworm' should
support only the merged-usr root filesystem layout, dropping support
for the non-merged-usr layout.
Let's start warning if split-usr mode is used, in preparation to removing the
split in one of the future releases.
The target is update-syscall-tables, so let's call the script
update-syscall-tables.sh to reduce the cognitive overhead when
trying to find the right file.
The script is renamed to match.
Now all targets are named uniformly in a tab-completion-friendly fashion, with
the exception of systemd-update-po which is generated by the i18n module
automatically:
$ ninja -C build -t targets | grep update
systemd-update-po: phony
update-syscall-tables: phony
update-syscall-header: phony
update-hwdb: phony
update-hwdb-autosuspend: phony
update-dbus-docs: CUSTOM_COMMAND
update-man-rules: CUSTOM_COMMAND
Very old versions of meson did not include the subdirectory name in the
target name, so we started adding various "top-level" custom targets in
subdirectories. This was nice because the main meson.build file wasn't
as cluttered. But then meson started including the subdir name in the
target name. So let's move the definition to the root so we can have all
targets named uniformly.
Before this commit, udevd is built with LOG_REALM=LOG_REALM_UDEV.
However, log level specified by e.g. environment variable or kernel
command line option are also passed to LOG_REALM_SYSTEMD. So, the
maximum log level for the two realms are always equivalent, and it is
not necessary to specify the build option. Hence drop it.
Allow to setup new bind mounts for a service at runtime (via either
DBUS or a new 'systemctl bind' verb) with a new helper that forks into
the unit's mount namespace.
Add a new integration test to cover this.
Useful for zero-downtime addition to services that are running inside
mount namespaces, especially when using RootImage/RootDirectory.
If a service runs with a read-only root, a tmpfs is added on /run
to ensure we can create the airlock directory for incoming mounts
under /run/host/incoming.
vcs_tag() is slow. When the version-tag meson option is set,
we can use configure_file() directly to speed up incremental
builds.
Before (with version-tag set to v247):
```
‣ Running build script...
[1/418] Generating version.h with a custom command
real 0m0.521s
user 0m0.229s
sys 0m0.067s
```
After (with version-tag set to v247):
```
‣ Running build script...
ninja: no work to do.
real 0m0.094s
user 0m0.048s
sys 0m0.022s
```
This adds the support for veritytab.
The veritytab file contains at most five fields, the first four are
mandatory, the last one is optional:
- The first field contains the name of the resulting verity volume; its
block device is set up /dev/mapper/</filename>.
- The second field contains a path to the underlying block data device,
or a specification of a block device via UUID= followed by the UUID.
- The third field contains a path to the underlying block hash device,
or a specification of a block device via UUID= followed by the UUID.
- The fourth field is the roothash in hexadecimal.
- The fifth field, if present, is a comma-delimited list of options.
The following options are recognized only: ignore-corruption,
restart-on-corruption, panic-on-corruption, ignore-zero-blocks,
check-at-most-once and root-hash-signature. The others options will
be implemented later.
Also, this adds support for the new kernel verity command line boolean
option "veritytab" which enables the read for veritytab, and the new
environment variable SYSTEMD_VERITYTAB which sets the path to the file
veritytab to read.
By default, systemd installs various sample configuration files
containing commented-out defaults. Systems seeking to minimize the
number of files in /etc may wish to install directories and
configuration files that have semantic effects, but not install not
commented-out sample configuration files.
Turn install-sysconfdir into a multi-valued option, with a "no-samples"
value to skip installing sample-only configuration files.
This change improves integration with distributions using locale-gen to
generate missing locale on-demand, like Debian-based distributions
(Debian/Ubuntu/PureOS/Tanglu/...) and Arch Linux.
We only ever enable new locales for generation, and never disable them.
Furthermore, we only generate UTF-8 locale.
This feature is only used if explicitly enabled at compile-time, and
will also be inert at runtime if the locale-gen binary is missing.
The next libblkid v2.37 is going to support session offsets for
multi-session CD/DVDs. This feature is implemented by "hint offsets".
These offsets are optional and prober specific (e.g., iso, udf, ...).
For this purpose, the library provides a new function
blkid_probe_set_hint(), and blkid(8) provides a new command-line
option --hint <name>=<offset>. For CD/DVD, the offset name is
"session_offset".
The difference between classic --offset and the new --hint is that
--offset is very restrictive and defines the probing area and the rest
of the device is invisible to the library. The new --hint works
like a suggestion, it provides a hint where the user assumes the
filesystem, but the rest of the device is still readable for the
library (for example, to get some additional superblock information
etc.).
If the --hint is without a value then it defaults to zero.
The option --hint implementation in udev-builtin-blkid.c is backwardly
compatible. If compiled against old libblkid, then the option is used in
the same way as --offset.
Addresses: https://github.com/karelzak/util-linux/issues/1161
Addresses: https://github.com/systemd/systemd/pull/17424
Normally ls-files prints the full path to files from the repo root. But when
$GIT_WORK_TREE is set, ls-files prints paths relative to the current
directory. When rebasing, $GIT_WORK_TREE is set in the commands executed from
'rebase -x'. This causes problems if meson config is touched and the meson
reconfigures itself. ($GIT_WORK_TREE shouldn't be relevant, since the paths that
ls-files reports don't depend on the work tree, but whatever.) Let's unset
GIT_WORK_TREE to avoid the issue.
$ (cd test; git --git-dir=$PWD/../.git ls-files ':/test/dmidecode-dumps/*.bin')
test/dmidecode-dumps/HP-Z600.bin
test/dmidecode-dumps/Lenovo-ThinkPad-X280.bin
test/dmidecode-dumps/Lenovo-Thinkcentre-m720s.bin
$ (cd test; GIT_WORK_TREE=$PWD/.. git --git-dir=$PWD/../.git ls-files ':/test/dmidecode-dumps/*.bin')
dmidecode-dumps/HP-Z600.bin
dmidecode-dumps/Lenovo-ThinkPad-X280.bin
dmidecode-dumps/Lenovo-Thinkcentre-m720s.bin
Fixes#18148.
Back in 5248e7e1f1 (July 2017) we moved over to
"_gateway", with the old name declared to be temporary measure. Since we're
doing a bunch of changes to resolved now, it seems to be a good moment to make
this simplification and not add support for the compat name in new code.
This makes commands like 'ninja -C build fuzz-journal-remote' or
'ninja -C build fuzzers' work, even if we have -Dfuzz-tests=false.
Two advantages: correctness of the meson declarations is verified even
if fuzzers are not built, and it easier to do a one-off build to check for
regressions or such.
Follow-up for 1763ef1d49.
Other similar variables use the binary name underscorified and upppercased
(with "_BINARY" appended in some cases to avoid ambiguity). Add "S" to follow
the same pattern for systemd-cgroups-agent.
Based on the discussion in #16715.
A distro (Fedora in particular) may want to enable oomd in a unstable
branch for testing, even though the package as a whole is compiled in release
mode. Let's emit a warning but otherwise allow this.
This is useful for development where overwriting files out side
the configured prefix will affect the host as well as stateless
systems such as NixOS that don't let packages install to /etc but handle
configuration on their own.
Alternative to https://github.com/systemd/systemd/pull/17501
tested with:
$ mkdir inst build && cd build
$ meson \
-Dcreate-log-dirs=false \
-Dsysvrcnd-path=$(realpath ../inst)/etc/rc.d \
-Dsysvinit-path=$(realpath ../inst)/etc/init.d \
-Drootprefix=$(realpath ../inst) \
-Dinstall-sysconfdir=false \
--prefix=$(realpath ../inst) ..
$ ninja install
There are downsides to using fexecve:
when fexecve is used (for normal executables), /proc/pid/status shows Name: 3,
which means that ps -C foobar doesn't work. pidof works, because it checks
/proc/self/cmdline. /proc/self/exe also shows the correct link, but requires
privileges to read. /proc/self/comm also shows "3".
I think this can be considered a kernel deficiency: when O_CLOEXEC is used, this
"3" is completely meaningless. It could be any number. The kernel should use
argv[0] instead, which at least has *some* meaning.
I think the approach with fexecve/execveat is instersting, so let's provide it
as opt-in.
For scripts, when we call fexecve(), on new kernels glibc calls execveat(),
which fails with ENOENT, and then we fall back to execve() which succeeds:
[pid 63039] execveat(3, "", ["/home/zbyszek/src/systemd/test/test-path-util/script.sh", "--version"], 0x7ffefa3633f0 /* 0 vars */, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
[pid 63039] execve("/home/zbyszek/src/systemd/test/test-path-util/script.sh", ["/home/zbyszek/src/systemd/test/test-path-util/script.sh", "--version"], 0x7ffefa3633f0 /* 0 vars */) = 0
But on older kernels glibc (some versions?) implement a fallback which falls
into the same trap with bash $0:
[pid 13534] execve("/proc/self/fd/3", ["/home/test/systemd/test/test-path-util/script.sh", "--version"], 0x7fff84995870 /* 0 vars */) = 0
We don't want that, so let's call execveat() ourselves. Then we can do the
execve() fallback as we want.
We want to compile the new code in CI without having to explicitly specify
-Doomd=true everywhere. Let's enable it by default, and rely on distros
setting -Dmode=release to not have it enabled by default.
Latest glibc has deprecated mallinfo(), so it might become unavailable at some point
in the future. There is malloc_info(), but it returns XML, ffs. I think the information
that we get from mallinfo() is quite useful, so let's use mallinfo() if available, and
not otherwise.
