core: add debug log when a job in the activation queue is not runnable
When a job is skipped due its dependencies not being ready, log
a debug message saying what is holding it back.
This was very useful with transient units timing out to figure
out where the problem was.
Remove the artifact files indicating test result (testok, failed, and
skipped) just before running the test so we always get the latest and
most relevant result instead of incorrectly consuming previous results.
Discovered in https://github.com/systemd/systemd/pull/15378#issuecomment-616801873
Dan Streetman [Wed, 15 Apr 2020 18:40:21 +0000 (14:40 -0400)]
network: change UseGateway= default to UseRoutes= setting
Anyone previously using the UseRoutes=false parameter expected their
dhcp4-provided gateway route to be ignored, as well. However, with
the introduction of the UseGateway= parameter, this is no longer true.
In order to keep backwards compatibility, this sets the UseGateway=
default value to whatever UseRoutes= has been set to.
test: drop Disk (Size|Free|Floor|Ceiling) fields prior comparing
The disk attributes can take some time to update on certain filesystems,
so let's strip them from inputs of both `homectl` and `userdbctl` before
comparing them to avoid unexpected fails.
Also, switch from `cmp` to `diff` to make a potential test fail a bit more
debuggable.
core: add log_get_max_level check optimization in log_unit_full
Just as log_full already does, check if the log level would result in
logging immediately in the macro in order to avoid doing
unnecessary work that adds up in hot spots.
core: automatically add udev dependency for units using RootImage=
We use udev to wait for /dev/loopX devices to be fully proped hence we
need an implicit ordering dependency on it, for RootImage= to work
reliably in early boot, too.
directives.index:
- This index contains 3398 entries in 19 sections, referring to 333 individual
+ This index contains 4316 entries in 19 sections, referring to 333 individual
make-directive-index: allow variablelist to specify an element to index
This commit looks for a new "extra-ref" attribute in <variablelist>
If this attribute is specified, its content will be index as pointing to
the current man-page in systemd.directives
resolve: when the stub listener is disabled, symlink stub-resolv.conf to resolv.conf
When the stub listener is disabled, stub-resolv.conf is useless. Instead of
warning about this, let's just make stub-resolv.conf point to the private
resolv.conf file. (The original bug report asked for "mirroring", but I think
a symlink is nicer than a copy because it is easier to see that a redirection
was made.)
resolve: when writing of private resolv.confs fails, do not remove old copies
All callers ignore the return value.
This is almost entirely theoretical, since writing to /run is unlikely to
fail..., but the user is almost certainly better off keeping the old copy
around and having working dns resolution with an out-of-date dns server list
than having having a dangling /etc/resolv.conf symlink.
resolve: allow setting the log level dynamically as in pid1
This is useful to raise the log level for a single transaction or a few,
without affecting other state of the resolved as a restart would.
The log level can only be set, I didn't bother with having the ability
to restore the original as in pid1.
man: use manpages.ubuntu.com for resolvconf(8) link
Add manpages.debian.org as a man citeref "project", so we can refer to man
pages hosted there. resolvconf(8) doesn't seem to appear on any of the ones we
currently have defined.
We are doing a trick, where our man page is installed as resolvconf(1), and
we refer the reader to resolvconf(8). This can be pretty confusing, so the
least we can do is to provide a non-broken symlink ;)
v2:
- link to manpages.d.o instead of manpages.ubuntu.com, because debian is the
upstream here, and because with debian we can use /unstable/ as the version,
and ubuntu doesn't seem to have any such shortcut, so the version would need
to be periodically updated.
man: add a note that resolvconf updates /etc/resolv.conf in specific circumstances
When someone knows how the whole ecosystem works, this is understandable.
But for someone coming from a system where resolvconf updates /etc/resolv.conf
directly, this can be rather surprising.
For https://bugzilla.redhat.com/show_bug.cgi?id=1815605.
systemctl: hide first column with --plain instead of --no-legend
Hiding the first column, which may contain bullet circles, with --no-legend
is undocumented and potentially unexpected. On the other hand, not printing
bullet circles with --plain is documented so hiding the column with that
switch is sensible.
The combination "--full --no-legend --no-pager --plain" is appropriate for
automated processing of systemctl output.
ebf963c551e1077abaa5e0fa0f330e6d1c23565e changed the 'sep' argument to always
be either " " or "\n", which broke the indentation logic for the first line
in base64_append_width(). Since it now always is one character, and never NULL,
let's change the type to char and simplify the logic a bit.
test-resolve: add a bunch more packets for testing
Let's append the date to the domain in the file name, to be able
to have multiple versions for the same domain.
There is no particular rhyme or reason to the domains being used:
I just pulled a few domains that happened to be present in issues reported
on github, even though the issues were not about pretty printing.
Follow-up for fa2cf64a917d31605d40d34e98ce9e2e066064fa.
Backwards-compat is retained. A short note is added in docs, in case
people see sd_seat_can_multi_session() mentioned somewhere and wonder what
happened to it.
Also see https://github.com/systemd/systemd/pull/15337#issuecomment-610369404.
journald: add configuration option for enabling/disabling audit during journald startup
Let's make it optional whether auditing is enabled at journald start-up
or not.
Note that this only controls whether audit is enabled/disabled in the
kernel. Either way we'll still collect the audit data if it is
generated, i.e. if some other tool enables it, we'll collect it.
This clarifies some more aspects of `${FOO}` expansions in service
units, mostly trying to answer my own doubts about what happens when
the matching variable is not defined.