Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using GNU screen for remote pair programming. Let's call the local account for the remote user 'pairpair'. I have the following lines in my .screenrc:

multiuser on
acladd pairpair

I have run sudo chmod u+s /usr/bin/screen. However, when the remote user tries to connect to my screen with the command screen -r [my_account_name]/[pid_of_screen] I receive the following message:

Attach attempt with bad pid(xxx)

The pid listed in the error message matches the pid of the screen process run by the remote user. The remote user's screen process hangs; my screen session continues happily along after the error message disappears.

I've tried using both the built-in screen (at /usr/bin/screen) and the screen available from MacPorts, but I get the same error in both cases.

This worked on OS X 10.5 (Leopard).

I've googled around for the error message, but most of the hits relate to some BSD bug from 2003 or so (which was fixed). Has anyone else seen this behavior? Does anyone have any idea how to make multiuser support in screen work in SL?

share|improve this question
I'm having this same issue. Following these steps to connect does not work:… – Benjamin Oakes Oct 8 '10 at 13:11

I don't know if you're still seeing this, but I am.

Screen uses a call to kill() with signal zero to validate PIDs. The cause of the issue is that kill() is unexpectedly failing with errno EPERM. This should only happen if the UID and EUID of the calling process is nonzero and doesn't match the UID and EUID of the target process, respectively.

In this particular case, the UID of the two processes in question are different and the inherited EUID of both processes are zero. This would be fine, but as a part of the PID sanity check, the EUID of both processes is set to the UID that owns the screen session. In this particular scenario, even though both EUIDs are the same, kill() still fails with errno EPERM.

I've filed bug 8965041 at Hopefully this is the correct avenue to have this fixed.

In the meantime, I'm working around the issue by compiling my own screen binary where I've forced CheckPid() to return 0.

share|improve this answer
Thank you! That fix worked for me on AIX 5. – Greg Hewgill Nov 20 '11 at 23:41

I use Snow Leopard server, and I use multiuser screen without problems - I use exec screen -xRR in my .profile to start screen, rather then using explicit PIDs.

Does this work for you? If so it's a problem with the PID syntax, rather then multiuser screen itself

share|improve this answer
No, that doesn't make multiuser work. – schustafa Mar 17 '10 at 13:21

I'm using screen for remote pair programming. We've tried some screen sharing solutions like iChat, Skype, and VNC. For sharing text, it's a little bit overkill to send pixels (and tough to read and write remotely), especially when Internet connections are flaky.

Because there's a lot of trust implied in pair programming already (and the fact that we have a shared computer), the situation has a workaround:

  1. Make a shared user account (e.g., "pairing")
  2. Give that account admin rights
  3. Add public keys for the users I would remote pair with

The remote users can now SSH in and join the screen session.

Thanks to wwalker in #screen on for the help.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .