You are not logged in.
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)
Offline
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
Offline
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.
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.
Offline
How do you launch chrome?
Are any other processes affected/unexpectedly stopped?
Do you get the same behavior w/ chromium?
Offline
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)
Offline
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?
Offline