Presently, CLI utilities such as systemctl will check whether they have a tty
attached or not to decide whether to parse /proc/cmdline or EFI variable
SystemdOptions looking for systemd.log_* entries.
But this check will be misleading if these tools are being launched by a
daemon, such as a monitoring daemon or automation service that runs in
background.
Make log handling of CLI tools uniform by never checking /proc/cmdline or EFI
variables to determine the logging level.
Furthermore, introduce a new log_setup_cli() shortcut to set up common options
used by most command-line utilities.
We don't need a seperate output parameter that is of type int. glibc() says
that the type is "unsigned", but the kernel thinks it's "int". And the
"alternative names" interface also uses ints. So let's standarize on ints,
since it's clearly not realisitic to have interface numbers in the upper half
of unsigned int range.
This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
And minor other tweaks.
For executables which take a verb, we should list the verbs first, and
then options which modify those verbs second. The general layout of
the man page is from general description to specific details, usually
Overview, Commands, Options, Return Value, Examples, References.
This removes a special case that was implemented before: if some service
was already enabled, we'd treat it as having higher priority.
From https://bugzilla.redhat.com/show_bug.cgi?id=1735584#c4:
> Setting ntp off and on should give the same result as just setting it
> on. There should be no stickiness (hidden state). It should behave like
> running an ansible role.
>
> The other service might have been enabled because no other was installed at
> the time. If I install a new NTP service with a higher priority, setting ntp
> on should enable and start the new service, and disable all other. Also, if
> for some reason multiple services are enabled, after setting ntp on there
> should be only one enabled to avoid systemd selecting between them randomly
> on the next boot.
The general idea is that for things which can occur repeatedly, like SetNTP
being called with the same argument, we only log at debug level. For things
which change state, like when we realize that a unit that wasn't enabled
before needs to be enabled, we log at info level.
Also, don't return success if there are no units loaded.
We removed support for foreign services (and ntp-units.d/) in b72ddf0f4.
Support for foreign services was added back in 5d280742, but through an
environment variable.
The problem with the env var approach is that it only works as a mechanism
to select one item, and doesn't work nicely as a mechinism to create a list
of items through drop-ins (because the env var can be easily overridden, but not
extended). Having a list of "ntp providers" is important to be able to reliably disable
all of them when that is requested.
Another problem is that nobody ever bothered to care about our new "standard".
ntp-units.d/ is a nice simple format that works and is already supported by
chrony and ntpd and timedatex. If we were to introduce and ask people to follow
a new standard, there should be some good reason for this. The idea with env
vars has lower functionality, requires systemd-specific syntax. We should just
re-adopt the format that we originally introduced and that seems to work for
everyone, and more on to more interesting problems.
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.
When `timedatectl set-time` is called, NTP client may be in
'activating' or something. For safety, let's treat such states as
'active'.
This also changes all unit file status except for 'masked' or 'disabled'
are treated as 'enabled'.
Yu Watanabe