This speeds up the meson install step by half a second
which, given the trivial changes required to add this
option, makes it worth the effort to support this.
Before:
```
‣ Running build script...
[1/418] Generating version.h with a custom command
Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo
Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo
Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo
Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo
Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo
Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo
Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo
Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo
Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo
Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo
Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo
Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo
Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo
Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo
Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo
Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo
Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo
Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo
Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo
Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo
Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo
Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo
Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo
Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo
Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo
Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo
Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo
Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo
Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo
Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo
real 0m1.467s
user 0m1.064s
sys 0m0.392s
```
After (with translations disabled):
```
‣ Running build script...
[1/418] Generating version.h with a custom command
real 0m0.925s
user 0m0.622s
sys 0m0.301s
```
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 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.
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.
We don't (and shouldn't I think) look at them when determining the type of the
user, but they should be used during user/group allocation. (For example, an
admin may specify SYS_UID_MIN==200 to allow statically numbered users that are
shared with other systems in the range 1–199.)
It makes little sense to make the boundary between systemd and user guids
configurable. Nevertheless, a completely fixed compile-time define is not
enough in two scenarios:
- the systemd_uid_max boundary has moved over time. The default used to be
500 for a long time. Systems which are upgraded over time might have users
in the wrong range, but changing existing systems is complicated and
expensive (offline disks, backups, remote systems, read-only media, etc.)
- systems are used in a heterogenous enviornment, where some vendors pick
one value and others another.
So let's make this boundary overridable using /etc/login.defs.
Fixes#3855, #10184.
This means that the dbus doc consistency checks will be enabled by default,
including in the CI. I think that will work better than current state where
people do not enable them and them follow-up patches for the docs like the
parent commit must be had.
This adds an option to build standalone binaries that do not depend on the
systemd-shared library. This option can be handy to build binaries that can be
useful on a non-systemd system, binaries such as systemd-sysusers and
systemd-tmpfiles have been previously requested, but installing them with all
the required dependencies pulls in too much code that isn't really relevant for
those use cases. The standalone use case is also relevant in containers, where
minimizing the size of the container image is quite relevant.
For now, only `systemd-sysusers` is also built as a standalone binary.
The standalone binaries are installed as `/usr/bin/%{name}.standalone`, the
packaging system is reponsible for renaming those into the correct names
during the packaging step. RPM is able to do so with RemovePathPostfixes:
The default behavior is to build shared binaries only, since this option is
mainly intended for building distribution packages.
Tested that a proper separate binary is built when using this option and
that having it disabled (or using the default Meson configuration) does not
produce a binary for this option.
This generator can be used by desktop environments to launch autostart
applications and services. The feature is an opt-in, triggered by
xdg-desktop-autostart.target being activated.
Also included is the new binary xdg-autostart-condition. This binary is
used as an ExecCondition to test the OnlyShowIn and NotShowIn XDG
desktop file keys. These need to be evaluated against the
XDG_CURRENT_DESKTOP environment variable which may not be known at
generation time.
Co-authored-by: Henri Chain <henri.chain@enioka.com>
The slow-tests= option already enables fuzzers as well, however, this
option can't be used in the "fully sanitized" runs, as certain slow
tests are affected by the performance quite significantly.
This option allows us to enable only fuzzers without the slow tests to
meet the needs of such runs.
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
Enables building systemd without systemd-analyze, which in
return saves approx. 4 MB of space upon installing systemd.
Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>
Signed-off-by: Luka Perkov <luka.perkov@sartura.hr>
This commit introduces new meson build option "kernel-install" to prevent kernel-install from building if the user
sets the added option as "false".
Signed-off-by: Jakov Smolic <jakov.smolic@sartura.hr>
Signed-off-by: Luka Perkov <luka.perkov@sartura.hr>
Build option "link-timesyncd-shared" to build a statically linked
systemd-timesyncd by using
-Dlink-udev-shared=false -Dlink-timesyncd-shared=false
on systems with full systemd stack except systemd-timesyncd, such
as RHEL/CentOS 8.
Fixes systemd build in Fedora rawhide.
The old ldsdir option is not useful, because both the directory and the
file name changed. Let's remove the option and try to autodetect the file
name. If this turns out to be not enough, a new option to simply specify
the full path to the file can be added.
F31:
efi arch: x86_64
EFI machine type: x64
EFI CC ccache cc
EFI lds: /usr/lib64/gnuefi/elf_x64_efi.lds
EFI crt0: /usr/lib64/gnuefi/crt0-efi-x64.o
EFI include directory: /usr/include/efi
F32:
efi arch: x86_64
EFI machine type: x64
EFI CC ccache cc
EFI lds: /usr/lib/gnuefi/x64/efi.lds
EFI crt0: /usr/lib/gnuefi/x64/crt0.o
EFI include directory: /usr/include/efi
Build option "link-networkd-shared" to build a statically linked
systemd-networkd by using
-Dlink-udev-shared=false -Dlink-networkd-shared=false
on systems with full systemd stack except systemd-networkd, such
as RHEL/CentOS 8.
This partially reverts db11487d10 (the logic to
calculate the correct value is removed, we always use the same setting as for
the system manager). Distributions have an easy mechanism to override this if
they wish.
I think making this configurable is better, because different distros clearly
want different defaults here, and making this configurable is nice and clean.
If we don't make it configurable, distros which either have to carry patches,
or what would be worse, rely on some other configuration mechanism, like
/etc/profile. Those other solutions do not apply everywhere (they usually
require the shell to be used at some point), so it is better if we provide
a nice way to override the default.
Fixes #13469.
As discussed on systemd-devel [1], in Fedora we get lots of abrt reports
about the watchdog firing [2], but 100% of them seem to be caused by resource
starvation in the machine, and never actual deadlocks in the services being
monitored. Killing the services not only does not improve anything, but it
makes the resource starvation worse, because the service needs cycles to restart,
and coredump processing is also fairly expensive. This adds a configuration option
to allow the value to be changed. If the setting is not set, there is no change.
My plan is to set it to some ridiculusly high value, maybe 1h, to catch cases
where a service is actually hanging.
[1] https://lists.freedesktop.org/archives/systemd-devel/2019-October/043618.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1300212
This patch introduces the systemd pstore service which will archive the
contents of the Linux persistent storage filesystem, pstore, to other storage,
thus preserving the existing information contained in the pstore, and clearing
pstore storage for future error events.
Linux provides a persistent storage file system, pstore[1], that can store
error records when the kernel dies (or reboots or powers-off). These records in
turn can be referenced to debug kernel problems (currently the kernel stuffs
the tail of the dmesg, which also contains a stack backtrace, into pstore).
The pstore file system supports a variety of backends that map onto persistent
storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI
variables[3 Appendix N Common Platform Error Record]. The pstore backends
typically offer a relatively small amount of persistent storage, e.g. 64KiB,
which can quickly fill up and thus prevent subsequent kernel crashes from
recording errors. Thus there is a need to monitor and extract the pstore
contents so that future kernel problems can also record information in the
pstore.
The pstore service is independent of the kdump service. In cloud environments
specifically, host and guest filesystems are on remote filesystems (eg. iSCSI
or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation
of networking software *and* hardware *and* infrastructure. Thus it may not be
possible to capture a kernel coredump to a file since writes over the network
may not be possible.
The pstore backend, on the other hand, is completely local and provides a path
to store error records which will survive a reboot and aid in post-mortem
debugging.
Usage Notes:
This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore.
To enable kernel recording of error records into pstore, one must either pass
crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y
> /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option
invokes the recording of errors into pstore *before* an attempt to kexec/kdump
on a kernel crash.
Optionally, to record reboots and shutdowns in the pstore, one can either pass
the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y >
/sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the
shutdown path to record information via pstore.
This pstore service is a oneshot service. When run, the service invokes
systemd-pstore which is a tool that performs the following:
- reads the pstore.conf configuration file
- collects the lists of files in the pstore (eg. /sys/fs/pstore)
- for certain file types (eg. dmesg) a handler is invoked
- for all other files, the file is moved from pstore
- In the case of dmesg handler, final processing occurs as such:
- files processed in reverse lexigraphical order to faciliate
reconstruction of original dmesg
- the filename is examined to determine which dmesg it is a part
- the file is appended to the reconstructed dmesg
For example, the following pstore contents:
root@vm356:~# ls -al /sys/fs/pstore
total 0
drwxr-x--- 2 root root 0 May 9 09:50 .
drwxr-xr-x 7 root root 0 May 9 09:50 ..
-r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001
-r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001
-r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001
-r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001
-r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001
-r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001
-r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001
-r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001
-r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001
-r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001
-r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001
-r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001
-r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001
-r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001
-r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001
results in the following:
root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/
total 92
drwxr-xr-x 2 root root 4096 May 9 09:50 .
drwxr-xr-x 4 root root 40 May 9 09:50 ..
-rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001
-rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001
-rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001
-rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001
-rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001
-rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001
-rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001
-rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001
-rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001
-rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001
-rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001
-rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001
-rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001
-rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001
-rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001
-rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt
where dmesg.txt is reconstructed from the group of related
dmesg-efi-155741337* files.
Configuration file:
The pstore.conf configuration file has four settings, described below.
- Storage : one of "none", "external", or "journal". With "none", this
tool leaves the contents of pstore untouched. With "external", the
contents of the pstore are moved into the /var/lib/systemd/pstore,
as well as logged into the journal. With "journal", the contents of
the pstore are recorded only in the systemd journal. The default is
"external".
- Unlink : is a boolean. When "true", the default, then files in the
pstore are removed once processed. When "false", processing of the
pstore occurs normally, but the pstore files remain.
References:
[1] "Persistent storage for a kernel's dying breath",
March 23, 2011.
https://lwn.net/Articles/434821/
[2] "Advanced Configuration and Power Interface Specification",
version 6.2, May 2017.
https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
[3] "Unified Extensible Firmware Interface Specification",
version 2.8, March 2019.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
[4] "The kernel’s command-line parameters",
https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
Some distros install nologin as /usr/sbin/nologin, others as
/sbin/nologin.
Since we can't really on merged-usr everywhere (where the path wouldn't
matter), make the path build time configurable via -Dnologin-path=.
Closes#13028
Not everybody has those dirs in the filesystem (and they don't need to).
When creating an installation package using $DESTDIR, it is easy enough to
remove or ignore those directories, but if installing into a real root, it
is ugly to create and remove them. Let's add an option so people can skip
it if they want.
Inspired by #12930.
This makes the default build much quicker. If people are building systemd for
packaging or actual installation, they probably need to set some more options
anyway (-Ddns-servers=, -Dntp-servers=), so adding -Dman=true is not a big
burden.
For CIs configured locally, -Dman=true is added to restore status quo ante.
Daan De Meyer