| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Also includes the issues pointed out by @boucman.
|
|
|
|
|
|
| |
Fixes #2562.
v2: the erroneous part about CAP_SYS_ADMIN is removed
|
| |
|
|
|
|
| |
Partially fixes #1042.
|
| |
|
|
|
|
| |
Co-Authored-By: Daan De Meyer <daan.j.demeyer@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|\
| |
| | |
systemctl --property-value as shortcut for --property --value
|
| | |
|
|\ \
| | |
| | | |
Three unrelated minor tweaks
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Clearly there is some confusion about the intent of this option, let's add
a short note.
https://bugzilla.redhat.com/show_bug.cgi?id=1819313
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| | | | |
| | | | | |
DHCPv6: Add support to send MUD URL
|
| | | | | |
|
| | | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
For now, this function is nearly equivalent to the si_uint64 parser, except for
an additional range check as Linux only takes 32-bit values as bitrates. In
future, this may also be used to introduce fancier bitrate config formats.
|
|\ \ \ \
| | | | |
| | | | | |
sd-bus: Add error handling info to sd_bus_add_object_vtable docs
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |_|/
| |/| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Apparently people wondered about that:
https://lists.freedesktop.org/archives/systemd-devel/2020-March/044091.html
|
| | | | |
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
DHCP4: Add support to emit and receive SMTP servers.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
log: add support for prefixing console log messages with current timestamp
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
These params are optional arg, so remove the '=' from their doc.
Also include systemd.log_location in the statement explaining they are
set to true if no argument is provided to the parameter.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This only sorts the --log-* params in order in the man page docs;
no text is added or removed or modified.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Export sd-path functions and beef up systemd-path to show more items
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also document it in the man page.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Inspired by https://lists.freedesktop.org/archives/systemd-devel/2020-March/044169.html.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We were very inconsistent in this, but in general _PATH signifies
a search path (separated with :), and _DIR signifies a single directory.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
So far we had various ad hoc APIs to query search paths:
systemd-analyze unit-paths, lookup_paths_log(), the pkgconfig file,
debug logs emitted by systemd-analyze cat-config.
But answering a simple question "what is the search path for tmpfiles,
sysusers, .network files, ..." is surprisingly hard.
I think we should have an api that makes it easy to query this. Pkgconfig is
not bad, but it is primarily a development tool, so it's not available in many
context. Also it can't provide support for paths which are influenced by
environment variables, and I'd like to be able to answer the question "what is
the search path for ..., assuming that VAR_FOO=... is set?".
Extending sd-path to support more of our internal paths seems to be most
flexible solution. We already have systemd-path which provides a nice
way to query, and we can add stuff like optional descriptions later on.
We we essentially get a nice programmatic and commmandline apis for the price
of one.
|
| | | | | | |
|