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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There is little point in logging about unmounting errors if the
exact mountpoint will be successfully unmounted in a later retry
due unmounts below it having been removed.
Additionally, don't log those errors if we are going to switch back
to a initrd, because that one is also likely to finalize the remaining
mountpoints. If not, it will log errors then.
This makes users can configure DHCPv4 client with ClientIdentifier=duid-only.
If set so, then DHCP client sends only DUID as the client identifier.
This may not be RFC compliant, but some setups require this.
Closes#7828.
I have no idea why clang doesn't do this on its own, and why clang
makes it so hard to query this path (-dumpversion returns something
unrelated...).
I know this is an ugly hack, but this is a very specialized script,
so it should be OK to make it a bit hacky.
Tested to work on Fedora (27) and Debian (unstable).
Fixes#8428.
fuzz-unit-file generated too much logs about invalid config lines. This just
slows things down and fills the logs. If necessary, it's better to rerun the
interesting cases with SYSTEMD_LOG_LEVEL=debug.
When running tests like test-unit-name, there is not point in setting
up the cgroup and signals and interacting with the environment. Similarly
when running fuzz testing of the parser.
Add new MANAGER_TEST_RUN_BASIC which takes the role of MANAGER_TEST_RUN_MINIMAL,
and redefine MANAGER_TEST_RUN_MINIMAL to just create the basic data structures.
This replaces commit 4d3900f1b7.
The underlying cause of issue #8291 has been fixed, so there is no reason
to paper over it any more.
But it might still be useful not to crash in the face of bad restart data.
That can cause several restarts, or maybe at some point an infinite loop
of restarts. Fail the start (or stop!) request, and write an error to the
system log. Each time reflects a user request where we fail to resume the
display server's access (or revoke it), and it can be useful if the log
shows the most recent one.
FDSTOREREMOVE=1 removes all fds with the specified name. And we had named
the fds after the session. Better fix that.
Closes#8344.
AFAICT there's no point providing compatibility code for this transition.
No-one would be restarting logind on a system with a GUI (where the
session devices are used), because doing so has been killing the GUI, and
even causing startup of the GUI to fail leading to a restart loop.
Upgrading logind on a running system with a GUI might start being possible
after this commit (and after also fixing the display server of your
choice).
Reproducer:
$ meson build && cd build
$ ninja
$ sudo useradd test
$ sudo su test
$ ./systemd --system --test
...
Failed to create /user.slice/user-1000.slice/session-6.scope/init.scope control group: Permission denied
Failed to allocate manager object: Permission denied
Above error message is caused by the fact that user test didn't have its
own session and we tried to set up init.scope already running as user
test in the directory owned by different user.
Let's try to setup cgroup hierarchy, but if that fails return error only
when not running in the test mode.
Fixes#8072
Some versions of asan report the following false positive
when strict_string_checks=1 is passed:
=================================================================
==3297==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f64e4090286 bp 0x7ffe46acd9a0 sp 0x7ffe46acd118 T0)
==3297==The signal is caused by a READ memory access.
==3297==Hint: address points to the zero page.
#0 0x7f64e4090285 in __strlen_sse2 (/lib64/libc.so.6+0xaa285)
#1 0x7f64e5a51e46 (/lib64/libasan.so.4+0x41e46)
#2 0x7f64e4e5e3a0 (/lib64/libglib-2.0.so.0+0x383a0)
#3 0x7f64e4e5e536 in g_dgettext (/lib64/libglib-2.0.so.0+0x38536)
#4 0x7f64e48fac5f (/lib64/libgio-2.0.so.0+0xc1c5f)
#5 0x7f64e4c03978 in g_type_class_ref (/lib64/libgobject-2.0.so.0+0x30978)
#6 0x7f64e4be9567 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x16567)
#7 0x7f64e4be9fd0 in g_object_new (/lib64/libgobject-2.0.so.0+0x16fd0)
#8 0x7f64e48fd43e in g_dbus_message_new_from_blob (/lib64/libgio-2.0.so.0+0xc443e)
#9 0x564a6aa0de52 in main ../src/libsystemd/sd-bus/test-bus-marshal.c:228
#10 0x7f64e4007009 in __libc_start_main (/lib64/libc.so.6+0x21009)
#11 0x564a6aa0a569 in _start (/home/vagrant/systemd/build/test-bus-marshal+0x5569)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xaa285) in __strlen_sse2
==3297==ABORTING
It's an external library and errors in external libraries are generally not very
useful for looking for internal bugs.
It would be better not to change the code and use standard suppression
techinques decribed at
https://clang.llvm.org/docs/AddressSanitizer.html#suppressing-reports-in-external-libraries,
but, unfortunaley, none of them seems to be able to suppress fatal errors in asan intself.
This mainly gets around a kernel bug making it possible to
have non-existent paths in /proc/self/mountinfo, but it should also
prevent flaky failures that can happen if something changes immediately
after or during reading /proc/self/mountinfo.
Closes https://github.com/systemd/systemd/issues/8286.
meson.build:2907: WARNING: Trying to compare values of different types (bool, str) using ==.
The result of this is undefined and will become a hard error in a future Meson release.
Otherwise having a .socket unit start a .service running a binary under
a chroot fails as the unit is unable to determine the SELinux label of
the binary.
When we are in late shutdown, and for whatever reason kexec fails, we should
proceed with a normal reboot. Network is down and sessions have been terminated
when we attempt to do the kexec, so rebooting normally is a better solution.
Logs from the case where the kexec kernel is not usable:
Mar 08 11:23:10 fuefi systemd[1]: Reached target Final Step.
Mar 08 11:23:10 fuefi systemd[1]: Starting Reboot via kexec...
Mar 08 11:23:10 fuefi systemctl[1480]: Cannot find the ESP partition mount point.
Mar 08 11:23:10 fuefi systemctl[1480]: Failed to load kexec kernel, continuing without.
Mar 08 11:23:10 fuefi systemd[1]: Shutting down.
... and then we proceed to do a normal reboot
Related to #7730.
We already don't allow directly opening block devices attached to the seat.
They are handled by udisks instead. Clarify the code used when restarting
logind.
