[SOLVED] Something started sending "SIGSTOP" to "chrome" threads

cherio · 2022-08-12 02:30:29

Since recently some of my chrome processes for no obvious reason switch status to "T - stopped by job control signal". I found that running

killall -SIGCONT chrome

resurrects it back to life without killing and restarting it. My big question is what could be sending SIGSTOP and for what reason. I have 64GB of RAM and 6 multithreaded cores and the times when SIGSTOP was sent, the workstation was mostly idle with plenty of free memory.

I need ideas regarding what could be triggering this event.

Last edited by cherio (2022-08-17 01:09:21)

seth · 2022-08-12 07:30:26

some of my chrome processes

but not all and especially not the master process?
Might be chrome itself, resting tabs for power management, see eg. https://www.tenforums.com/tutorials/146 … ost2223080

cherio · 2022-08-12 17:50:04

seth wrote:

some of my chrome processes
but not all and especially not the master process?

It is both a few (out of a dozen) individual processes representing tabs and the main process.

seth wrote:

Might be chrome itself, resting tabs for power management

Although it is certainly possible, the result was equivalent to effectively disabling itself. Some of the non-tab related processes up on the process tree were stopped, which makes me think it was an outside force.

If this was a misbehaving OOM Killer it wouldn't just send a SIGSTOP.

seth · 2022-08-12 18:34:44

How do you launch chrome?
Are any other processes affected/unexpectedly stopped?
Do you get the same behavior w/ chromium?

cherio · 2022-08-15 23:57:43

Holy cow, I nailed it down. It is reliably reproducible.

chrome is launched from XFCE keyboard mapped sequence (by xfsettingsd?).

The script that hangs chrome is also invoked via XFCE keyboard mapped sequence:

ssh nonexistent_user@real_ssh_host

After SSH starts chrome gets disabled as the main process and a few subprocesses get into "T" status.

SSH is expected to authenticate with private/public key but in this case the user is incorrect so the script hangs asking for a password without any TTY allocated.
SSH CPU spikes to 100% and at the same time ?something? somehow sends the SIGSTOP to chrome.

This happens reliably every time; chrome can also be reliably unfrozen with "killall -SIGCONT chrome"

Likely related, while running various tests I was also able to get xfce4-terminal into "T" status.

The big, big question here is probably obvious: why would ssh password prompt with no TTY send SIGSTOP to an unrelated process????????

Last edited by cherio (2022-08-16 00:01:31)

seth · 2022-08-16 07:26:30

why would ssh password prompt with no TTY send SIGSTOP to an unrelated process?

XON/XOFF flow control, the conduit is likely the shortcut daemon.
I assume chrome won't be the only affected process and if you eg. bind some xterm to the same shortcut system, you'll find it stopped as well?

Arch Linux

#1 2022-08-12 02:30:29

[SOLVED] Something started sending "SIGSTOP" to "chrome" threads

#2 2022-08-12 07:30:26

Re: [SOLVED] Something started sending "SIGSTOP" to "chrome" threads

#3 2022-08-12 17:50:04

Re: [SOLVED] Something started sending "SIGSTOP" to "chrome" threads

#4 2022-08-12 18:34:44

Re: [SOLVED] Something started sending "SIGSTOP" to "chrome" threads

#5 2022-08-15 23:57:43

Re: [SOLVED] Something started sending "SIGSTOP" to "chrome" threads

#6 2022-08-16 07:26:30

Re: [SOLVED] Something started sending "SIGSTOP" to "chrome" threads

Board footer