arne@yc.estec.nl (Arne Lundberg) (06/06/90)
I have a question about the XDMCP support in the MIT sample server, in my particular case the Xhp server. I am starting the X server from init by an entry in the inittab. On an other machine I have a xdm running that is told that the workstation with the X server is a foreign display. This works OK until a reboot of the workstation, which xdm never learns about. I tried the ``-query xdm-host'' option when starting Xhp but it did not help. The only thing that happend was that Xhp generated an error message: ``XDM: too many retransmissions''. According to the manual this option would send query packets to xdm-host and this would than tell xdm that a `new' X display is ready for use. Is this supposed to work the way I would like? In that case why does it not work? Thanks in advance, Arne Lundberg European Space Technology Centre, Noordwijk, the Netherlands arne@yc.estec.nl or ALUNDBER@ESTEC.BITNET Phone: +31 1719 84865, Fax: +31 1719 12142, Telex: 39098
gertjan@repko.nl (Gertjan Vinkesteyn) (06/06/90)
In article <1378@esatst.yc.estec.nl>, arne@yc.estec.nl (Arne Lundberg) writes: > According to the manual this option would send query packets to xdm-host > and this > would than tell xdm that a `new' X display is ready for use. > The new XDMCP works if you have an entry like xdmcp 177/udp xdmcp /* XDM X window client server */ in the file /etc/services You need to have the octal ethernet address in /etc/ethers, like 00:00:a7:00:9:120 xterminal be sure arp runs, like: /usr/etc/arp -e /etc/ethers and in /etc/hosts #what ever the address is, like 192.9.200.1 xterminal The clue is that you have NOTHING in /usr/lib/X11/xdm/Xservers doing it the old way, still give problems restarting XDM after you shut off your X window terminal and turn it on again. You have to kill the particular XDM process to that terminal, that will help some. But that is awsome. Please call or mail me if you are in problems. Tel: 03473-70650 @ Repko -- Gertjan Vinkesteyn, internet: gertjan@Repko.NL ######################################################### ####### Jesus Saves, Invests, and pays Dividends ######## #########################################################
keith@EXPO.LCS.MIT.EDU (Keith Packard) (06/06/90)
> I have a question about the XDMCP support in the MIT sample server, in my > particular case the Xhp server. > I tried the ``-query xdm-host'' option when starting > Xhp but > it did not help. The only thing that happend was that Xhp generated an error > message: ``XDM: too many retransmissions''. xdm does not support XDMCP when running on SYSV machines. The lack of reliable signal handling in a SYSV environment would make this quite difficult to implement. The problem revolves around listening for UDP packets on a socket and also waiting for child process termination. The server is working fine in your case, the display manager is simply not listening for the packets. Keith Packard MIT X Consortium
arne@yc.estec.nl (06/07/90)
> xdm does not support XDMCP when running on SYSV machines. The lack of reliable > signal handling in a SYSV environment would make this quite difficult to > implement. The problem revolves around listening for UDP packets on a socket > and also waiting for child process termination. In the case of a HP-UX machine i believe that there exists a reliable signal mechanism. Refer to the following extract from sigvector(2): SYNOPSIS #include <signal.h> sigvector(sig, vec, ovec) int sig; struct sigvec *vec, *ovec; DESCRIPTION The system defines a set of signals that can be delivered to a process. The set of signals is defined in signal(5), along with the meaning and side effects of each signal. This manual page, along with those for sigblock(2), sigsetmask(2), sigpause(2), and sigspace(2), defines an alternate mechanism for handling these signals that assures the delivery of signals and integrity of signal handling procedures. The facilities described here should not be used in the same program as signal(2). Would it be possible to modify xdm to use these facilities and get XDMCP support? How difficult would you think that this would be? I have had a quick look and it seems like the ``SYSV'' define is used both for adapting to the different signals and also many other System V differences. -- Arne Lundberg
jsparkes@bcars85.bnr.ca (Jeff Sparkes) (06/08/90)
In <9006061659.AA05569@xenon.lcs.mit.edu> keith@EXPO.LCS.MIT.EDU (Keith Packard) writes: >> I have a question about the XDMCP support in the MIT sample server, in my >> particular case the Xhp server. >> I tried the ``-query xdm-host'' option when starting >> Xhp but >> it did not help. The only thing that happend was that Xhp generated an error >> message: ``XDM: too many retransmissions''. >xdm does not support XDMCP when running on SYSV machines. The lack of reliable >signal handling in a SYSV environment would make this quite difficult to >implement. The problem revolves around listening for UDP packets on a socket >and also waiting for child process termination. >The server is working fine in your case, the display manager is simply not >listening for the packets. > Given that HP-UX has BSD reliable signals and networking code, has anyone done the work to make it work? We kludged around it by setting the pingInterval down to 1. This works fairly well since it takes a fair chunk of a minute to boot the NCD, but I'd rather have it working correctly. -- Jeff Sparkes jsparkes@bnr.ca Cat: Is that what I think it is? Lister: What do you think it is? Cat: A big orange whirly thing in space!
timr@labtam.oz (Tim Roper) (06/13/90)
In <9006061659.AA05569@xenon.lcs.mit.edu> keith@EXPO.LCS.MIT.EDU (Keith Packard) writes: > ... >xdm does not support XDMCP when running on SYSV machines. The lack of reliable >signal handling in a SYSV environment would make this quite difficult to >implement. The problem revolves around listening for UDP packets on a socket >and also waiting for child process termination. >The server is working fine in your case, the display manager is simply not >listening for the packets. Even with System V.3 reliable signals and poll() the lack of a non-blocking wait() and the lack of a mask-driven form of sighold() will make WaitForSomething/WaitForChild ugly (ie. no equivalent of wait3 or sigsetmask). However I wonder whether the non-SYSV version is 100% reliable. For example, if a SIGHUP or SIGCHLD arrives just before calling select() in WaitForSomething() won't the rescan or dead child processing be delayed until the select() happens to be woken by another signal or an arriving XDMCP request? -Tim.