sudo has hangs on FreeBSD when use_pty is on

[squell]

On a FreeBSD box, run

for x in `seq 10`; do echo "$x "; target/debug/sudo true;done

(where you can replace true with another command, my favorite is sudo cat somefile | diff - somefile).

You'll get various hangs with sudo-rs if use_pty is enabled, which is the default.

It looks to me that if the child process finishes to quickly, the monitor process doesn't register this and forgets to reap it (turning the child into a zombie) and enters a tight busywait loop. I also notice in the dev logs that this problem seems related to setpgid returning an error code 3 ("Not found"). Although in cases where a process was executed succesfully setpgid returns error code 13 ("Permission denied"), which seems like it's not entirely right as well--but maybe that's a tangential issue.

I notice that on ogsudo, several bug reports also trickled in when @millert enabled use_pty by default as well, and this one comment seems to indicate an identical problem:

sudo-project/sudo#258 (comment)

In particular, if I change the busy-wait loop in our code from 1 microsecond to 10 microseconds (in exec/use_pty/monitor.rs) as suggested by this comment, the problem also seems to be gone. But @millert addressed this in a different way in0cb3e33444b8acb161935e4e00c337e56cf50448, as mentioned in the above issue thread.

And he had several other fixes around that time as well. I think we implemented our use_pty code pretty strictly based on sudo's use_pty code, and well before the date of september '23 (which was after our public release), so it makes sense that we need to do an update round.

I've pinged @pvdrz to also take a look at this (I hope he has time). This issue is a blocker for a release on FreeBSD, since I think we do need use_pty there as well.

[millert]

While I haven't managed to reproduce a complete hang on FreeBSD, I do see sudo-rs busy-waiting an chewing up CPU, especially on a single-core VM. It is possible that is the same underlying problem. As you say, this looks similar to what was fixed in sudo by sudo-project/sudo@0cb3e33. Some kind of interlock is probably required. In ogsudo I used the existing error pipe for this (but changed it to a bi-directional socketpair). Another option is to have the child call sigsuspend() and use a signal from the parent to wake it up after the foreground process group has been setup.

[squell]

Using a single-core VM/VPS seems to definitely be required for reproduction.

[millert]

If you yield instead of sleeping the problem goes away. I suppose on FreeBSD a short sleep must not always cause the process to yield the CPU. In my testing #1017 fixes the problem.

[squell]

I would be interested to know if changing sleeping 1us to simply yielding to the scheduler has any other noticeable impact in a multiprocessor setup, but I'll run some tests tomorrow. In the worst case we could:

• do both a sleep and a yield
• do a yield on FreeBSD and a sleep on Linux

If anything bad is discovered or pvdrz still wants to do a more thorough update or our monitor code we can always re-open; but I like the minimality of the change in #1017.