When running a read-only file system, we might not be able to create
/var/log/journal. Do not fail on this, unless actually requested by the
--link-journal options.
$ systemd-nspawn --image=image.squashfs ...
A couple of changes:
1. Clearly name the drop-in entry files "Type #1", and the unified
kernel images "Type #2", and be clearer that the latter is specific
to UEFI.
2. Suffix all directory paths with a trailing "/" to clarify that these
are directories. Also, enclose them all in ``.
3. Add introductory paragraph that explains that there is Type #1 and
Type #2 and what they are about.
4. Explain that Type #2 is about signed UEFI SecureBoot.
5. Don't claim that $BOOT/loader/ contains really all files defined by
the spec, because that's not true, Type #2 images are not located there
after all.
Fixes: #10399
This is might be useful in some cases, but it's primarily an example for
a boot check service that can be plugged before boot-complete.target.
It's disabled by default.
All it does is check whether the failed unit count is zero
This makes two changes:
1. When called for "remove" any drop-ins with "+" suffix are removed
too, so that the logic works for entries with boot counting enabled
too and we don't lose track of configuration snippets created that
way.
2. When called for "add" we optionally generate a "+" suffix, based on
the data in /etc/kernel/tries if it exists.
This basically means after "echo 5 > /etc/kernel/tries" any installed
kernels will automatically set up for 5 boot tries before older
kernels will be tried.
This is the counterpiece to the boot counting implemented in
systemd-boot: if a boot is detected as successful we mark drop the
counter again from the booted snippet or kernel image.
When journald reaches the maximum number of active streams, it,
basically, starts to decline new connections. On the client
side it can be detected by getting EPIPE and, if the writing
process isn't lucky enough, getting SIGPIPE soon afterwards.
systemd has always ignored EPIPE, which makes it very hard
to keep track of services losing logs. This patch should make
it easier to detect such services by just staring at the logs
carefully.
In case anyone is interested, the following one-liner run as any user
can be used to paralyze all the stream logging on a machine:
for i in {1..4096}; do systemd-cat -t HEY-$i & done
Lennart Poettering