The variable is not useful outside of the loop (it'll always be null
after the loop is finished), so we can declare it inline in the loop.
This saves one variable declaration and reduces the chances that somebody
tries to use the variable outside of the loop.
For consistency, 'de' is used everywhere for the var name.
This was an undocumented change in behavior introduced by
9e82a74cb0. Previously, we only
checked for "Default" if we didn't find a machine ID. Let's make
sure we keep the previous behavior intact.
We get "upstream" dns server config from ~three places: /etc/resolv.conf,
config files, and runtime config via dbus. With this commit, we'll filter out
our own stub listeners if they are configured in either of the first two
sources. For /etc/resolv.conf this is done quitely, and for our own config
files, a LOG_INFO message is emitted, since this is a small inconsistency in
the config.
Setting loops like this over dbus is still allowed. The reason is that in the
past we didn't treat this as an error, and if we were to start responding with
an error, we could break a scenario that worked previously. E.g. NM sends us a
list of servers, and one happens to be the our own. We would just not use that
stub server before, but it'd still be shown in the dbus properties and such.
We would have to return error for the whole message, also rejecting the other
valid servers. I think it's easier to just keep that part unchanged.
Test case:
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 57 Dec 15 10:26 /etc/resolv.conf
$ cat /etc/resolv.conf
nameserver 192.168.150.1
options edns0 trust-ad
search .
$ cat /etc/systemd/resolved.conf.d/stub.conf
[Resolve]
DNSStubListenerExtra=192.168.150.1
$ resolvectl
...
Global
resolv.conf mode: foreign
DNS Servers: 192.168.150.1
Fallback DNS Servers: ...
(with the patch):
Global
resolv.conf mode: foreign
Fallback DNS Servers: ...
The message that the "journal begins … ends …" has been always confusing to
users. (Before b91ae210e6 it was "logs begin … end …" which was arguably even
more confusing, but really the change in b91ae210e6 didn't substantially change
this.)
When the range shown is limited (by -e, -f, --since, or other options), it
doesn't really matter to the user what the oldest entries are, since they are
purposefully limiting the range. In fact, if we are showing the last few
entries with -e or -f, knowing that many months the oldest entries have is
completely useless.
And when such options are *not* used, the first entry generally corresponds to
the beginning of the range shown, and the last entry corresponds to the end of
that range. So again, it's not particularly useful, except when debugging
journalctl or such. Let's just treat it as a debug message.
Fixes#21491.
The idea is to be able to distinguish whether we're in a VM/container or something
more substantial at a glance.
Chassis: laptop 💻
Chassis: tablet 具
Chassis: vm 🖴
Chassis: server 🖳
Chassis: handset 🕻
Chassis: watch ⌚
Chassis: desktop 🖥
Chassis: container ☐
systemd-analyze critical-chain accepts an optional unit argument,
however currently there's no shell-completion for it
This change provides unit name completion for both bash and zsh.
Closes: #20927
Build option "link-boot-shared" to build a statically linked bootctl and
systemd-bless-boot by using
-Dlink-boot-shared=false
on systems with full systemd stack except bootctl and systemd-bless-boot,
such as CentOS/RHEL 9.
This description will help users who are trying to reset the already configured
CPUQuota= by trying incorrect ways such as CPUQuota=0 or CPUQUota=infinity.
Commit 49ef064c8d attempts to handle
"stub loop" by switching to the next server *after the query has
been made*.
The approach may be good enough for link scopes. However, for the
manager / global scope, it is not. First of all, there are more than
one types (SYSTEM and FALLBACK) of servers it can use. Also, whether
those of type FALLBACK should be used depends.
Besides, dns_scope_good_domain() determines whether things should
be routed to a scope by checking whether the scope has a server.
The decision made would be incorrect if stubs were not filtered
beforehand.
Therefore, to avoid failing query unnecessarily, and to make sure
that extra stub listeners will not trigger unexpected and/or
inconsistent behavior, make manager_get_dns_server() do what it
should have done.
When a service exits and triggers either an OnFailure= or OnSuccess=
dependency we now set a new environment variable for the ExecStart= and
ExecStartPre= process. This variable $MONITOR_METADATA exposes the
metadata relating to the service which triggered the dependency.
MONITOR_METADATA takes the following form:
MONITOR_METADATA="SERVICE_RESULT=<result-string0>,EXIT_CODE=<exit-code0>,EXIT_STATUS=<exit-status0>,INVOCATION_ID=<id>,UNIT=<triggering-unit0.service>;SERVICE_RESULT=<result-stringN>,EXIT_CODE=<exit-codeN>,=EXIT_STATUS=<exit-statusN>,INVOCATION_ID=<id>,UNIT=<triggering-unitN.service>"
MONITOR_METADATA is space separated set of metadata relating to the
service(s) which triggered the dependency. This is a list since if we
have 2 services which trigger the same dependency then the dependency
start job may be merged. In this case we need to pass both service
metadata to the triggered service. If there is no job merging then
MONITOR_METADATA will be a single entry.
For example, in the case we had a service "failer.service" which
triggers "failer-handler.service", the following variable is exported to
the ExecStart= and ExecStartPre= processes in failer-handler.service:
MONITOR_METADATA="SERVICE_RESULT=exit-code,EXIT_CODE=exited,EXIT_STATUS=1,INVOCATION_ID=67c657ed7b34466ea369abdf994c6393,UNIT=failer.service"
In another example where we have failer.service and failer2.service
which both also trigger failer-handler.service then the start job for
failer-handler.service may be merged and we might get the following:
MONITOR_METADATA="SERVICE_RESULT=exit-code,EXIT_CODE=exited,EXIT_STATUS=1,INVOCATION_ID=16a93ad196c94109990fb8b9aa5eef5f,UNIT=failer.service;SERVICE_RESULT=exit-code,EXIT_CODE=exited,EXIT_STATUS=1,INVOCATION_ID=ff70131e4cc145e994fb621de25a3e8f,UNIT=failer2.service"
TEST-67-INTEGRITY times out quite often, and when it passes
it does so a few seconds short of the timeout. It's a slow
qemu test, so bump the timeout.
TEST-50-DISSECT has been reported to fail in the same way
on Debian's infrastructure, again narrowly failing or passing
just short of the timeout.
This is a soft disable. Passing `dbus-interfaces-dir` build option
will with path or 'yes' enable exports again even when cross
compiling. (maybe your environment will allow to execute
cross compiled binaries)
Enable /dev/sgx_vepc access for the group 'sgx', which allows KVM-backed VMs
to host Intel Software Guard eXtension (SGX) enclaves. The upcoming QEMU
6.2 uses /dev/sgx_vepc to reserve portions of Enclave Page Cache (EPC) for
VMs. EPC is the reserved physical memory used for hosting enclaves.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Jayce Fayne
Luca Boccassi
Nishal Kulkarni
acsfer
Robert Scheck
Davide Cavalca
Sho Iizuka
Tom Yan
Peter Morrow
dependabot[bot]
наб
igo95862
Jarkko Sakkinen