On Mo, 24.09.18 19:30, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote: > 24.09.2018 16:20, Lennart Poettering пишет: > > On So, 23.09.18 10:38, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote: > > > >> Dracut /shutdown script first tries to kill all processes still running > >> off old root. Unfortunately this fails for special user process that > >> runs bpfilter because it does not include reference to /oldroot in > >> places where dracut looks for in kilall_proc_mountpoint() > > > > Hmm, when we invoke the /shutdown executable we already executed our > > process killing spree as part of systemd-shutdown. How come your > > processes even survive that long? > > > p = procfs_file_alloca(pid, "cmdline"); > f = fopen(p, "re"); > if (!f) > return true; /* not really, but has the desired effect */ > > count = fread(&c, 1, 1, f); > > /* Kernel threads have an empty cmdline */ > if (count <= 0) > return true; > > > This process is spawned as special kernel thread, even though it is > otherwise normal user process. I am sorry, what? Are you saying there's now a third kind of task? real kernel threads, real userspace processes, and weird shit running kernel code that in turn runs userspace supplied programs, and all that under user control? If so, yuck... Under which parent PID do they show up? kthreadd or somewhere further down? Do these processes report PF_KTHREAD in /proc/$PID/stat? i.e. do they pass the recently reworked is_kernel_thread() tests? We might want to update killall.c then so that it does not make assumptions on /proc/$PID/cmdline validity anymore, but strictly uses is_kernel_thread(). That should fix things properly for you, no? That way dracut won't even see these new kind processes at all... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel