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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
See https://bugzilla.redhat.com/show_bug.cgi?id=1973058 again:
systemd[1779]: Started Application launched by gnome-session-binary.
systemd[1779]: app-glib-liveinst\x2dsetup-1897.scope: Failed to add PIDs to scope's control group: No such process
systemd[1779]: app-glib-liveinst\x2dsetup-1897.scope: Failed with result 'resources'.
systemd[1779]: Failed to start Application launched by gnome-session-binary.
systemd[1779]: app-glib-xdg\x2duser\x2ddirs-1900.scope: Failed to add PIDs to scope's control group: No such process
systemd[1779]: app-glib-xdg\x2duser\x2ddirs-1900.scope: Failed with result 'resources'.
systemd[1779]: Failed to start Application launched by gnome-session-binary.
systemd[1779]: app-gnome-gsettings\x2ddata\x2dconvert-1902.scope: Failed to add PIDs to scope's control group: No such process
systemd[1779]: app-gnome-gsettings\x2ddata\x2dconvert-1902.scope: Failed with result 'resources'.
systemd[1779]: Failed to start Application launched by gnome-session-binary.
Since we don't show the PID anywhere, it can be quite hard to figure out what
is going on. There may be logs from the pid above or below in the log, but
we have no PID number to identify them. So let's upgrade the log from
unit_attach_pids_to_cgroup() to tell us precisely which PIDs and why couldn't
be handled.
See https://bugzilla.redhat.com/show_bug.cgi?id=1973058:
we would log something like:
systemd[244]: Starting willskip.service...
systemd[244]: willskip.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
systemd[244]: willskip.service: Skipped due to 'exec-condition'.
systemd[244]: Condition check resulted in willskip.service being skipped.
The line with 'Control process exited' would be at LOG_NOTICE level.
With the patch:
systemd[244]: Starting willskip.service...
systemd[244]: willskip.service: Skipped due to 'exec-condition'.
systemd[244]: Condition check resulted in willskip.service being skipped.
Debug logs:
systemd[244]: Starting willskip.service...
systemd[244]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/willskip_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=8 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
systemd[244]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/unit/willskip_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=9 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
systemd[244]: Sent message type=signal sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1/job/46 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
systemd[11020]: Skipping PR_SET_MM, as we don't have privileges.
systemd[11020]: willskip.service: Executing: sh -c 'exit 2'
systemd[244]: Received SIGCHLD from PID 11020 (sh).
systemd[244]: Child 11020 (sh) died (code=exited, status=2/INVALIDARGUMENT)
systemd[244]: willskip.service: Child 11020 belongs to willskip.service.
systemd[244]: willskip.service: Condition check process exited, code=exited, status=2/INVALIDARGUMENT (success)
systemd[244]: willskip.service: Got final SIGCHLD for state condition.
systemd[244]: willskip.service: Skipped due to 'exec-condition'.
systemd[244]: willskip.service: Service will not restart (restart setting)
systemd[244]: willskip.service: Changed condition -> dead
systemd[244]: willskip.service: Job 46 willskip.service/start finished, result=done
systemd[244]: Condition check resulted in willskip.service being skipped.
dns_resource_record_copy() assumes that NSEC types bitmap is non-empty
which results in a null pointer dereference inside bitmap_copy() in some
cases. Fix this by calling bitmap_copy() conditionally.
socket_broadcast_group_unref() is only called in netlink_slot_disconnect(),
so the assertion should not be triggered as the match slot was
successfully created.
But, we usually design `_ref/unref()` functions as they can be called
for any inputs. So, let's also follow the design rule here.
We checked the wrong field, which was always NULL here, so we would always
reject the assignment. We would also print the wrong string in the error
message:
$ sudo systemd-run --socket-property ListenFIFO=/tmp/fifo3 cat
Failed to start transient socket unit: Invalid socket path: FIFO
When an ExtensionImages= extension-release metadata does not match, the
log messages (unless debug level is set) are pretty much incomprehensible:
systemd[463]: run-u11.service: Failed to set up mount namespacing: /run/systemd/unit-extensions/0: Stale file handle
systemd[463]: run-u11.service: Failed at step NAMESPACE spawning /usr/bin/echo: Stale file handle
Add an explicit log message if we get ESTALE from the dissect code, to
make it clear what's happening without needing to enable debugging:
systemd[463]: Failed to mount image /tmp/app3.raw, extension-release metadata does not match the lower layer's: ID=debian VERSION_ID=11 SYSEXT_LEVEL=11
Only treat interface names containing dots specially when resolvectl is
pretending to be resolvconf to fix
https://github.com/systemd/systemd/issues/20014 .
Move the special suffix-stripping behaviour of ifname_mangle out to the
new ifname_resolvconf_mangle to be called from resolvconf only.
The mount option has special meaning when SELinux is enabled. To make
NoNewPrivileges=yes not break SELinux enabled systems, let's not set the
mount flag on such systems.
This reverts commit 1753d30215.
Let's re-enable that feature now. As reported when the original commit
was merged, this causes some trouble on SELinux enabled systems. So,
in the subsequent commit, the feature will be disabled when SELinux is enabled.
But, anyway, this commit just re-enable that feature unconditionally.
This fixes repart's, systemctl's, sysusers' and tmpfiles' specifier
expansion to honour the root dir specified with --root=. This is
relevant for specifiers such as %m, %o, … which are directly sourced
from files on disk.
This doesn't try to be overly smart: specifiers referring to runtime
concepts (i.e. boot ID, architecture, hostname) rather than files on the
medium are left as is. There's certainly a point to be made that they
should fail in case --root= is specified, but I am not entirely convinced
about that, and it's certainly something we can look into later if
there's reason to.
I wondered for a while how to hook this up best, but given that quite a
large number of specifiers resolve to data from files on disks, and most
of our tools needs this, I ultimately decided to make the root dir a
first class parameter to specifier_printf().
Replaces: #16187Fixes: #16183
