Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A workaround for X11 sharing by multiple users UNIX
Like others, our lab ran into the situation where multiple users of X11 on the same machine were locked out of the display. I'm no expert on X-windows so this may be obvious to the more experienced, but we came across a workaround without the need to modify system files or delete the display lock files.

With more observation and some help from colleagues, it turns out the first user to open X11 gets DISPLAY :0.0, the next user to open X11 gets DISPLAY :1.0, and so on. This is 'recorded' in /tmp as .X#-lock files, where # is the display number assigned, which are owned by the user who opened X11. The lock files are removed when X11 is terminated, and the next user to start X11 will get the lowest display number that is available starting with zero (e.g. the display numbers are recycled). Only the lock files seem to deny access to other users. The .X11-unix directory had no impact in our tests.

If this is how your system is working, the fix is to assign the correct display to each user via the 'setenv DISPLAY :#.0' command in the shell start-up (rc) file, where # is the display number. The following tcsh shell script will do this (scans for first 10 displays only) - first loop checks for an active lock by current user first, and the second loop will assign the next available DISPLAY number if the user hasn't already started X11 (assumes X11 will be started after login):

 foreach x (0 1 2 3 4 5 6 7 8 9 10)
    if ( -o /tmp/.X$x-lock ) then
      echo "X11 setup: $USER has an active lock on DISPLAY :$x.0"
      setenv DISPLAY :$x.0
      goto disp_set
    endif
  end
  foreach x (0 1 2 3 4 5 6 7 8 9 10)
    if ( ! -e /tmp/.X$x-lock) then
      echo "X11 setup: $USER does not have an active display"
      setenv DISPLAY :$x.0
      goto disp_set
    endif
  end
  disp_set:
  echo "X11 setup: DISPLAY set to :$x.0"
We added this to our .tcshrc files for 'automated' assignments at login or when opening new xterm or terminal windows. There is a slight probability the DISPLAY variable can be changed in the middle of a terminal session (depends on when each user starts/stops X11). If an X-window access error shows up again, the code can be sourced again to quickly fix the DISPLAY assignment.

This was tested successfully on two systems running 10.3.2. Hopefully it will also work on yours, although I can forsee some limitations based on certain apps or remote connections requiring the :0.0 display. Please feel free to clean up the script or offer improvements, I can use all the help I can get in this area!

    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[12,998 views]  

A workaround for X11 sharing by multiple users | 16 comments | Create New Account
Click here to return to the 'A workaround for X11 sharing by multiple users' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A workaround for X11 sharing by multiple users
Authored by: hopthrisC on Feb 25, '04 04:34:19PM

Sorry, but this looks like a Really Bad Idea (tm)!!

Not only that, it is (normally) totally not necessary:

Start X11, open an XTerm, voilĂ  $DISPLAY is already set correctly, regardless of the number of users logged in.

If you really have to start an X-App from Term.app instead of an XTerm, simply use the open-x11 command, as in:

# open-x11 xeyes

Or have I completely misunderstood your problem?

Please clarify!



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: mzs on Feb 26, '04 11:18:10AM

I have to concur this hint is a REALLY BAD IDEA.

Here is my explanation of why this is the case:

You never ever EVER want to set the DISPLAY environment variable in a login script. You have no idea of what it needs to be set to. Let me repeat:

YOU HAVE NO IDEA WHAT IT NEEDS TO BE SET TO.

You still disagree, you think you have a nice script to figure it out in the hint, but you are wrong. Imagine that you ssh into a machine and wish to have your X11 connection forwarded. The login script will blow away the value that DISPLAY has been set to by ssh. If you have to use telnet, the .telnetrc file lets you do a similar thing. A simple hack with the TERM variable and it works with rlogin/rsh/remsh as well. I do not even want to get into VMS.

The point is that the Terminal app is not meant to run X11 apps from. Let your X11 environment set-up the X11 environment properly and run your X11 apps from there.

I am sorry to sound so caustic, but I just remembered how many times I have had to deal with green sysadmins in the past that put crap like this into the SYSTEM login files, so I had no easier way of fixing it except banging it into their heads why it was wrong. With no way to get to the submitter of this hint in meat-space, this comment will have to do.



