Bug 9568

From Bill Nottingham:
>
> Someone might want to make sure that the odd files used to multiplex
> screen screens are OK on NFS.

screen uses either named pipes or sockets. Neither work over NFS.

Pipes work fine between compatible implementations.  Most NFSv2 systems use
a way of encoding named pipes as special device files, and if both the client
and server agree on that, named pipes over NFS should work fine.

I've just tried both Cartman and Piglet as both server and client, and named
pipes are still working fine.  Can the user show a "ls -lR" of the faulty
screen directory when things are breaking over NFS?

Oops, yeah, Stephen's right. However, the compatible
implementations could be an issue; I've had one report
that it breaks when talking to a Solaris NFS server, for
example. Talking to userland nfsd might also not work;
haven't tried yet.

ok, I thought I had included the error I got but anyway, here it is. When I
issue screen at the command line I get:

[mikev@mrhat mikev]$ screen
mkfifo /home/support/mikev/.screen/7551.pts-4.mrhat failed
[mikev@mrhat mikev]$

As for the directory:

[mikev@mrhat mikev]$ ls -la .screen/
total 5
drwx------    2 mikev    mikev        1024 Feb 21 17:03 .
drwxr-xr-x   51 mikev    mikev        4096 Feb 21 17:03 ..
[mikev@mrhat mikev]$

Beware --- the NFSv2 standard doesn't support named pipes.  Doing named pipes
requires an incompatible extension to the standard (typically the pipes are
encoded on the wire as a special case of char devices).  All bets are off if
you try passing named pipe inodes over NFSv2.  If it works at all, that's a
bonus, but there's no guarantee especially if client and server are from
different vendors.

Old builds of screen used to create their pipes in /tmp.  Is there any reason
we changed, and do current screen versions have a build option to restore the
old /tmp behaviour?  That would certainly avoid the NFS complication in this
case.

One other question --- I assume it is the client that was upgraded to Piglet,
was it?  What is the server running, and has that changed at all too?

Quick update: 5.2 to 6.1 and 5.2 to 6.2/piglet both work just fine in both
directions.  This is definitely a WORKSFORME unless we can get more information
about the configuration which fails.

The client was upgraded. The server is running 5.2. These are all internal Red
Hat boxes if you want to look at them.

It was changed because in the case where it uses /tmp, it
stores all the screen directories in /tmp/screens; since
it's no longer setuid root, the first person to run
screen gets ownership of the directory. (Plus, it complains
about the permissions on /tmp/screens; it wants it to
be different permissions if screen is run as root.)

Having it put the screens in the users's home directory
works around these issues nicely.

You can, however, still compile it to not do this; there's
a screen-3.9.4-notmp patch in the source RPM; if you don't
apply that patch, it will still use /tmp.OK, so it's the userland NFS server that doesn't support this.
Is supserv running the latest errata nfs-server (in case
this was added at some point past 5.2...)

Which machines are the clients and servers?  I'll go take a look on them.
(Is root available on either of them?)

OK, I've reproduced this on a pure piglet install using the 2.2.15 kernel
version.  Using the kernel from the current tree (2.2.14-3 or later), without
the major NFS changes in the 2.2.15 version we were using before, works just
fine.

Upgrade your kernel to the current 6.2 tree and reopen this report if you
still have trouble.