IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The general idea is that users should be able to figure out if some option
that they see in a config file or on some internet page is something that
systemd knows about. Once users know that, yes, this was an option but has
been deprecated and removed from the documentation, it's much easier for them
to find any docs in old versions if they want to. Or to switch to something
different.
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
Let's merge the footnote with the overall explanation of where systemd
parses its options from and reword the section a bit to hopefully make
things a bit more clear.
Before this patch, there was no way to request all running user instances for
reexecuting. However this can be useful especially during package updates
otherwise user instances are never updated and keep running a potentially very
old version of the binaries.
Now assuming that we have enough priviledge, it's possible to request
reexecution of all user instances:
systemctl kill --signal=SIGRTMIN+25 "user@*.service"
Note that this request is obviously asynchronous as it relies on a
signal. Keeping "systemctl kill" as the only interface should be good enough to
make this obvious and that's the reason why another interface, such as
"systemctl --global daemon-reexec" has not been considered.
PID1 already uses SIGTERM for reexecuting hence sending it SIGRTMIN+25 is a
nop.
* Fixed typo
Before, the file claimed that some systemd units are created "from other
configuration". It should have read "from other configuration files".
Co-authored-by: Nozz <nozolo90@gmail.com>
Some extra safety when invoked via "sudo". With this we address a
genuine design flaw of sudo, and we shouldn't need to deal with this.
But it's still a good idea to disable this surface given how exotic it
is.
Prompted by #5666
I'm not sure if the LogTarget property is sufficiently general to be made into
a property that can be generally implemented. It is very closely tied to the internal
systemd logic. The other two seem fine thoough.
Add note for change of behaviour in systemd-notify, where parent pid trick
is only used when --no-block is passed, and with enough privileges ofcourse.
Also, fix a small error in systemd(1).
As usual, the formatting was fixed and various obvious updates
were done, but nothing major.
I removed documentation of snapshots and related methods though.
This adds documentation for the SYSTEMD_GENERATOR_PATH and
SYSTEMD_ENVIRONMENT_GENERATOR_PATH variables to the systemd man page
grouped with the existing SYSTEMD_UNIT_PATH.
Also added is a description about how these variables work, i.e. that a
trailing : can be used to prepend paths to the usual set.
systemd.show-status=error is useful for the case where people care about errors
only.
If people want to have a quiet boot, they most likely don't want to see all
status output even if there is a delay in boot, so make "quiet" imply
systemd.show-status=error instead of systemd.show-status=auto.
Fixes#14976.
We would flip to status=temporary mode on the first error, and then switch back
to status=auto after the initial transaction was done. This isn't very useful,
because usually all the messages about successfully started units and not
related to the original failure. In fact, all those messages most likely cause
the information about the prime error to scroll off screen. And if the user
requested quiet boot, there's no reason to think that they care about those
success messages.
Also, when logging about dependency cycles, treat this similarly to a unit
error and show the message even if the status is "soft disabled" (before we
wouldn't show it in that case).
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.
In those two pages, we need to include individual entries with xi:include to
merge the list less-variables.xml with the other entries, which is obviously
error prone. All variables are supported in both tools so add them.
This structure of the man page originates from the time when systemd was
installed on top of sysvinit systems, and users had an actual chance to
interact with the systemd binary directly. Nowadays it is almost never called
directly, so let's properly explain this in the overview.
The Options section is moved down below the kernel command line, those options
are only needed in special circumstances. Let's refer the reader to the
description of the kernel command line options, and not duplicate the
descriptions (which makes the text longer than necessary and increases chances
for discrepancies).
Systemd is also prominently used as the user manager, let's mention that in the
Overview.
While at it, use "=" only when an argument is required as we nowadays do.
It was only described in systemd(1), making it hard to discover.
Fixes#13561.
The same for $SYSTEMD_URLIFY.
I think all the tools whose man pages include less-variables.xml support
those variables.
