No TTY in snaps.

[Eric Snow]

When run in a snap, the tty command prints "not a tty". The lack of a TTY is a problem for apps that need one, like tmux. This is a similar problem to one that both LXD and docker have. See:

https://github.com/lxc/lxc/issues/554
https://github.com/docker/docker/issues/8755

The work-around identified there (use "script -qc <cmd> /dev/null") works in snaps too. The underlying cause is likely similar (see https://github.com/docker/docker/issues/8755#issuecomment-110383830).

See https://github.com/ericsnowcurrently/tmate-snap (e.g. "tmate-esnow.tty-broken" vs. "tmate-esnow.tty") for a concrete example.

[Eric Snow (ericsnowcurrently)]

Apparently this is getting worked on: https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html.

[Seth Arnold (seth-arnold)]

There's a lot of moving pieces here:

- tty(1) program
- glibc's ttyname(3) and ttyname_r(3) functions
- The host's /dev/pts/ filesystem of type devpts
- The container's /dev/pts filesystem of type devpts (do we create one? do we allow snaps to create one if they need one?)
- People expecting applications that run in the snap namespaces to still have access to terminals that are in the host's namespace

I suspect that a snap that mounts its own /dev/pts of type devpts (if snapd doesn't already do this) and then follows the usual pts(4)/pty(7) protocols for managing terminals could run e.g. xterm or sshd inside the snap and function appropriately.

Thanks

[Jamie Strandboge (jdstrand)]

@Seth

"- The container's /dev/pts filesystem of type devpts (do we create one? do we allow snaps to create one if they need one?)"

We unconditionally mount a devpts newinstance on /dev/pts and bind mount /dev/pts/ptmx on /dev/ptmx for every snap app invocation.

[Michael Vogt (mvo)]

Fwiw, https://sourceware.org/ml/libc-alpha/2016-08/msg00249.html has a proposed fix from Serge.