screen [spugbrap’s blog]

This will not be of use to many, if any, but I expended effort trying to figure out how to solve this today, so I’m posting it here for future reference, if nothing else.

Today, at work, I ssh’d to my home computer, and tried to run ‘screen -r -d‘, to reattach to an existing session of gnu screen at home. Here’s what happened:

$ screen -r -d
There is no screen to be detached.

I knew this was not true, so I tried this:
$ screen -list
No Sockets found in /tmp/uscreens/S-myusername.

I didn’t believe it, because I knew I had an existing session open, so I looked for myself:
$ ls -l /tmp/uscreens/S-myusername/
total 2
-rw——- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
-rw——- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home

I saw it right there, so I looked to see if one of the processes that I had running in my existing screen session was still running:
$ ps | grep perl
3204 368 3204 1760 13 1003 14:20:05 /usr/bin/perl

Sure enough, there it was… So, I took a look at my SockDir on my laptop, at work, to see if permissions might be involved in some way:
$ ls -l /tmp/uscreens/S-myusername/
total 3
srwx—— 1 myusername None 53 Aug 2 14:18 2568.tty1.dave-laptop
srw——- 1 myusername None 53 Jul 4 01:05 3600.tty1.dave-laptop
srw——- 1 myusername None 53 May 15 15:42 960.tty1.dave-laptop

Ah hah! There was a difference! The ’s’ at the beginning of the permissions list on my laptop’s SockDir contents, but not on my home machine’s.

So, I went searching for what the heck that ’s’ stands for, since usually, if anything, I either see an ‘l’ (L) or a ‘d’. I checked the help, info, and man pages for ‘ls’ and ‘chmod’, but didn’t find anything that actually matched this flag. The closet thing was ’suid + executable’, but when I tried to chmod that onto one of my files, the permissions showed ‘-rws——’, which is not what I was looking for.

A google search or two, for things like ‘srwx——‘, ‘srw——-‘, ‘srwx srw‘, ‘cygwin srw‘, etc. didn’t turn up anything useful - at least not in the first pages of results.

I tried looking at my laptop’s SockDir in windows explorer, and looking at the advanced security properties of one of the files. Nothing looked interesting. Then I looked at it from a command prompt (4nt), and saw this:
[c:\]dir c:\cygwin\tmp\uscreens\S-myusername
[…]
0 bytes in 0 files and 2 dirs

Oops, let’s try with ‘attrib’ instead of ‘dir’:
[c:\]attrib c:\cygwin\tmp\uscreens\S-myusername
__SA_ C:\cygwin\tmp\uscreens\S-myusername\2568.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\3600.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\960.tty1.dave-laptop

Ah hah! The ’system’ and ‘archive’ attributes were set on these files. So, I verified that these flags were NOT set on the files on my home machine:
$ attrib “c:\\cygwin\\tmp\\uscreens\\S-myusername\*”
C:\cygwin\tmp\uscreens\S-myusername\1696.tty0.spugbrap-home
C:\cygwin\tmp\uscreens\S-myusername\3500.tty0.spugbrap-home

Sure enough, there’s the difference. So, I set the ’system’ attribute on those files (didn’t bother with ‘archive’ attribute, though I’m not sure what causes it to be there on my laptop but not on my home):
$ attrib +”c:\\cygwin\\tmp\\uscreens\\S-myusername\*”

Verified that it worked:
srw——- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
srw——- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home

Then, I tried connecting to my existing session, and it succeeded.

While preparing this post, I experimented a little bit more, and noticed that, for some reason, my home pc is not creating these screen socket files with the required ’system’ attribute at all, anymore. I’m not sure why this is happening, now, because I can’t think of anything I’ve done, recently, that might have caused any different behavior as far as permissions and such.

I will post again if I figure this out, but for now I am content with adjusting the attribute manually. In theory, I can keep each screen session alive until my next reboot (which is rare), so I shouldn’t have to do too many manual adjustments like this. I also welcome any comments on how to solve this problem, or any other useful tips for effectively using gnu screen in cygwin.

I use a Windows version of the GNU Screen window manager/terminal multiplexer every day, and wanted to share a trick that I’ve learned over time. A lot of people have trouble with reattaching to existing screen sessions in the windows/cygwin version. You can probably accomplish this different ways, but this is what I have been doing every day at work for at least 9 months now:

open first bash shell window
run: screen
open another bash shell window
run: screen -x
NOTE: this window will probably not reattach, at least it doesn’t for me. if it does, these instructions are useless for you.
close second bash window (opened in step 3).
open another bash shell window
run: screen -x

At this point, both bash windows are now connected to the same screen session.

Variations on this may work.. I’ve done this in a lot of different conditions, including of course ssh-ing into a box and attaching to the existing screen session, and also using ssh-agent just right to avoid having to type passwords all day long. More on that later, but for now, I just wanted to get this basic information out there.

The main idea is that the first attempt to attach to an existing screen session will fail, but if you try again in a new window it should work.

spugbrap’s blog

August 2nd, 2006

screen in cygwin needs System attribute on SockDir files

July 14th, 2005

How to reattach to GNU screen sessions in windows (cygwin)

Site Info

Feeds

My Other Sites