[ Reply to This | # ]
A little tact would go a long way (was: workaround for X11 sharing by multiple users)
Authored by: The Lorax on Feb 27, '04 08:40:14AM

I'm sorry, where is it written that submissions to this site need to come from some sysadmin guru with 200 years experience? You make some VERY valid points about how DISPLAY settings can get you into trouble, but please, this site is called macosxHINTS.com, not bloody macos-snotty-mightier-than-thou-gurus.com. Don't discourage new members (like myself!) from posting with this kind of negative comback. We want posts, posters, and user experiences on this site, right?
Not "bah, green sysadmin, crap" and other such unhelpful nonsense which your points could have been made just as well without.

I for one found the original poster comments interesting. It (a) seemed to solve his immediate problem, (b) brought some interesting (mostly non-condescending) discussion (Imagine that!), and (c) brought forth a follow-on hint about the 'open-x11' command. I certainly learned from it all. So thanks 'spier' and 'hopthrisC'!!!!



[ Reply to This | # ]
A little tact would go a long way (was: workaround for X11 sharing by multiple users)
Authored by: hopthrisC on Feb 27, '04 12:31:01PM

Ah! A discussion thread I have never seen before ;)

I think I have advice for both kinds of posters:

To the newcomers in the daunting world of neverending frustrations (a.k.a. the UN*X experience): Whenever you have to invent something on your own to solve a problem, you most probably are somehow wrong.

30-odd years of UN*X-using, -hacking, -breaking and -tuning have seen it all and there is no problem you -- as a beginner -- can run into, that isn't already solved. Search for it, ask for it, it is there!

To the (thinks-he-is) guru: Allow for some slack! They are _beginners_. You can solve their problem lefthanded on a french keyboard while the terminal driver went bonkers and spews line noise at you, great!!

How are they supposed to find a solution to a problem when they neither know that one exists, nor even where to look for it. And don't give me "read the man pages" shit, cause they are wrong more often than not on OS X. (Although I have to admit that this particular poster should have read the X11 FAQ .-)

Tell them they have a bad solution. Tell them it is bad, because they themselves invented it. Tell them why this is almost always a Bad Idea (tm), but also tell them what the solution is!

_Especially_ in a forum where _your_ presence is purely voluntaryl The least this does is save you (and me) from one more lab that has $DISPLAY settings that make you wish for high-voltage LARTs.

Or -- to put it another way -- don't be sissies, don't be pricks!



[ Reply to This | # ]
A little tact would go a long way (was: workaround for X11 sharing by multiple users)
Authored by: speir on Feb 27, '04 05:28:48PM

I am not a sys admin (obvious by now ;). Why anyone would assume so perplexes me since this great site is an open public forum. I am an academic research scientist who studies viruses using biophysical methods, and a long time unix end user. My lab works on a stricly limited budget and can not employ a sys admin. So it is left to those of us willing to take on new enterprises (usually at personal cost) to extend our capabilities and solve some of our impediments. This is why I read this site and posted this hint here - like the great variety of non-admins out there I was looking for helpful discussion. I did look for the answer to my problem for the amount of time I could afford, and didn't run across the answer. Indeed, the capability I look for doesn't appear to exist. The open-x11 command is very close though and I will make use of it.

Not being a sys admin, I will never modify system files since it is not my expertise and outside my interests. I guess I didn't make it clear that I only suggest changes to a users individual setup files. Then the fix for any unforseen trouble, like remarked here for x11 forwarding, is to simply use the previously archived set up files.

I would rather spend my time studying the biology of viruses. What I have learned from these responses, with one exception, will allow me and my colleagues to continue to do so with improved capabilities. I thank hopthirsC, Ptitboul, and The_Lorax for their valuable time. You have done us a great service, and I hope you will continue to do so in the civil manner you have demonstrated for all who post here.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: EccentricAnomaly on Aug 17, '04 11:17:22AM
You still disagree, you think you have a nice script to figure it out in the hint, but you are wrong. Imagine that you ssh into a machine and wish to have your X11 connection forwarded. The login script will blow away the value that DISPLAY has been set to by ssh. If you have to use telnet, the .telnetrc file lets you do a similar thing. A simple hack with the TERM variable and it works with rlogin/rsh/remsh as well. I do not even want to get into VMS.

humbug

here's the solution to the ssh/telnet whatever problem (rewrite in your fav. shell):


if (! $?DISPLAY) then
  setenv DISPLAY :0
endif

You can use login like the poster's script where 'setenv DISPLAY :0' is to figure out what the DISPLAY should be set too.

The point is that the Terminal app is not meant to run X11 apps from. Let your X11 environment set-up the X11 environment properly and run your X11 apps from there.

poppycock! I run X apps from Terminal all of the time. I like the Terminal's split screen and I like the way you can search in the buffer. Terminal is miles better than xterm.



[ Reply to This | # ]

A workaround for X11 sharing by multiple users
Authored by: hopthrisC on Feb 25, '04 04:38:29PM

BTW, when several Users start X11 (several times) on one Box, they actually don't share X. Quite the contrary!

If you really want to share one X11 display among several users, have a look at the xhost command (or turn off authentication in the X11 prefs...)



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: speir on Feb 25, '04 05:39:22PM

Thanks for all the information! I was hoping that the more experienced could tell me if I was going in the wrong direction.

1) Yes, we did find that the xterm $DISPLAY was automatically set, but after I posted. However we primarily use the Terminal program, so needed another solution.

2) Thanks for open-x11 - its the solution we were looking for. I did not know about this command. Works perfectly so my workaround is unnecessary (just have to set up a series of aliases since the lab is used to just typing the program name - was hoping for something more seamless).

3) No, we do not want to share one $DISPLAY (is this what you meant?). We wanted everyone to have a different $DISPLAY so they did not run into conflicts.

