A problem with the function recvtty

[g0dA]

runc/tty.go

Line 102 in 0c0ec3f

func (t *tty) recvtty(socket *os.File) (Err error) {

lang@g0dA$ cat test.sh
#!/bin/bash
timeout -s "KILL" 5 runc exec -t test whoami

lang@g0dA$ sudo bash test.sh
lang
a.sh：line 2: 344235 Killed               timeout -s "KILL" 5 runc exec -t test whoami

if run CLI in shell script, recvtty will not return, The code logic will hang when executing tty.Close()

runc/tty.go

Line 185 in 0c0ec3f

_ = t.hostConsole.Reset()

[kolyshkin]

Alas, timeout messes with runc terminal. From info timeout:

‘--foreground’
     Don’t create a separate background program group, so that the
     managed COMMAND can use the foreground TTY normally.  This is
     needed to support timing out commands not started directly from an
     interactive shell, in two situations.
       1. COMMAND is interactive and needs to read from the terminal for
          example
       2. the user wants to support sending signals directly to COMMAND
          from the terminal (like Ctrl-C for example)

     Note in this mode of operation, any children of COMMAND will not be
     timed out.  Also SIGCONT will not be sent to COMMAND, as it’s
     generally not needed with foreground processes, and can cause
     intermittent signal delivery issues with programs that are monitors
     themselves (like GDB for example).

If you use this option, it works as expected.

[kolyshkin]

Basically, you can not run processes that require a terminal via timeout (without --foreground, that is).

I am not sure if there's a way for runc to detect this and bail out (because currently it is bombarded with SIGTTIN and eats 100% CPU).

What happens is timeout makes runc a background process. When a background process tries to read (and runc tries to read in

runc/tty.go

Line 129 in 0c0ec3f

go func() { _, _ = io.Copy(epollConsole, os.Stdin) }()

), it receives SIGTTIN (sent by the kernel). This signal is ignored, and read(2) returns EINTR, thus it is restarted.

As a result of all that, we have a mess of several goroutines using all CPU available.

This is caused by the fact that runc exec wants to catch and forward all the signals, including SIGTTIN and SIGTTOU.

From os/signal doc:

Notify disables the default behavior for a given set of asynchronous
signals and instead delivers them over one or more registered
channels. Specifically, it applies to the signals SIGHUP, SIGINT,
SIGQUIT, SIGABRT, and SIGTERM. It also applies to the job control
signals SIGTSTP, SIGTTIN, and SIGTTOU, in which case the system
default behavior does not occur.

(the default behavior is to stop the program, same as for SIGSTOP).

Frankly, I don't know what to do. If we choose to not change the default for SIGTTIN/SIGTTOU, runc will just be stopped.

I took a look at crun, and it handles all this in a single process, listening to events, including signals, via epoll and signalfd. Because reading is prepended by epoll_wait, it just works...

[g0dA]

Yes you are right，but i am not sure if there are other ways of using it that would make runc a background process，so i use a tmpporary way to avoid this problem

I set a state in tty struct and will be set to true when the recvtty func returns , such as

func (t *tty) recvtty(socket *os.File) (Err error) {
    defer func() {
        t.state = true
    }()

Then it will be judged in the Close()，if runc is a background process the state is false, so tty can be closed directly without reset

func (t *tty) Close() error {
    ......
    if !t.state {
        t.stdin.Close()
        return nil
    }

But i didn't think about the issues related to resource release and signal processing，so maybe i can actively wait for a good solution

good luck : )