It turns out that our man page didn't describe the handling of single-label
names almost at all. This probably adds to the confusion regarding the subject.
So let's first describe what our current implementation is doing.
Quoting https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/:
> Applications and platforms that apply a suffix search list to a single-label
> name are in conformance with IETF standards track RFCs. Furthermore,
> applications and platforms that do not query DNS for a TLD are in conformance
> with IETF standards track recommendations
Current behaviour is in line with that recommendation.
For #13763.
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.
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.
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.
Fixes: #14972
Follow-up for f92c8d1c67.
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
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.
proot provides userspace-powered emulation of chroot and mount --bind,
lending it to be used on environments without unprivileged user
namespaces, or in otherwise restricted environments like Android.
In order to achieve this, proot makes use of the kernel's ptrace()
facility, which we can use in order to detect its presence. Since it
doesn't use any kind of namespacing, including PID namespacing, we don't
need to do any tricks when trying to get the tracer's metadata.
For our purposes, proot is listed as a "container", since we mostly use
this also as the bucket for non-container-but-container-like
technologies like WSL. As such, it seems like a good fit for this
section as well.
Given that ANSI_COLOR= is mostly about branding it probably makes sense
to use RGB rather than paletted colors for them, so that the colors
match the project design as close as possible. Hence, provide a 25bit
RGB example for ANSI_COLOR, and update the overall example to something
newer.
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1823099
The wiki was primarily describing the D-Bus API, but it also had a large
introduction to the daemon functionality. I moved that latter part into
the page that describes the daemon, and the API description into the new
page.
This is mostly a straighforward import. Apart from some required formatting
changes, I removed obvious repetitions, and made tiny grammar and typo fixes
where I noticed them. The goal is not to have a perfect text immediately.
<interfacename>org.foo.bar</interface> is used for interface names,
<function>function()</function> for methods, and <function>signal</function>
(no parentheses) for signal names. In D-Bus, signals are similar to methods,
and docbook doesn't have a nice tag for them.
First After=local-fs-pre.target wasn't described in the man page although it's
part of the default dependencies automatically set by pid1.
Secondly, Before=local-fs.target was only set if the automount unit was
generated from the fstab-generator because the dep was explicitly
generated. It was also not documented as a default dependency.
Fix it by managing the dep from pid1 instead.
This patch changes the way user managers set the default umask for the units it
manages.
Indeed one can expect that if user manager's umask is redefined through PAM
(via /etc/login.defs or pam_umask), all its children including the units it
spawns have their umask set to the new value.
Hence make user units inherit their umask value from their parent instead of
the hard coded value 0022 but allow them to override this value via their unit
file.
Note that reexecuting managers with 'systemctl daemon-reexec' after changing
UMask= has no effect. To take effect managers need to be restarted with
'systemct restart' instead. This behavior was already present before this
patch.
Fixes#6077.
A warning is emitted from sd_bus_message_{get,set}_priority. Those functions
are exposed by pystemd, so we have no easy way of checking if anything is
calling them.
Just making the functions always return without doing anything would be an
option, but then we could leave the caller with an undefined variable. So I
think it's better to make the functions emit a warnings and return priority=0
in the get operation.
For whatever reason, this does not get rendered propely in the man
page and results in an invalid code:
W: manual-page-warning /usr/share/man/man7/systemd.special.7.gz 103: warning: macro `AQ' not defined
We say 'user manager' and 'system manager' in most other places, so let's just
use this form here too.
Merging by hand because github refuses merging because "Rebasing the commits of
this branch on top of the base branch cannot be performed automatically as this
would create a different result than a regular merge.".
Consumers of the sd-bus convenience API can't make convenience
helpers of their own without va_list variants.
This commit is a mechanical change splitting out the existing function
bodies into bare va_list variants having a 'v' suffixed to the names.
The original functions now simply create the va_list before forwarding
the call on to the va_list variant, and the va_list variants dispense
with those steps.
Daan De Meyer