Arbitrary other processes hang when I "pause" one - how can I pause processes "better"/figure out how to un-deadlock?

Question

Sometimes, I'm running massive compiles (and similar) on my machine, mostly unattended. Typically, those require intervention every now and then, and this intervention requires googling. So far so good.

While running the compiles I noticed - in atop - that my main browser process (librewolf) would take between 80 - 140% CPU. Not something I'm particularly interested in happening while I want the machine to finish with some processing as quickly as possible. Since those compiles don't create huge memory pressure, I had the idea that 'pausing' the browser might be lots more convenient than quitting and restarting it every time. So, killall -STOP librewolf, and the CPU hog is gone.

Nine times out of ten, this would work perfectly great. But the other one time... weird things happen. The first one was that my telegram-desktop IM client was hanging. It'd briefly show up in atop when I activated it, but then settle back to idle, but not draw its window. More on a hunch/by accident at that time I called killall -CONT librewolf, and in that instant the Telegram client window popped up. At that time, I suspected some untoward complicity between my daily driver LibreWolf browser, and the Electron-based Telegram Desktop Client, and chalked that up to "figure this out another day".

The second weirdness is on a completely different level, though. Some while after pausing LibreWolf, the atop process running as root stopped updating. Launching another instance of atop would immediately hang. So I had a look at atop using htop, and it was showing with 100% CPU, "running". According to this and strace / /proc/<pid>/syscall etc it was not shown as being blocked in kernel code. Nonetheless, kill -9 <pid> would not get rid of it. While dealing with this and trying to figure out what was going on with my system, I happened to notice that KDE file dialogs also were behaving weirdly slow - no mouse over feedback, clicking on things/typing would eventually work after a delay. More weird still, I couldn't even losetup -d / kpartx -d a loopback-mounted disk image - all those would hang as well.

At that time, I didn't yet consider the paused LibreWolf to be the culprit - for one, I wasn't really aware that it was stopped at that particular time, and more importantly, what influence "should" one stopped (or debugged...) arbitrary user process have on the rest of the system, especially such root-only operations? Rather, while digging through this, obviously at one point I wanted to use google and, oh right, gotta killall -CONT librewolf. Oh, that's funny, now the hung atop and losetup and kpartx and so on all exit.

This is not something I can readily explain to myself based on my admittedly mid-90s BSD based "how does a Unix kernel work" knowledge. In fact, to me, it goes against one of the design principles - something an arbitrary user process can do should not effect processes of another user, let alone root, in this way. It's a local denial of service at the very least.

And, picking up from there, more usefully: How do I figure out such a situation? How would I, in a much more general situation, from "looking at" the hung atop process, systematically figure my way to finding that paused librewolf process, so that I can do something about it?

And, more useful to everyday usage still: How would I go about e.g. pausing that LibreWolf process without causing such side effects? Reading up on suggested similar questions, I'll try and see whether using the TSTP signal behaves better than STOP.

For context, this is on current gentoo Linux on amd64, running a 6.1.12 SMP PREEMPT_DYNAMIC desktop kernel.

Answer 1

Not an answer to all of my questions, but my solution to the issue at hand.

After digging around some more (and after a clean reboot, and never having paused LibreWolf) I'd see more weirdness, like again atop no longer updating and turning out to be kill -9 resistant hung under load, and kworker event threads hogging a complete core when the system was otherwise relatively idle - sometimes visibly in psi_avgs_work, other times with no stack trace (or just in worker_thread). Playing HoloCure (in wine-vanilla 7.0.1) multiple times locked up my whole system hard in a weird way - its music was still playing, but the whole system otherwise no longer reacted to anything, not even replying to pings (existing ssh sessions into the system would also freeze), or even magic-sysrq sequences(!).

On a hunch, I upgraded to kernel 6.2.1 (from 6.1.2), using the exact same kernel configuration (through make oldconfig, none of the new options looked pertinent to such issues, and I accepted what seemed sensible defaults on the few new ones). Lo and behold, everything works as I'd expect (again). Including being able to pause LW (using kill -STOP / kill -CONT) and other 'hungry' processes at will.

So, for now I'll chalk it up to kernel 6.1.2 having issues.

I'll leave this here for other folks to find who might run into something similar.

My question on how to more effectively (and less intuitively) track down the specifics of such issues still stands.