Bug 191017 - sysutils/screen: 4.3 will not load 4.0 sessions due to default socket usage
Summary: sysutils/screen: 4.3 will not load 4.0 sessions due to default socket usage
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-13 21:17 UTC by Bryan Drewery
Modified: 2014-06-15 15:27 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bryan Drewery freebsd_committer 2014-06-13 21:17:27 UTC
In the 4.0 build it would default to using fifo:

- your fifos are usable
configure: checking for broken fifo implementation...
- your implementation is ok
configure: checking sockets...
- your sockets are usable
configure: checking socket implementation...
- you are normal
- both sockets and fifos usable. let's take fifos.

In 4.3 it now defaults to sockets:

- your fifos are usable
configure: checking for broken fifo implementation...
- your implementation is ok
configure: checking sockets...
- your sockets are usable
configure: checking socket implementation...
- you are normal
- both sockets and fifos usable. let's take sockets.


The impact of this is that NAMEDPIPE is *not* defined in the 4.3 config.h, so the SockFind function ignores any existing fifos in socket.c:

#ifndef SOCK_NOT_IN_FS
# ifdef NAMEDPIPE
#  ifdef S_ISFIFO
      debug("S_ISFIFO?\n");
      if (!S_ISFIFO(st.st_mode))
        continue;
#  endif
# else
#  ifdef S_ISSOCK
      debug("S_ISSOCK?\n");
      if (!S_ISSOCK(st.st_mode))
        continue;
#  endif
# endif
#endif

This requires all sessions to be sockets and ignored older fifo. I would consider this to be an upstream bug.

Something such as this would fix it to work with older sessions and also stick to fifos in new sessions:

post-configure:
    echo "#define NAMEDPIPE 1" >> ${WRKSRC}/config.h
Comment 1 commit-hook freebsd_committer 2014-06-14 04:08:38 UTC
A commit references this bug:

Author: cy
Date: Sat Jun 14 04:07:56 UTC 2014
New revision: 357739
URL: http://svnweb.freebsd.org/changeset/ports/357739

Log:
  Make screen 4.0 compatible, prefer fifo over sockets.

  PR:		191017
  Submitted by:	bdrewery

Changes:
  head/sysutils/screen/Makefile
Comment 2 Cy Schubert freebsd_committer 2014-06-14 04:46:46 UTC
Committed. Thanks.
Comment 3 A. Gijsberts 2014-06-14 17:33:21 UTC
After this update I cannot connect to my screen sessions anymore, just like when screen was updated to 4.2.1. The files are still listed in /tmp/screens/S-..., but screen -list doesn't find any.

Is there any way to recover these sessions?
Comment 4 John Hein 2014-06-15 01:15:02 UTC
After the previous fifo->sockets change broke my existing sessions, I started looking at the code to see if it could accept either to attach to existing sessions (and prefer one for new sessions).  I didn't find an easy way in the existing code.  The way it is structured, it makes it hard to do that (or I missed the simple way).  Ideally, a patch to support both would be nice.  A couple quick searches in the upstream resources (mailing list, bug reports) was not fruitful either (although there were complaints):

http://savannah.gnu.org/bugs/?32471
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788


When I hit the fifo->sockets update breakage, my workaround was to keep an old binary that used fifos.

Another option would be that the port could build a bin/screen-fifo and bin/screen-socket.  It'd be a bit of building gymnastics, and it's really a hack, but it seems easier than trying to find a patch to support both in the same binary.  Closely related would be to add socket/fifo port options.

[The other workaround was that now I use tmux more and am mostly happy with that, but still use screen in some cases.]
Comment 5 Cy Schubert freebsd_committer 2014-06-15 05:27:36 UTC
Option added.
Comment 6 A. Gijsberts 2014-06-15 15:27:07 UTC
Great, thanks to both of you. In the end I indeed rebuild the previous version of the port, which at least allowed me to properly close the sessions and avoid data loss.