shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-01 00:51:24 +03:00
Code

core/cgroup: upgrade log level when we fail to rescope a pid

Browse Source 
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.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2021-06-30 17:17:41 +02:00
parent e8616626eb
commit 7a2ba40787
1 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/core/cgroup.c
View File

@ -2164,19 +2164,23 @@ int unit_attach_pids_to_cgroup(Unit *u, Set *pids, const char *suffix_path) {
/* First, attach the PID to the main cgroup hierarchy */
q = cg_attach(SYSTEMD_CGROUP_CONTROLLER, p, pid);
if (q < 0) {
log_unit_debug_errno(u, q, "Couldn't move process " PID_FMT " to requested cgroup '%s': %m", pid, p);
bool again = MANAGER_IS_USER(u->manager) && ERRNO_IS_PRIVILEGE(q);
if (MANAGER_IS_USER(u->manager) && ERRNO_IS_PRIVILEGE(q)) {
log_unit_full_errno(u, again ? LOG_DEBUG : LOG_INFO, q,
"Couldn't move process "PID_FMT" to%s requested cgroup '%s': %m",
pid, again ? " directly" : "", p);
if (again) {
int z;
/* If we are in a user instance, and we can't move the process ourselves due to
* permission problems, let's ask the system instance about it instead. Since it's more
* privileged it might be able to move the process across the leaves of a subtree who's
* top node is not owned by us. */
/* If we are in a user instance, and we can't move the process ourselves due
* to permission problems, let's ask the system instance about it instead.
* Since it's more privileged it might be able to move the process across the
* leaves of a subtree whose top node is not owned by us. */
z = unit_attach_pid_to_cgroup_via_bus(u, pid, suffix_path);
if (z < 0)
log_unit_debug_errno(u, z, "Couldn't move process " PID_FMT " to requested cgroup '%s' via the system bus either: %m", pid, p);
log_unit_info_errno(u, z, "Couldn't move process "PID_FMT" to requested cgroup '%s' (directly or via the system bus): %m", pid, p);
else
continue; /* When the bus thing worked via the bus we are fully done for this PID. */
}