| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| | |
When the hostname is set through network config or such, let's
optimize things a bit by suppressing the logs and dbus notifications.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
No functional change, just moving a bunch of things around. Before
we needed a rather complicated setup to test hostname_setup(), because
the code was in src/core/. When things are moved to src/shared/
we can just test it as any function.
The test is still "unsafe" because hostname_setup() may modify the
hostname.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Various users want to know what the fallback hostname is. Since it was made
configurable in 8146c32b9264a6915d467a5cab1a24311fbede7e, we didn't expose this
nicely.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Let's clean up hostname_is_valid() a bit: let's turn the second boolean
argument into a more explanatory flags field, and add a flag that
accepts the special name ".host" as valid. This is useful for the
container logic, where the special hostname ".host" refers to the "root
container", i.e. the host system itself, and can be specified at various
places.
let's also get rid of machine_name_is_valid(). It was just an alias,
which is confusing and even more so now that we have the flags param.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Like it's customary in our codebase bus_error_message() internally takes
abs() of the passed error anyway, hence no need to explicitly negate it.
We mostly got this right, but in too many cases we didn't. Fix that.
|
| |
|
|
| |
No actual code flow changes, just a bunch of debug messages.
|
| | |
|
| | |
|
| |
|
|
| |
Just some refactoring, no code changes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
/etc/machine-info
Instead of reading these files at startup and never again, let's read
them when we need them. As an optimization (in particular as some of
these files contain the data for many fields at once) let's cache the
results as long as the stat data (i.e. mtime) remains stable.
Also, while we are at it, if we can't read any of these props, let's not
fail everything, but continue without the data.
|
| |
|
|
|
| |
Querying the current hostname is cheap, hence let's not cache it. That
way it is much less likely we'll return out-of-date data.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There's no point in caching this. Let's always get this directly from
sysfs, so that we can never get out-of-date data here (after all this is
going to be cheap, and people might overmount it or so)
|
| |
|
|
|
|
| |
Let's not cache the uname(), it's very cheap to get it, and just means
we might get out of sync with what is current. After all, the data might
change IRL, due to setarch and stuff.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
parsing stubs
--help and --version are implemented in the usual style.
help() prints full path, since the program is not expected to
be in $PATH.
|
| |\
| |
| | |
A few more dbus api documentation updates
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
It's enough, complex stuff to warrant its own source file.
No other changes, just splitting out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
This doesn't cover all the binaries, but I don't know how to script
this, and I run out of steam ;)
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
It's a special case of strjoin(), so no need to keep both. In particular
as typing strjoin() is even shoert than strappend().
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This means we need to include many more headers in various files that simply
included util.h before, but it seems cleaner to do it this way.
|
| | |
|
| |\
| |
| | |
flush nscd's caches when we register user/groups/hostnames
|
| | |
| |
| |
| | |
This way we know that nss-myhostname always serves the correct answer.
|
| |/
|
|
|
| |
These UUIDs are considered as wildcard value for "unset" UUIDs
typically, and this even makes sense. Let's suppress them hence.
|
| | |
|
| |
|
|
|
|
| |
It's quite complex, let's split this out.
No code changes, just some file rearranging.
|
| |
|
|
| |
There's no reason for doing that, hence simply don't.
|
| |
|
|
|
| |
This is high-level functionality, and fits better in shared/ (which is for
our executables), than in basic/ (which is also for libraries).
|
| |
|
|
| |
This also renames context_free() to context_clear().
|
| |
|
|
|
| |
Let's reduce the common boilerplate and have a single setup function
used by all service code to setup logging.
|
| |
|
|
|
|
|
|
|
| |
This way, we can extend the macro a bit with stuff pulled in from other
headers without this affecting everything which pulls in macro.h, which
is one of our most basic headers.
This is just refactoring, no change in behaviour, in prepartion for
later changes.
|
| | |
|
| |
|
|
| |
Let's modernize things a bit.
|
| |
|
|
|
|
|
| |
Now that we don't (mis-)use the env file parser to parse kernel command
lines there's no need anymore to override the used newline character
set. Let's hence drop the argument and just "\n\r" always. This nicely
simplifies our code.
|
