We had 'calendar' and 'timespan', but the third one was missing.
Also consistently order the verbs as calendar/timestamp/timespan in help.
The output from 'timespan' is highlighted more.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1711065.
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
[zj: this is a subset of changes generated by clang-format, just the ones
I think improve readability or consistency.]
This is a part of https://github.com/systemd/systemd/pull/11811.
With multiple iterations, I found it hard to pick out the interesting bits in
the column of text. I tried plain highlighting first, but it doesn't seem
enough. But blue/yellow makes it easy to jump to the right iteration.
This was intended to be just a refactoring, but it also fixes a minor bug:
after printing "never", we would skip subsequent expressions:
$ systemd-analyze calendar --iterations=20 @0 @1
systemd-analyze calendar --iterations=20 @0 @1
Original form: @0
Normalized form: 1970-01-01 00:00:00 UTC
Next elapse: never
(the second expression was skipped).
Fixes#10256.
What works:
systemd-analyze cat-config systemd/system-preset
systemd-analyze cat-config systemd/user-preset
systemd-analyze cat-config tmpfiles.d
systemd-analyze cat-config sysusers.d
systemd-analyze cat-config systemd/sleep.conf
systemd-analyze cat-config systemd/user.conf
systemd-analyze cat-config systemd/system.conf
systemd-analyze cat-config udev/udev.conf
(and other .conf files)
systemd-analyze cat-config udev/rules.d
systemd-analyze cat-config environment.d
systemd-analyze cat-config environment
Directories may be specified with the trailing dash or not.
The caveat is that for user configuration, systemd and other tools also look
at ~/.config/. It would be nice to support this, but this patch doesn't.
"cat-config --user" is rejected, and we may allow it in the future and then
extend the search path with directories under ~/.config.
What doesn't work (and probably shouldn't because those files cannot be
meaningfully concatenated):
systemd-analyze cat-config systemd/system (.service, .slice, .socket, ...)
systemd-analyze cat-config systemd/user
systemd-analyze cat-config systemd/network (.network, .link, and .dnssd)
The hardcoding of information about paths in this manner is a bit ugly, but
OTOH, it is not too onerous, and at least we have one place where all the
schemes are "documented" through code. It'll make us think twice before adding
yet another slightly different scheme.
$ build/systemctl --version
systemd 239-3555-g6178cbb5b5
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
$ git tag v240 -m 'v240'
$ ninja -C build
ninja: Entering directory `build'
[76/76] Linking target fuzz-unit-file.
$ build/systemctl --version
systemd 240
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
This is very useful during development, because a precise version string is
embedded in the build product and displayed during boot, so we don't have to
guess answers for questions like "did I just boot the latest version or the one
from before?".
This change creates an overhead for "noop" builds. On my laptop, 'ninja -C
build' that does nothing goes from 0.1 to 0.5 s. It would be nice to avoid
this, but I think that <1 s is still acceptable.
Fixes#7183.
PACKAGE_VERSION is renamed to GIT_VERSION, to make it obvious that this is the
more dynamically changing version string.
Why save to a file? It would be easy to generate the version tag using
run_command(), but we want to go through a file so that stuff gets rebuilt when
this file changes. If we just defined an variable in meson, ninja wouldn't know
it needs to rebuild things.
This has been irritating me for quite a while: let's prefix these enum
values with a common prefix, like we do for almost all other enums.
No change in behaviour, just some renaming.
Ideally, coccinelle would strip unnecessary braces too. But I do not see any
option in coccinelle for this, so instead, I edited the patch text using
search&replace to remove the braces. Unfortunately this is not fully automatic,
in particular it didn't deal well with if-else-if-else blocks and ifdefs, so
there is an increased likelikehood be some bugs in such spots.
I also removed part of the patch that coccinelle generated for udev, where we
returns -1 for failure. This should be fixed independently.
Pretty much everything uses just the first argument, and this doesn't make this
common pattern more complicated, but makes it simpler to pass multiple options.
This is useful for a couple of cases, I'm mostly interested in case #1:
1. Verifying "reasonable" values in a trivially scriptable way
2. Debugging unexpected time span parsing directly
Test Plan:
```
% build/systemd-analyze timespan 20
Original: 20
μs: 20
Human: 20us
% build/systemd-analyze timespan 20ms
Original: 20ms
μs: 20000
Human: 20ms
% build/systemd-analyze timespan 20z
Failed to parse time span '20z': Invalid argument
```
This is a bit like the info link in most of GNU's --help texts, but we
don't do info but man pages, and we make them properly clickable on
terminal supporting that, because awesome.
I think it's generally advisable to link up our (brief) --help texts and
our (more comprehensive) man pages a bit, so this should be an easy and
straight-forward way to do it.
On target boards without RTC, `t->kernel_time` is 0 or 1 usec.
`systemd-analyze` reads this value over D-Bus from
`org.freedesktop.systemd1.Manager`, property `KernelTimestamp`.
The issue is: if `t->kernel_time` is 0, `systemd-analyze` does not print
the kernel time:
~~~~
$ systemd-analyze
Startup finished in 1.860s (userspace) = 5.957s
~~~~
This commit fixes the misbehaviour:
~~~~
$ systemd-analyze
Startup finished in 3.866s (kernel) + 2.015s (userspace) = 5.881s
~~~~
Fixes#7721.
v2: fixes one more condition (by Yu Watanabe <watanabe.yu+github@gmail.com>)
v3: fixes one more condition (by Kirill Marinushkin <kmarinushkin@de.adit-jv.com>)
