Sudo high cpu usage after terminal is closed

[blazp7]

Describe the bug
Frequently the sudo process is left running at 100% on one cpu core, after the terminal is already closed. When i hear the cpu fans i know there is atleast one sudo that i need to kill manually.

To Reproduce
Steps to reproduce the behavior:

• in terminal for example Alacritty sudo su
• with nix temporarily download an app nix shell nixpkgs#sysbench
• kill the terminal (i close it with a Hyprland hotkey)
• sudo process now starts to run at 100% on one core

Expected behavior
sudo process doesnt torture my cpu.

Environment (please complete the following information):

• Linux distribution: NixOS 24.05.20240329.d8fe5e6 (Uakari) x86_64
• sudo-rs 0.2.2

Additional context
I use Hyprland window manager, maybe it has something to do with how it closes apps? Or maybe nix shell causes it.

[pvdrz]

@blazp7 does this happen with OG sudo as well?

Edit: I can't reproduce this while downloading a large file and killing alacritty on gnome.

[squell]

I remember we fixed this related issue during the Berlin Meeting: #263. We could also have a look at the relevant code where the potential loop might be.

Of course, @pvdrz, if we fix this we are getting really close to your favorite scenario

[squell]

Note: the example you cite is sudo su; is that our su implementation or the "regular" version? Does it also occur with say something like sudo sleep 600 or sudo yes > /dev/null?

[pvdrz]

@squell the only place where something similar could happen would be here: https://github.com/memorysafety/sudo-rs/blob/9e7a4c4fa48ec6e411e5cb3b2ae0a4258227a856/src/exec/event.rs#L222-L243

But that would mean that there aren't any file descriptors being polled or that the polling is failing consistently, which I find very unlikely as all the signal handling is done via sockets that are polled there.

[blazp7]

It seems that just exiting a terminal where sudo su is active causes this issue. I have tried multiple terminal emulators, same issue. I have tried to exit the terminal app with killall instead of hotkey, same issue. So it probably isnt Hyprland or Alacritty at fault. If you guys cant reproduce this problem i would say it has something to do with how NixOS packages the binary and wraps it in a module. Or just how NixOS is.

recording.webm

[pvdrz]

I don't seem to be able to reproduce it on my system:

[blazp7]

Note: the example you cite is sudo su; is that our su implementation or the "regular" version? Does it also occur with say something like sudo sleep 600 or sudo yes > /dev/null?

Only sudo-rs, not the regular version. And only sudo su then killing the terminal, i tried the other commands you posted. Edit: nixos uses this su implementation from here

Might or might not be relevant, dont know if this is the default behaviour but someone from nixos matrix chat said:

• Don't do sudo su. It spawns a sudo process, which then spawns a su process as root, which then spawns a shell.
• 

[squell]

(Yes, sudo -s or sudo -i is generally what you should do instead of sudo su, but that shouldn't cause this issue.)

Does it happen with sudo sudo -s as well?

[blazp7]

Does it happen with sudo sudo -s as well?

No. After i close the terminal that has an active sudo sudo -s or sudo bash every sudo process is properly closed as expected. This points to su being the culprit? However when i do su myuser there are no issues.

[squell]

I'm suspecting an interaction between util-linux nixos's su and sudo-rs based on your answers; even though su seems to trigger it, I'd say the problem lies with sudo-rs (since the child process shouldn't be able to influence it in this way).

[blazp7]

Alright, well i learned that i should use sudo -s and sudo -i, but if youre going to troubleshoot this interaction just remember that nixos uses this su implementation -> https://github.com/shadow-maint/shadow/blob/master/src/su.c

[squell]

That's very useful info (I didn't know shadow-utils also packaged a su implementation). @pvdrz