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.
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.
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.
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.
Fixes: #959
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.
This replaces the api export tables with updated versions, and inserts
comments for all "undocumented" items. The slow work of documented them
is left for later ;)
lxml does some formatting changes that are not significant for lxml processing,
but generate spurious difference in the diff (namely: ulinks become one-line,
and double quotes are used instead of single quotes for element attribute
values). This should be a one-time thing: subsequent renegeration should be
idempotent with regards to this.
So far the units there were being documented had only one custom interface.
But for the pid1 case, something more flexibile is needed. So let's add
an annotation in the page what we want to print, and filter in the generator.
As usual, the formatting was fixed and various obvious updates
were done, but nothing major.
I removed documentation of snapshots and related methods though.
The text in the man page provides the justification why I think this is
generally the right thing. An additional reason is that with the previous
commit (to move resolved earlier), since resolved internally implements the
same rules that nss-myhostname does, we'd have this strange inversion where
the priority of external configuration would be different in the "resolve"
path and in the fallback path.