4) The workaround has been working very well for weeks (not a single problem), but I knew it wasn't ideal. Thanks again for the helpful comments.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: hopthrisC on Feb 25, '04 06:11:49PM
2) Thanks for open-x11 - its the solution we were looking for. I did not know about this command. Works perfectly so my workaround is...
It's all in the FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
...unnecessary...
At least you learned a lot about shell scripting and racing conditions ;)
...(just have to set up a series of aliases since the lab is used to just typing the program name - was hoping for something more seamless).
Ah! The joys of user education ;) Well, there is another hack that could help you with this. It's slightly ugly, but anyways: If you start X11.app from the Terminal (or from a script, which you can use as a Startup Item) like so:
  # /Applications/Utilities/X11.app/Contents/MacOS/X11 :$UID
It will use the user's (unique!) ID as display number. You then can set $DISPLAY to $UID in .tcshrc, .bashrc or even in ~/.MacOSX/environment.plist (which is the more general approach).

With this method the users can never get in each other's way and don't have to use open-x11. You only have to make sure that they don't start X11 on their own, or that they only start it via your script.

(With this method you can start several instances of X11.app at the same time, so don't be confused, if you see more then one X icon in the Dock!)

[ Reply to This | # ]

A workaround for X11 sharing by multiple users
Authored by: speir on Feb 25, '04 05:47:59PM

Forgot the clarification:

We wanted what Xterm does automatically, but in the Terminal.app - setting the $DISPLAY correctly for each user.

open-x11 is a good built in option, but not a complete solution. Is there a way to get the automatic $DISPLAY setting in Xterm to work in Terminal.app?



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: Ptitboul on Feb 27, '04 06:29:16AM

You asked "Is there a way to get the automatic $DISPLAY setting in Xterm to work in Terminal.app?"

Not really. The biggest problem is that you have to guess which X11 server you want to use. When xterm is launched from within X11, then the guess is that all applications lauched within this xterm should be displayed on that X11 server. But that may be a bad guess, and that is the reason why DISPLAY can be changed and why most X11 programs understand the -display flag.
If an X11 server is already running when Terminal.app is launched, then your technique is quite good, because the best guess you can make is to find an X11 server you are allowed to talk with. But you should at least check that DISPLAY was not set. If there is a previous value for DISPLAY (e.g. if the shell was lauched from within an ssh with X11 forwarding), then you should not change it.
However, if no X11 server is running when Terminal.app is launched, then your technique is not so good, because you make the hypothesis that the owner of this Terminal.app will be the next one to launch a new X11. I would rather not set DISPLAY, and ask that anyone that may need a X11 server launches it at login.
This is what I do. But, since launching X11 automatically launches an xterm, I find this annoying (I prefer Terminal.app). Therefore I deleted the line "xterm &" from /etc/X11/xinit/xinitrc



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: speir on Feb 27, '04 04:32:22PM

Thank you for the additional advice and very helpful information! Much appreciated.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: jhegarty on Apr 10, '04 05:44:18AM

Interesting. I also prefer the Terminal, but don't always start X before starting the Terminal. It also seems like when I put the machine to sleep, X gets confused and I have to restart it when I wake the machine up (but I don't want to close and then reposition all my terminals!). I worked around the problem of having the Terminal start first by adding

[ ! "$DISPLAY" ] && export DISPLAY=:0.0

to my /etc/profile. (i.e.: if DISPLAY is not set when the Terminal starts, set it to :0.0, otherwise use the existing $DISPLAY) Of course, I'm really the only regular user on this machine, and definitely the only one using X locally. Setting the display like this doesn't seem to break ssh for remote logins, by the way. If I login to this machine remotely and X is already running locally, ssh still sets the display correctly for forwarding.

** Note: This was a Physicist's hack. Less messy than the Biologist's hack, but much more spur-of-the-moment and broken. ;)

