the whole systemd-analyze time logic is based on the fact that monotonic
time 0 is the start of the kernel.
If the firmware does not provide a correct time, firmware_time degrades to
0, which is the start of the kernel. The diference between FinishTime and
firmware_time is thus correct.
That assumption is still true with containers, but the start time of the
kernel is not what the user expects : It's the time when the host booted.
The total is thus still correct, but highly misleading. Containers can be
easily detected (and, in fact, already are) by systemd not reporting any
kernel non-monotonic timestamp.
This patch simply avoids printing a misleading time when it can detect that
case
gcc says:
[196/1142] Compiling C object 'src/basic/basic@sta/hashmap.c.o'.
../src/basic/hashmap.c: In function ‘cachemem_maintain’:
../src/basic/hashmap.c:1913:17: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
mem->active = r = true;
^~~
which conflates two things: the first is transitive assignent a = b = c = d;
the second is assignment of the value of an expression, which happens to be a
an assignment expression here, and boolean. While the second _should_ be
parenthesized, the first should _not_, and it's more natural to understand
our code as the first, and gcc should treat this as an exception and not emit
the warning. But since it's a while until this will be fixed, let's update
our code too.
This is close to %sysusers_create_inline and %sysusers_create that we had
already, but expects a file name and uses --replace= to implement proper
priority.
This is used like:
%sysusers_create_package %{name} %SOURCE1
where %SOURCE1 is a file with called %{name}.conf that will be installed
into /usr/lib/sysusers.d/.
The tough part is that the file needs to be available before %prep,
i.e. outside of the source tarball. This is because the spec file is
parsed (and any macros expanded), before the sources are unpackaged.
v2:
- disallow the case case when --config-name= is given but there are no
positional args. Most likely this would be a user error, so at least for now
forbid it.
v3:
- replace --config-name= with --target=
- drop quotes around %1 and %2 — if necessary, the caller should add
those.
v4:
- replace --target with --replace
- add a big comment
When used in a package installation script, we want to invoke systemd-sysusers
before that package is installed (so it can contain files owned by the newly
created user), so the configuration to use is specified on the command
line. This should be a copy of the configuration that will be installed as
/usr/lib/sysusers.d/package.conf. We still want to obey any overrides in
/etc/sysusers.d or /run/sysusers.d in the usual fashion. Otherwise, we'd get a
different result when systemd-sysusers is run with a copy of the new config on
the command line and when systemd-sysusers is run at boot after package
instalation. In the second case any files in /etc or /run have higher priority,
so the same should happen when the configuration is given on the command line.
More generally, we want the behaviour in this special case to be as close to
the case where the file is finally on disk as possible, so we have to read all
configuration files, since they all might contain overrides and additional
configuration that matters. Even files that have lower priority might specify
additional groups for the user we are creating. Thus, we need to read all
configuration, but insert our new configuration somewhere with the right
priority.
If --target=/path/to/file.conf is given on the command line, we gather the list
of files, and pretend that the command-line config is read from
/path/to/file.conf (doesn't matter if the file on disk actually exists or
not). All package scripts should use this option to obtain consistent and
idempotent behaviour.
The corner case when --target= is specified and there are no positional
arguments is disallowed.
v1:
- version with --config-name=
v2:
- disallow --config-name= and no positional args
v3:
- remove --config-name=
v4:
- add --target= and rework the code completely
v5:
- fix argcounting bug and add example in man page
v6:
- rename --target to --replace
If the configuration is included in a script, this is more convient.
I thought it would be possible to use this for rpm scriptlets with
'%pre -p systemd-sysuser "..."', but apparently there is no way to pass
arguments to the executable ($1 is used for the package installation count).
But this functionality seems generally useful, e.g. for testing and one-off
scripts, so let's keep it.
There's a slight change in behaviour when files are given on the command line:
if we cannot parse them, error out instead of ignoring the failure. When trying
to parse all configuration files, we don't want to fail even if some config
files are broken, but when parsing a list of items specified explicitly, we
should.
v2:
- rename --direct to --inline
This is the first error message when running unprivileged, and the message is
unspecific, so let's at least add some logging at debug level to make this less
confusing.
The function `strv_join_quoted()` is now not used, and has a bug
in the buffer size calculation when the strings needs to escaped,
as reported in #8056.
So, let's remove the function.
Closes#8056.
On Debian/Ubuntu systems the default passwd/group files use a
slightly strange mapping. E.g. in passwd:
```
man❌6:12::/var/cache/man:/sbin/nologin
```
and in group:
```
disk❌6:
man❌12:
```
This is not supported in systemd-sysusers right now because
sysusers will not re-use an existing uid/gid in its normal
mode of operation. Unfortunately this reuse is needed to
replicate the default Debian/Ubuntu users/groups.
This commit enforces reuse when the "uid:gid" syntax is used
to fix this.
I also added a test that replicates the Debian base-passwd
passwd/group file to ensure things are ok.
Booting with `systemd.log_level=debug` and looking in `dmesg -u` showed
messages like this:
systemd[433]: Failed to add rule for system call n/a() / 156, ignoring:
Numerical argument out of domain
This commit fixes it to:
systemd[449]: Failed to add rule for system call _sysctl() / 156,
ignoring: Numerical argument out of domain
Some of the messages could be even more misleading, e.g. we were reporting
that utimensat() / 320 was skipped as non-existent on x86, when actually
the syscall number 320 is kexec_file_load() on x86 .
The problem was that syscall NRs are looked up (and correctly passed to
libseccomp) as native syscall NRs. But we forgot that when we tried to
go back from the syscall NR to the name.
I think the natural way to write this would be
seccomp_syscall_resolve_num(nr), however there is no such function.
I couldn't work out a short comment that would make this clearer. FWIW
I wrote it up as a ticket for libseccomp instead.
https://github.com/seccomp/libseccomp/issues/104
> Only system calls of the *specified* architectures will be permitted to
> processes of this unit.
(my emphasis)
> Note that setting this option to a non-empty list implies that
> native is included too.
Attempting to use "implies" in the later sentence, in a way that
contradicts the very clear meaning of the earlier sentence... it's too
much.
Technically, `data` is a sequence of bytes without a trailing zero,
so the use of `memcmp` seems to be logical here. Besides, this helps get
around a bug that makes `asan` report the false positive mentioned in
#8052.
Closes#8052.
Every place the kernel actually calls SET_NETDEV_DEVTYPE, it's adding a
piece of information that looks useful and relevant for us to use. So
let's use it when it's there.
The previous matching based on the corresponding ARPHRD didn't really
make much sense. The more sensible logic for getting a textual
representation of the link type is to see if the kernel supplies a
devtype. If it does, great. If not, then we can fall back on the ARPHRD,
as before.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Red is used for highligting, the same as grep does. Except when the line is
highlighted red already, because it has high priority, in which case plain ansi
highlight is used for the matched substring.
Coloring is implemented for short and cat outputs, and not for other types.
I guess we could also add it for verbose output in the future.
Case sensitive or case insensitive matching can be requested using
--case-sensitive[=yes|no].
Unless specified, matching is case sensitive if the pattern contains any
uppercase letters, and case insensitive otherwise. This matches what
forward-search does in emacs, and recently also --ignore-case in less. This
works surprisingly well, because usually when one is wants to do case-sensitive
matching, the pattern is usually camel-cased. In the less frequent case when
case-sensitive matching is required with an all-lowercase pattern,
--case-sensitive can be used to override the automatic logic.
This changes real_journal_next() to leverage the IteratedCache for
accelerating iteration across the open journal files.
journalctl timing comparisons with 100 journal files of 8MiB size
party to this boot:
Pre (~v235):
# time ./journalctl -b --no-pager > /dev/null
real 0m9.613s
user 0m9.560s
sys 0m0.053s
# time ./journalctl -b --no-pager > /dev/null
real 0m9.548s
user 0m9.525s
sys 0m0.023s
# time ./journalctl -b --no-pager > /dev/null
real 0m9.612s
user 0m9.582s
sys 0m0.030s
Post-IteratedCache:
# time ./journalctl -b --no-pager > /dev/null
real 0m8.449s
user 0m8.425s
sys 0m0.024s
# time ./journalctl -b --no-pager > /dev/null
real 0m8.409s
user 0m8.382s
sys 0m0.027s
# time ./journalctl -b --no-pager > /dev/null
real 0m8.410s
user 0m8.350s
sys 0m0.061s
~12.5% improvement, the benefit increases the more log files there are.
