currently if a stub image is directly booted, bootctl reports:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
Let's add a StubInfo which will be displayed by bootctl too (in a later
patch).
when an image with the stub is booted directly from UEFI, bootctl status
shows this:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─n/a
```
After this change, the stub reports the image itself:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
The slightly modified review comments say that "...in theory
offsetof(DHCP6Option, data) is nicer than sizeof(DHCP6Option)
because the former removes alignment artifacts. In this
specific case there are no alignment whitespaces hence it's
fine, but out of a matter of principle offsetof() is preferred
over sizeof() in cases like this..."
Calling dhcp6_option_parse_address() will always return a value
< 0 on error even though lt_valid remains unset. This is more
than valgrind can safely detect, but let's fix the valgrind
nitpick anyway.
While fixing, use UINT32_MAX instead of ~0 on the same line.
Currently there is no way to prevent tests from building using meson.
This introduces two problems:
1) It adds a extra 381 files to compile.
2) One of these tests explicitly requires libgcrypt to be built even if systemd
is not using it.
3) It adds C++ to the requirements to build systemd.
When cross-compiling, this is uneccessary.
Testing the previous commit with `systemctl stop tmp.mount` logged the
reason for failure as expected, but unexpectedly the message was repeated
32 times.
The retry is a special case for umount; it is only supposed to cover the
case where the umount command was _successful_, but there was still some
remaining mount(s) underneath. Fix it by making sure to test the first
condition :).
Re-tested with and without a preceding `mount --bind /mnt /tmp`,
and using `findmnt` to check the end result.
That way, they're always sorted by date. I do not know how to make ZSH sort
them by PID through some option, but that doesn't seem very useful in the first
place.
An output from coredumpctl list is like
> TIME PID UID GID SIG COREFILE EXE
> Sun 2016-05-29 18:44:03 CEST 14578 1000 1000 6 none /tmp/pacaurtmp-wieland/python33/src/Python-3.3.6/python
^1 ^2 ^3 ^4 ^5
, but the previous sub() command turns that into
> TIMEPID UID GID SIG COREFILE EXE
> Sun2016-05-29 18:44:03 CEST 14578 1000 1000 6 none /tmp/pacaurtmp-wieland/python33/src/Python-3.3.6/python
^1 ^2 ^3 ^4 ^5
so the whole pipeline generated entries like
$UID:$DESCRIPTION
but that's not useful and probably not what was supposed to happen.
This now generates entries like
$PID:$DESCRIPTION
which make everything work.
Note that with this commmit, the completions will be sorted by PID by
ZSH.
Documentation - systemd.exec - strongly implies mount units get logging.
It is safe for mounts to depend on systemd-journald.socket. There is no
cyclic dependency generated. This is because the root, -.mount, was
already deliberately set to EXEC_OUTPUT_NULL. See comment in
mount_load_root_mount(). And /run is excluded from being a mount unit.
Nor does systemd-journald depend on /var. It starts earlier, initially
logging to /run.
Tested before/after using `systemctl stop tmp.mount`.
in other way we will get a warning during build:
../src/core/dbus-util.h:55:13: warning: ‘bus_set_transient_errno’
defined but not used [-Wunused-function]
int bus_set_transient_##function(
When we crash we freeze() our-self (or possibly we reboot the machine if
that is configured). However, calling pause() is very unhelpful thing to
do. We should at least continue to do what init systems being doing
since 70's and that is reaping zombies. Otherwise zombies start to
accumulate on the system which is a very bad thing. As that can prevent
admin from taking manual steps to reboot the machine in somewhat
graceful manner (e.g. manually stopping services, unmounting data
volumes and calling reboot -f).
Fixes#7783
On Linux the former is a compat alias to the latter, and that's really
weird, as inside the kernel the two are distinct. Which means we really
should stay away from it.
Let's be more restrictive when validating PID files and MAINPID=
messages: don't accept PIDs that make no sense, and if the configuration
source is not trusted, don't accept out-of-cgroup PIDs. A configuratin
source is considered trusted when the PID file is owned by root, or the
message was received from root.
This should lock things down a bit, in case service authors write out
PID files from unprivileged code or use NotifyAccess=all with
unprivileged code. Note that doing so was always problematic, just now
it's a bit less problematic.
When we open the PID file we'll now use the CHASE_SAFE chase_symlinks()
logic, to ensure that we won't follow an unpriviled-owned symlink to a
privileged-owned file thinking this was a valid privileged PID file,
even though it really isn't.
Fixes: #6632
The new --uid= switch allows selecting the UID from which the
notificaiton messages shall originate.
This is primarily useful for testing purposes, but might have other
uses.
Let's be explicit, and always send the messages from our UID and never
our EUID. Previously this behaviour was conditionalized only on whether
the PID was specified, which made this non-obvious.
