-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KillUserProcesses doesn't kill user process at logout (systemd.unified_cgroup_hierarchy=1) #3483
Comments
maybe related to #3388 (I am the author of this issue… I forget to switch github account when I created it) |
Seems like a race: nohup sleep 3600 &
sleep 10
logout Do you see |
Well, I've reproduced:
Notes:
|
So,
static void scope_sigchld_event(Unit *u, pid_t pid, int code, int status) {
/* If we get a SIGCHLD event for one of the processes we were
interested in, then we look for others to watch, under the
assumption that we'll sooner or later get a SIGCHLD for
them, as the original process we watched was probably the
parent of them, and they are hence now our children. */
unit_tidy_watch_pids(u, 0, 0);
unit_watch_all_pids(u);
/* If the PID set is empty now, then let's finish this off */
if (set_isempty(u->pids))
scope_notify_cgroup_empty_event(u);
} The problem starts here: int unit_watch_all_pids(Unit *u) {
assert(u);
/* Adds all PIDs from our cgroup to the set of PIDs we
* watch. This is a fallback logic for cases where we do not
* get reliable cgroup empty notifications: we try to use
* SIGCHLD as replacement. */
if (!u->cgroup_path)
return -ENOENT;
if (cg_unified() > 0) /* On unified we can use proper notifications */
return 0;
return unit_watch_pids_in_path(u, u->cgroup_path);
}
Later we try to remove a cgroup: 1465741918124072 "/sys/fs/cgroup/user.slice/user-1001.slice/session-16.scope" -16 (EBUSY)
0x7fe362ffed97 : rmdir+0x7/0x30 [/usr/lib64/libc-2.23.90.so]
0x560e8a95cec9 : cg_trim+0xb9/0x110 [/usr/lib/systemd/systemd]
0x560e8a9d65f2 : unit_prune_cgroup+0x62/0x150 [/usr/lib/systemd/systemd]
0x560e8a934ee8 : unit_notify+0x488/0x1190 [/usr/lib/systemd/systemd]
0x560e8a9c5701 : manager_dispatch_sigchld+0x171/0x2d0 [/usr/lib/systemd/systemd]
0x560e8a9c8809 : manager_dispatch_signal_fd.lto_priv.1049+0x999/0xa90 [/usr/lib/systemd/systemd]
0x560e8a9375a3 : source_dispatch.lto_priv.1035+0x1f3/0x350 [/usr/lib/systemd/systemd]
0x560e8a9c7466 : manager_loop+0x4c6/0xce0 [/usr/lib/systemd/systemd]
0x560e8a90e67a : main+0x2f7a/0x46e0 [/usr/lib/systemd/systemd]
0x7fe362f27481 : __libc_start_main+0xf1/0x1d0 [/usr/lib64/libc-2.23.90.so]
0x560e8a90fe2a : _start+0x2a/0x30 [/usr/lib/systemd/systemd] This fails. But we ignore it:
This is totally unrelated to #3388 |
I've prepared a fix: --- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -429,7 +429,7 @@ static void scope_sigchld_event(Unit *u, pid_t pid, int code, int status) {
unit_watch_all_pids(u);
/* If the PID set is empty now, then let's finish this off */
- if (set_isempty(u->pids))
+ if (cg_unified() <= 0 && set_isempty(u->pids))
scope_notify_cgroup_empty_event(u);
} I'm testing /* We got one SIGCHLD for the service, let's watch all
* processes that are now running of the service, and watch
* that. Among the PIDs we then watch will be children
* reassigned to us, which hopefully allows us to identify
* when all children are gone */
unit_tidy_watch_pids(u, s->main_pid, s->control_pid);
unit_watch_all_pids(u);
/* If the PID set is empty now, then let's finish this off */
if (set_isempty(u->pids))
service_notify_cgroup_empty_event(u); ) |
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Expected behaviour you didn't see
In case of bug report: Unexpected behaviour you saw
Remark
Gentoo and Archlinux build systemd with
--without-kill-user-processes
.Archlinux:
Gentoo:
I also tested on Archlinux testing with the same result.
I also test with systemd master (40652ca) (without any config option) with the same result.
I use the kernel parameter systemd.unified_cgroup_hierarchy=1.
The problem appeared when I update from 229 to 230 (I also add systemd.unified_cgroup_hierarchy=1 to my kernel parameter at the same time).
EDIT:
I just recheck, the problem disappear when I remove
systemd.unified_cgroup_hierarchy=1
from my kernel cmdline.KillUserProcesses doesn't work in combination with
systemd.unified_cgroup_hierarchy=1
.The text was updated successfully, but these errors were encountered: