[lxc-devel] update from LXC 1.1.5 to 2.0.7: command hangs

Thomas Jarosch thomas.jarosch at intra2net.com
Thu Feb 2 11:07:19 UTC 2017


On Wednesday, 1. February 2017 23:31:36 Christian Brauner wrote:
> This is likely not lxc-attach's fault. It seems that timeout is sending
> SIGTTOU to the process it monitors. If you send this to a tty it will
> stop until it receives a continue signal. So this behaviour is, I'd
> argue, correct. Newer versions of lxc-attach allocate a tty whenever they
> can to prevent various known exploits when setns()ing to a container's
> namespaces. This change has indeed been introduced with LXC 2.*.*.

The SIGTTOU signal is sent by the kernel if the "TOSTOP" flag is enabled
on the tty and a process in the background tries to write to it.

It seems to be that the initialization of the tty counts as write operation.
(IMHO this is correct). ioctl() gets interrupted during tty
configuration by the SIGTTOU signal, the signal handler is executed and
then ioctl() tries again. This fires the signal handler again.
-> endless loop

coreutil's timeout command sets the SIGTTOU signal
handler back to the default handler before execvp() "lxc-attach".
I quickly tried to clear the "TOSTOP" flag in console.c of lxc-attach,
but that didn't work since it's a write the TTY.

Perhaps it would make sense to clean up the signal
handler for SIGTTOU in lxc-attach before configuring the TTY?

timeout.c in coreutils documents this:
----------
      /* exec doesn't reset SIG_IGN -> SIG_DFL.  */
      signal (SIGTTIN, SIG_DFL);
      signal (SIGTTOU, SIG_DFL);

      execvp (argv[0], argv)
----------

-> so it might make sense to ensure a sane
signal handler environment on lxc-attach startup.

Thoughts?

Cheers,
Thomas



More information about the lxc-devel mailing list