bob@primerd.prime.com (04/05/89)
I am trying to use xdm to control a couple of X terminals. When I first start the daemon, everything works fine. (I am using all of the defaults.) The problem is that when I reboot any of the terminals, xdm does not grab it again when it comes back online. Is there some way to get xdm to recognize that a server has gone down and keep retrying till it comes back up? I've tried playing with the obvious parameters such as # of retries, but the problem seems to be that once xdm has made the connection, it doesn't realize when the server goes down. What am I missing? bob pellegrino Prime COmputer, Inc. bob@deep-thought.prime.com
keith@EXPO.LCS.MIT.EDU (Keith Packard) (04/06/89)
> I am trying to use xdm to control a couple of X terminals. > > .... but the problem seems to > be that once xdm has made the connection, it doesn't realize when the server > goes down. This is because xdm doesn't send any packets to the display after the connection is established, so the network connection remains idle and xdm never finds out that the other end has disappeared. You could use the TCP KEEPALIVE stuff from BSD and hope that works correctly, or hack xdm to call Xsync every 5 minutes or so. As with almost all other terminal issues, this one is easily resolved with XDMCP. Until such a protocol exists you'll probably want to leave the terminals on-line all the time. When you do want to turn the terminal off, you should do so before xdm gets around to opening the display for the first time. The open will fail and xdm will disable the display. When you turn the terminal back on, send a SIGHUP to xdm and it will re-read the Xservers file, notice that the disabled display is still in the file and attempt to reenable it. A cheap hack, but effective (i.e. I use it occasionally). Keith Packard MIT X Consortium (617) 253-1428 keith@expo.lcs.mit.edu
strike@convex.UUCP (Professor Fate) (04/25/89)
I am having some trouble with xdm. I run xdm to serve several different kinds of foreign servers, e.g., Sun's, X terminals. The xdm host is a CONVEX C120. If I start xdm, and then I start the server or power on the X terminal, xdm detects that the server is now accepting connections and displays the login window. However, if my Sun crashes, or if I power off the X terminal, and the xdm login window was being displayed, xdm will not send a new login window when the server is available again (after reboot or power on). The problem is that xdm does not detect that the server has gone away (and come back again.) The xdm child process that is waiting for input in the login window is stuck in select() deep in the bowels of Xt. There is a lot of code in xdm - some if it seems unused. Has this problem been solved already. I seem to remember some discussion about xdm about three months ago or so. Is there a solution to this problem? M
rws@EXPO.LCS.MIT.EDU (04/25/89)
Is there a solution to this problem? We at MIT think the correct solution is to establish a standard protocol between X displays and display managers like xdm, so that when a display is powered on or reset, it can request connections from (one or more) display managers. In fact, we have designed such a protocol (which actually does a little more than this), and it is currently under technical review within the X Consortium. Since most of the current display vendors are in the Consortium, we're hopeful of a common solution in the future.
paone@aramis.rutgers.edu (Phil Paone) (06/07/90)
Hi, Has anyone managed to get xdm to work under any of the 386 Sys V varients? I have been trying to get it to run on SCO Unix, to no avail. The closest I have been able to get, is a message to the xdm-error file which says "xdm must be run from the console", and I was running it from the console. Any help is appreciated. Thanks, Phil -- Phil Paone attmail!ppaone !rutgers.edu!aramis.edu!ppaone paone@aramis.rutgers.edu "Dinna ya know a jailbreak when ya see it?"
johnl@esegue.segue.boston.ma.us (John R. Levine) (06/07/90)
In article <Jun.7.07.39.10.1990.1082@aramis.rutgers.edu> paone@aramis.rutgers.edu (Phil Paone) writes: >Has anyone managed to get xdm to work under any of the 386 Sys V >varients? Works fine for me under 386/ix. I put this line into /etc/inittab: xw:23:respawn:/usr/bin/X11/xdm -nodaemon If I had more than one server, I'd use multiple lines each with a -server option. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.
john@labtam.oz (John Carey) (06/08/90)
In article <Jun.7.07.39.10.1990.1082@aramis.rutgers.edu>, paone@aramis.rutgers.edu (Phil Paone) writes: > Hi, > > Has anyone managed to get xdm to work under any of the 386 Sys V > varients? I have been trying to get it to run on SCO Unix, to no > avail. The closest I have been able to get, is a message to the xdm-error > file which says "xdm must be run from the console", and I was running > it from the console. We have xdm running on Labtam Delta's under UNIX System VR3.2 also System VR4 The message you are getting is from xdmshell - NOT xdm I have no expereince with xdmshell - a work around would be to run xdm directly John Carey Labtam Information Systems Pty Ltd
bachovch@sjuphil.uucp (J. Bachovchin) (08/02/90)
I was wondering if anyone could be of some assistance. I am trying to set up several X terminals to run off our network. To allow easy acces for users, typically students who are unfamiliar with X, I'm trying to run the xdm Display Manager. Everything seems to run okay, except for the Xsession file. Everytime I log in, the Xsession file fails and the only message in my error log is: "Xsession execution failure /usr/lib/X11/xdm/Xsession". I have the appropriate line in xdm-config, I believe: "DisplayManager*session: /usr/lib/X11/Xsession", the file is executable, and I even put full pathnames for the commands in it thinking that was the problem. Has anyone seen this problem or know any causes? Thanks in advance Jeff Bachovchin Systems Manager St. Joseph's University Philadelphia, PA bachovch@sjuphil
keith@EXPO.LCS.MIT.EDU (Keith Packard) (08/03/90)
> Everytime I log in, the Xsession file fails and the only message in my error > log is: "Xsession execution failure /usr/lib/X11/xdm/Xsession". I have the > appropriate line in xdm-config, I believe: > "DisplayManager*session: /usr/lib/X11/Xsession" As it looks like you've copied this information by hand, I'd first suggest checking the spelling (and directory) of each of the files in question. If the file names are as indicated above, then xdm is (somehow) interpreting the resource file incorrectly. You can run xdm in debug mode (xdm -debug 9) to see the exact contents of all of the relevant resources. You'll be looking for a line like DisplayManager._0.session/DisplayManager.Color.Session value /usr/lib/X11/Xsession The _0 and Color fields will depend on the name/class of the display involved. Make sure you run it in an xterm with a huge history buffer, or inside and emacs shell window, otherwise the important information will simply scroll on by. Keith Packard MIT X Consortium
grady@fx.com (Steven Grady) (01/25/91)
Environment: X11.4 on a SparcStation 1 running SunOS 4.1. We've been trying to use a script to start X and another program (something that redirects console messages) as the X server started by xdm. It took us a while to get things right, because there were some unexpected signals that got sent to the "server". Specifically, the server receives a number of SIGIOs when xdm terminates it (when the user hits a key-sequence generating an abort-display() call). Anyone know why this is happening? Also, to terminate the server, xdm sends a SIGTERM, followed by a SIGCONT. This sort of makes sense, since somehow after the user logs out, X is in status "STOP". Why would this be? No one sends out a SIGSTOP (from looking at xdm, dix, and libX). Is this intentional behavior? Some of the obscure stuff in xdm could be better commented.. BTW, it took us some time to fix this. Shell scripts do something weird with SIGTERM (even if you explicitly trap them), so we couldn't use sh. We went with perl instead. The script starts X and the console process, traps all signals to forward them to X, waits for X to exit, then kills the console process and exits with the X exit value. Not forwarding all signals, or not waiting for X to exit, will cause strange, bad behavior.. -- Steven grady@fx.com "If you wanted to make Sarok the Preparer cry, well, mission accomplished."
cjdb@ellis.uchicago.edu (Charles Blair) (05/05/91)
I'm trying to set up a network so that users log in using XDMCP. Things are O.K. until I try customizing, following the xdm man page. One hurdle I can't seem to overcome results in the following message in xdm-errors: error (pid 123): Cannot open server authorization file /usr/local/lib/X11/xdm/auth-server Nowhere do I see documented what the format of this file should be, nor is the file mentioned in the xdm man page. Could someone e-mail me a description of a customizable setup using xdm that works? I'd really appreciate it. Thanks. -- Internet: chas@uchicago.edu
stumpf@Informatik.TU-Muenchen.DE (Markus Stumpf) (05/06/91)
In article <1991May4.181440.29158@midway.uchicago.edu> you write: |> |> I'm trying to set up a network so that users log in using XDMCP. |> Things are O.K. until I try customizing, following the xdm man page. |> |> One hurdle I can't seem to overcome results in the following message |> in xdm-errors: |> |> error (pid 123): Cannot open server authorization file |> /usr/local/lib/X11/xdm/auth-server |> |> Nowhere do I see documented what the format of this file should be, |> nor is the file mentioned in the xdm man page. Hi there! You can find information about the format of this file in the man page for xauth(1). You have to be carefully when setting up a network-wide xdm-directory! xdm tries to write this file, so the server can read it and set up the auth-records to check the authorization of the user! A hack we use here locally - which is kind of a compromise - is to use various xdm-config files (xdm-config.<host1>, xdm-config.<host2>, etc.). They all look similar, but have entries different entries for DisplayManager.errorLogFile: DisplayManager.pidFile DisplayManager.remoteAuthDir and DisplayManager.DISPLAY.authFile This entries point to directories where xdm has write permission and names that don't collide. Xdm gets started from /etc/rc with xdm -config <xdm-directory>/xdm-config.<localhostname> This works fine for us! Hope that helps \Maex P.S. We had problems on mVaxen that the DisplayManager.remoteAuthDir resource wasn't read correctly! Therefor we changed the local Imakefile and every- thing worked fine! -- +- Markus Stumpf Technische Universitaet Muenchen -+ | Institut fuer Informatik, Rechnerbetriebsgruppe | | stumpf@informatik.tu-muenchen.de Postfach 202420 | +- ...@{unido.uucp,relay.cs.net} D-8000 Muenchen 2, West Germany -+ -- +- Markus Stumpf Technische Universitaet Muenchen -+ | Institut fuer Informatik, Rechnerbetriebsgruppe | | stumpf@informatik.tu-muenchen.de Postfach 202420 | +- ...@{unido.uucp,relay.cs.net} D-8000 Muenchen 2, West Germany -+