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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
This makes the ask-password agent handling more alike the polkit agent
handling again, and introduces ask_password_agent_open_if_enabled() that
works just like the already existing polkit_agent_open_if_enabled().
The commit:
a3fc6b55ac nspawn: mask out CAP_NET_ADMIN again if settings file turns off private networking
turned off the CAP_NET_ADMIN capability whenever no private networking
feature was enabled. This broke configurations where the CAP_NET_ADMIN
capability was explicitly requested in the configuration.
Changing the order of evalution here to allow the Capability= setting
to overrule this implicit setting:
Order of evaluation:
1. if no private network setting is enabled, CAP_NET_ADMIN is removed
2. if a private network setting is enabled, CAP_NET_ADMIN is added
3. the settings of Capability= are added
4. the settings of DropCapability= are removed
This allows the fix for #11755 to be retained and to still allow the
admin to specify CAP_NET_ADMIN as additional capability.
Fixes: a3fc6b55acFixes: #13995
We set ProtectKernelLogs=yes on all long running services except for
udevd, since it accesses /dev/kmsg, and journald, since it calls syslog
and accesses /dev/kmsg.
If we fail to start polkit, we get a message like
"org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.",
which has no meaning for the caller of our StartUnit method. Let's just
return -EACCES.
$ systemctl start apache
Failed to start apache.service: Could not activate remote peer. (before)
Failed to start apache.service: Access denied (after)
Fixes#13865.
We currently use the host's kernel and initramfs in our QEMU tests.
If the host is running on an encrypted LUKS partition, then the initramfs
will have a crypttab setup looking for the particular root disk it needs to
encrypt before booting into the system.
However, this disk obviously doesn't exist in our QEMU VM, so it turns out
our tests end up waiting for this device to become available, which will
never actually happen, and boot hangs for 90s until that service times out.
[*** ] A start job is running for /dev/disk/by-uuid/01234567-abcd-1234-abcd-0123456789ab (20s / 1min 30s)
In order to prevent this issue, let's pass "rd.luks=0" to disable LUKS in
the initramfs only as part of our default kernel command-line in our QEMU
tests.
This is enough to disable this behavior and prevent the timeout, while at
the same time doesn't conflict with our tests that actually check for LUKS
behavior in the systemd running under test (such as TEST-02-CRYPTSETUP).
Tested: `sudo make -C TEST-02-CRYPTSETUP/ clean setup run`
DNSOverTLS in strict mode (value yes) does check the server, as it is said in
the first few lines of the option documentation. The check is not performed in
"opportunistic" mode, however, as that is allowed by RFC 7858, section "4.1.
Opportunistic Privacy Profile".
> With such a discovered DNS server, the client might or might not validate the
> resolver. These choices maximize availability and performance, but they leave
> the client vulnerable to on-path attacks that remove privacy.
This partially reverts db11487d10 (the logic to
calculate the correct value is removed, we always use the same setting as for
the system manager). Distributions have an easy mechanism to override this if
they wish.
I think making this configurable is better, because different distros clearly
want different defaults here, and making this configurable is nice and clean.
If we don't make it configurable, distros which either have to carry patches,
or what would be worse, rely on some other configuration mechanism, like
/etc/profile. Those other solutions do not apply everywhere (they usually
require the shell to be used at some point), so it is better if we provide
a nice way to override the default.
Fixes #13469.
systemd-analyze verify command now results in segmentation fault if two
consecutive non-existent unit file names are given:
# ./build/systemd-analyze a.service b.service
...<snip irrelevant part>...
Unit a.service not found.
Unit b.service not found.
Segmentation fault (core dumped)
The cause of this is a wrong handling of return value of
manager_load_startable_unit_or_warn() in verify_units() in failure case.
It looks that the current logic wants to assign the first error status
throughout verify_units() into variable r and count up variable count only when
a given unit file exists.
However, due to the wrong handling of the return value of
manager_load_startable_unit_or_warn() in verify_units(), the variable count is
unexpectedly incremented even when there is no such unit file because the
variable r already contains non-zero value in the 2nd failure, set by the 1st
failure, and then the condition k < 0 && r == 0 evaluates to false.
This commit fixes the wrong handling of return value of
manager_load_startable_unit_or_warn() in verify_units().
I added a fairly vague entry to docs/ENVIRONMENT because I think it is worth
mentioning there (in case someone is looking for any environment variable that
might be relevant).
Initially I thought this is a good idea, but when reviewing a different PR
(https://github.com/systemd/systemd/pull/13862#discussion_r340604313) I changed
my mind about this. At some point we probably should start warning about the
old option name, and yet later remove it. But it'll make it easier for people
to transition to the new option name if there's a period of support for both
names without any fuss. There's nothing particularly wrong about the old name,
and there is no support cost.
Fixes#13919 (by avoiding the issue completely).
