On Fri, May 05, 2017 at 05:04:18PM -0000, LocutusOfBorg wrote:
> >If you're referring to screen . The screen version right now with my
> >compat-layer patch applied
> >should be fully backwards compatible.
>
> so, you mean, it didn't work before and still doesn't work with older
> glibc?
TL;DR: It should all work now without any regression
potential. I tested your package with my patches
applied and it works fine inside and outside of
containers.
Additional info to summarize again what has been said in
the thread above:
1. For screen to work in containers you need a specific
patch that Serge and I have successfully pushed into
glibc upstream and which is already available in the
glibc package for Ubuntu 17.04 and 17.10.
- The glibc patch has no effect whatsoever of screen
outside of containers.
- The glibc patch is fully backwards compatible to
any program out there and does not lead to
regressions.
2. For screen to work in containers you also need the
three patches that I wrote and pushed to upstream
screen and which you now applied in your package.
Thanks for that!
- Downstream screen in {Debian,Ubuntu} communicates
using FIFOs whereas newer upstream versions of screen
use unix domain sockets. So far these two things have
been mutually exclusive. However, I wrote a compat
layer that allows screen to use both. This is my
third patch which is also available upstream
and now in your package.
3. **Orthogonal to all of this** I wanted to direct the
attention of the screen maintainers to the fact that
upstream screen uses a message protocol which is based
on C struct that is either send around via the FIFO or
the unix domain socket. This message protocol is
versioned using a simple integer numbering scheme
{1,2,3,4,5, ...}. Changing this message protocol
is essentially an ABI break if you want to call it that.
This means, clients that send a C struct using a
different version than an already running screen server
will not be able to attach to already existing sessions.
This scenario can be postponed but it will happen once
the screen 4.*.* series {Debian,Ubuntu} ends. There is
no way to fix this that I know of. I just wanted to
point this out and make the maintainers aware that
on the next possible version bump for screen it would
cause a break in backwards compatibility.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1669578
>
> Title:
> Get ttyname() to work properly in containers
>
> Status in glibc package in Ubuntu:
> Fix Released
> Status in screen package in Ubuntu:
> Fix Committed
> Status in tmux package in Ubuntu:
> Fix Released
>
> Bug description:
> For the past year or so, the LXD team has been trying to resolve an
> issue affecting screen, tmux and a bunch of other software (including
> the "tty" command).
>
> The problem comes from the fact that when attaching to a container,
> your terminal's pts device comes from the host and therefore can't be
> found in /dev/pts/.
>
> glibc makes the assumption that it can readlink /proc/self/fd/0 and
> that the target path will exist. This simply isn't true as the symlink
> target returned by the kernel, is confusingly relative to the host's
> root and not the container's.
>
> Which means that if the target happens to exist, it's actually going
> to be an entirely different pts device from the one that you're
> actually attached to.
>
>
> You therefore need to do something along the lines of:
> - Resolve the symlink. If the target doesn't exist, return the symlink as
> the ttyname.
> - If the target does exist, check that its major and minor matches that of
> the symlink itself, if it doesn't, then return the symlink rather than the
> target.
>
>
> That's the ideal approach which makes existing software keep working
> properly without the need for any added code. After about a year of
> bikeshedding, the proposed glibc upstream fix has now evolved to instead
> returning ENODEV in the is_pty function. This allows downstream glibc users
> to detect this case and then use /proc/self/fd/0 rather than the return value
> of ttyname() but means every software using ttyname() now needs fixing.
>
> As we very much care about Ubuntu running properly inside LXD
> containers, our suggested patchset includes both the ENODEV patch as
> is still being considered by upstream (stuck on legal validation) AND
> another patch which has ttyname() return the symlink when it receives
> the ENODEV.
>
>
> We feel this is the best way to fix the problem entirely right now. Once
> glibc upstream merges the ENODEV side of this and all affected software get
> fixed upstream to deal with it, we'll then be able to drop that patch without
> causing any regressions.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1669578/+subscriptions
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1669578
Title:
Get ttyname() to work properly in containers
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1669578/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
