Ultimately, O_CLOEXEC should be off in fd 0, 1, 2, but when we open
/dev/null here it's unlikely to be < 0, and after dupping the fd to 0,
1, 2 we turn off O_CLOEXEC explicitly anyway.
Unless we know that what we are about to open will return 0, 1 or 2 we
should always set O_CLOEXEC in order to be safe to other threads forking
of subprocesses at the wrong moment.
Just a minor tweak, making sure we execute as much as we can of the
funciton, but return the first error instead of the last we encounter.
This is usuelly how we do things when we have functions that continue on
the first error, so let's do it like that here too.
Let's fork off sync() ina process instead of a thread, as a safety
measure. This is beneficial to ensure that the original process can exit
without having to wait for the sync() to finish (note that the kernel
will delay process termination until all threads finished their
syscalls). In case of hanging NFS this increases the chance that PID 1
can safely transition to the "systemd-shutdown" process as the sync() is
initiated early on but definitely not waited for.
on some architectures such as MIPS there are special unaligned load/store
sequences, instead of having to do bitwise accesses
https://www.linux-mips.org/wiki/Alignment
This makes things a bit easier to read I think, and also makes sure we
always use the _unlikely_ wrapper around it, which so far we used
sometimes and other times we didn't. Let's clean that up.
Followup to previous commit. Suggested by @poettering.
Reindented the `verbs[]` tables to match the apparent previous
whitespace rules (indent to one flag, allow multiple flags to overflow?).
A lot of code references the `running_in_chroot()` function; while
I didn't dig I'm pretty certain this arose to deal with situations
like RPM package builds in `mock` - there we don't want the `%post`s
to `systemctl start` for example.
And actually this exact same use case arises for
[rpm-ostree](https://github.com/projectatomic/rpm-ostree/)
where we implement offline upgrades by default; the `%post`s are
always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap).
And here's the problem: bwrap creates proper mount roots, so it
passes `running_in_chroot()`, and then if a script tries to do
`systemctl start` we get:
`System has not been booted with systemd as init system (PID 1)`
but that's an *error*, unlike the `running_in_chroot()` case where we ignore.
Further complicating things is there are real world RPM packages
like `glusterfs` which end up invoking `systemctl start`.
A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was
added for the inverse case of running in a chroot, but still wanting
to use systemd as PID 1 (presumably some broken initramfs setups?).
Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like
mock/rpm-ostree so we can force on the "ignore everything except preset" logic.
This way we'll still not start services even if mock switches to use nspawn or
bwrap or something else that isn't a chroot.
We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled
`SYSTEMD_OFFLINE=0`. (Suggested by @poettering)
Also I made things slightly nicer here and we now print the ignored operation.
Remount, and subsequent umount, attempts can hang for inaccessible network
based mount points. This can leave a system in a hard hang state that
requires a hard reset in order to recover. This change moves the remount,
and umount attempts into separate child processes. The remount and umount
operations will block for up to 90 seconds (DEFAULT_TIMEOUT_USEC). Should
those waits fail, the parent will issue a SIGKILL to the child and continue
with the shutdown efforts.
In addition, instead of only reporting some additional errors on the final
attempt, failures are reported as they occur.
These helper calls are potentially called often, and allocate FILE*
objects internally for a very short period of time, let's turn off
locking for them too.
Let's replace usage of fputc_unlocked() and friends by __fsetlocking(f,
FSETLOCKING_BYCALLER). This turns off locking for the entire FILE*,
instead of doing individual per-call decision whether to use normal
calls or _unlocked() calls.
This has various benefits:
1. It's easier to read and easier not to forget
2. It's more comprehensive, as fprintf() and friends are covered too
(as these functions have no _unlocked() counterpart)
3. Philosophically, it's a bit more correct, because it's more a
property of the file handle really whether we ever pass it on to another
thread, not of the operations we then apply to it.
This patch reworks all pieces of codes that so far used fxyz_unlocked()
calls to use __fsetlocking() instead. It also reworks all places that
use open_memstream(), i.e. use stdio FILE* for string manipulations.
Note that this in some way a revert of 4b61c87511.
fputs() writes only first 2048 bytes and fails
to write to /proc when values are larger than that.
This patch adds a new flag to WriteStringFileFlags
that make it possible to disable the buffer under
specific cases.
This commit updates networkd behavior to check if the hostname option
received via DHCP is too long for Linux limit, and in case shorten it.
An overlong hostname will be truncated to the first dot or to
`HOST_MAX_LEN`, whatever comes earlier.
Add a new option `--network-namespace-path` to systemd-nspawn to allow
users to specify an arbitrary network namespace, e.g. `/run/netns/foo`.
Then systemd-nspawn will open the netns file, pass the fd to
outer_child, and enter the namespace represented by the fd before
running inner_child.
```
$ sudo ip netns add foo
$ mount | grep /run/netns/foo
nsfs on /run/netns/foo type nsfs (rw)
...
$ sudo systemd-nspawn -D /srv/fc27 --network-namespace-path=/run/netns/foo \
/bin/readlink -f /proc/self/ns/net
/proc/1/ns/net:[4026532009]
```
Note that the option `--network-namespace-path=` cannot be used together
with other network-related options such as `--private-network` so that
the options do not conflict with each other.
Fixes https://github.com/systemd/systemd/issues/7361
Using strlen() to declare a buffer results in a variable-length array,
even if the compiler likely optimizes it to be a compile time constant.
When building with -Wvla, certain versions of gcc complain about such
buffers. Compiling with -Wvla has the advantage of preventing variably
length array, which defeat static asserts that are implemented by
declaring an array of negative length.
While the compiler likely optimizes strlen(x) for string literals,
it is not a constant expression.
Hence,
char buffer[strlen("OPTION_000") + 1];
declares a variable-length array. STRLEN() can be used instead
when a constant espression is needed.
It's not entirely identical to strlen(), as STRLEN("a\0") counts 2.
Also, it only works with string literals and the macro enforces
that the argument is a literal.
Our CODING_STYLE suggests not comparing with NULL, but relying on C's
downgrade-to-bool feature for that. Fix up some code to match these
guidelines. (This is not comprehensive, the coccinelle output for this
is unfortunately kinda borked)
The detection of ConditionVirtualisation= relies on the presence of
/proc/xen/capabilities. If the file exists and contains the string
"control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
be set. In case /proc/xen exists, or some sysfs files indicate "xen",
VIRTUALIZATION_XEN should be set to indicate the system is a domU.
With an (old) xenlinux based kernel, /proc/xen/capabilities is always
available and the detection described above works always. But with a
pvops based kernel, xenfs must be mounted on /proc/xen to get
"capabilities". This is done by a proc-xen.mount unit, which is part of
xen.git. Since the mounting happens "late", other units may be scheduled
before "proc-xen.mount". If these other units make use of
"ConditionVirtualisation=", the virtualization detection returns
incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
is found in sysfs. This value will be cached. Once xenfs is mounted, the
next process that runs detect_vm() will get VIRTUALIZATION_NONE.
This misdetection can be fixed by using
/sys/hypervisor/properties/features, which exports the value returned by
the "XENVER_get_features" hypercall. If the bit XENFEAT_dom0 is set, the
domain is the "hardware domain". It is supposed to have permissions to
access all hardware. The used sysfs file is available since v2.6.31.
The commonly used term "dom0" refers to the control domain which runs
the toolstack and has access to all hardware. But the virtualization
host may be configured such that one dedicated domain becomes the
"hardware domain", and another one the "toolstack domain".
Update detect_vm_xen_dom0 to propagate errors in case reading
/proc/xen/capabilites fails. This does not fix any bugs, it just makes
it consistent with other functions called by detect_vm.
The file /proc/xen/capabilities is only available if xenfs is mounted.
With a classic xenlinux based kernel that file is available
unconditionally. But with a modern pvops based kernel, xenfs must be
mounted before the "capabilities" may appear. xenfs is mounted very late
via .services files provided by the Xen toolstack. Other units may be
scheduled before xenfs is mounted, which will confuse the detection of
VIRTUALIZATION_XEN.
In all Xen enabled kernels, and if that kernel is actually running on
the Xen hypervisor, the "/proc/xen" directory is the reliable indicator
that this instance runs in a "Xen guest".
Adjust the code to check for /proc/xen instead of
/proc/xen/capabilities.
Fixes commit 3f61278b5 ("basic: Bugfix Detect XEN Dom0 as no virtualization")
Lennart Poettering
Susant Sahani
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Shawn Landden
Henrik Grindal Bakken
Colin Walters
Kyle Walker
Tiago Salem Herrmann
Luca Bruno
Dongsu Park
Thomas Haller
Olaf Hering