Hmm .. it might be worthwhile to write a script that checks for the ownership of the .X##-lock files, and sets the display according to which one you own. That way X can still give you whatever display it wants to, and it should be trivial for a user to run a single command if they discover their X isn't set correctly (without worrying about exactly what it's supposed to be set to), right?

---
--[ you cannot consistenly judge this statement to be true ]--



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: Christoph on May 03, '04 02:38:46AM
In contrast to the strong opinion of some posters I need to say that this is not a bad idea. The problem with open-x11 (which is just a wrapper script around "open -a X11 xapp" BTW) is that you cannot pass command line arguments to the application. Say you want to load the file bla.txt in emacs or bla.ps in gv. This is not possible with open-x11. Here is a Bourne shell compatible version of the above code:

# try to figure out DISPLAY cleverly
DISPLAY=""
for x in 0 1 2 3 4 5 6 7 8 9
do
  if [ -O /tmp/.X$x-lock ]
      then
      DISPLAY=:$x.0
      break
  fi
done
if [ -z "$DISPLAY" ]
    then
    echo "$USER has no X11 DISPLAY open" 1>&2
    exit 1
fi
export DISPLAY
I have written an open-x11 replacment "open-xapp" which is available from http://lionel.kr.hs-niederrhein.de/~dalitz/data/software/macosx/open-xapp

[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: EccentricAnomaly on Aug 17, '04 11:21:22AM

Wrap the code above in logic to check if $DISPLAY is already set first. This way you can be logged into your Mac using x11 and can also ssh in remotely from another machine and have x11 display properly both locally and remotely.



[ Reply to This | # ]
A workaround for X11 sharing by multiple users
Authored by: wgscott on Nov 05, '04 06:14:57PM
I had a fresh crack at this. I found that if the X11.app has been started, then you can use ps -x to find out what DISPLAY needs to be set to for that particular user. This is for zsh but it could be generalized...


       #---------------
	# X-windows DISPLAY
	#---------------
	
	# Set DISPLAY variable to allow X-windows programs to run from Terminal.app
	# Fast User Switching creates the problem of multiple simultaneous instances of
	# X11.app running and how to find the appropriate DISPLAY value to assign to each.
	# Currently this is only done for X11.app.  It should be done for XDarwin, etc.
	
	# {====>}
	
	# If the user has Apple's X11 installed, assume that the user wants to use it.
	# If it is not open, open it, and then try to find the appropriate DISPLAY value
	# consistent with multiple instances of X11 running simultaneously.
	
	# If the user doesn't have X11.app installed, the user probably uses a different     
	# X11 application. We then simply set DISPLAY to :0.0 if it is not already set.

    if [[ -z $DISPLAY ]]; then	
    
        # Find out if user has Apple's X11:
        
        # First attempt:
        X11APPDIR=$(/usr/bin/locate X11.app | head -1 )
        
        if [[ ! -z $X11APPDIR ]];then
            # If locate didn't work, try hunting for it in the usual places:
            if [[ -d /Applications/Utilities/X11.app ]]; then
                X11APPDIR=/Applications/Utilities/X11.app
            elif [[ -d /Applications/X11.app ]]; then
                X11APPDIR=/Applications/X11.app
            else
                X11APPDIR=''
            fi
        fi
         
            
        # If we found that the computer has X11.app, assume this is what the
        # user will want to use to start X11.
        
        if [[ -d $X11APPDIR ]];then 
        
            # First see if this user has started X11. If not, start it.
            # Then get the DISPLAY the output of the command "ps"
            # This guarantees we use the correct DISPLAY number.
            
            already_running_x11=$( /bin/ps -xwc | grep -v X11DO | grep X11 \
                                                | head -1 | awk '{print $NF}' )
            
            if [[ -z $already_running_x11 ]]; then
                /usr/bin/open -a X11; print "opening X11"; sleep 3
            fi
            
            x11_display_number=$( /bin/ps -xw -o command \
                         | /usr/bin/sed -n 's/.*\/X11.* \(:[0-9]\{1,2\}\)$/\1/p' )
                
            if [[ -n $x11_display_number ]];then
               export DISPLAY=$x11_display_number.0
               print "DISPLAY has been set to $DISPLAY "
            else
               print "Failed to read DISPLAY from ps"
               export DISPLAY=:0.0
               print "DISPLAY has been set to $DISPLAY "
               print "This may cause problems with Fast User Switching."
            fi
                    
        fi # [[ -d $X11APPDIR ]]
    
    else 
        # In the case of non-Apple X11, just set the display to :0.0
        export DISPLAY=:0.0
        print "DISPLAY has been set to $DISPLAY "
            
    fi # initial DISPLAY test
        




[ Reply to This | # ]