• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 407
  • Last Modified:

fatal server error when trying to start xserver via: startx

I'm running redhat 7.2. My machine has been running
on a local network and running fine. I now need this
machine to run independent of the network. When I take out
my ethernet connection and reboot, I get an error message
when trying to start the xserver via: startx from the command line.
It gives me a message:
XSERVTransSocketINETCreateListener:  ...SocketCreateListener( ) failed
XSERVTransMakeAllCOTServerListeners: server already running
Fatal server error:
Cannot establish any listening sockets- Make sure an X server isn't already running.
I don't understand why and what i need to do?
0
mitchguy
Asked:
mitchguy
  • 3
  • 3
1 Solution
 
MFCRichCommented:
Does the output of 'ps -ef' show any X servers or display managers (xdm, gdm, kdm) running?
0
 
mitchguyAuthor Commented:
I changed the run level to 3 so the gui interface doesn't
try to start. So now just using the text window with this setting when I type startx with my ethernet connection
out I get this:
YPBINDPROC_DOMAIN: Domain not bound

If I plug in my ethernet cable it and reboot startx comes up fine.

So my current state is startx still doesn't work,
but the previous error message is gone and now I just have to get past  
YPBINDPROC_DOMAIN: Domain not bound
0
 
jlevieCommented:
That error indicates that you system was using NIS on the network. You'll have to change the system configuration to not use NIS in order to use it off the network. And you ought to able to do that via authconfig on a console screen.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
mitchguyAuthor Commented:
would I have to do that everytime?
 This machine is going to be used
as portable even though it's not a laptop.
The thing that is most confusing is that another
machine which had just been built with a new linux
install works as we want this one to work. If it's
booted up with the ethernet cable in it's fine and
if it's booted up with the cable out it tries to bind to NIS but gives up shortly after and then moves on.
starting X works fine without having to change anything.
So somebody changed something on the machine we want,
be we can't figure out what it is as of yet.
0
 
jlevieCommented:
If I were to configure a machine to be a portable I certainly would not enable NIS on that box. But, if you must have NIS when the machine si connected to the network, you could try disabling the automatic startup of ypbind with:

chkconfig ypbind off

You'll also have to insure that the local passwd, shadow, group, and gshadow files have the correct data for those users that need to be able to log into the system. And if your NIS environment is using automounted home dirs the system will have to have local copies of the user's home dirs, at the very least.

My personal preference, for a portable machine, is to not use NIS. The portable needs local accounts for each user and local home dirs. To make it easy to use when the system is on the network, I always use an aoutomounter. The I can have something like:

wilowisp   type:=nfs;rhost:=wilowisp.entrophy-free.net;rfs:=/nfs0/levie

jim        host==chaos;type:=link;fs:=/nfs0/jim
           host!=chaos;type:=nfs;rhost:=chaos.entrophy-free.net;rfs:=/nfs0/jim

whick lets me access my home dir on the portable as /home/jim and my home dir on a networked system as /home/wilowisp
0
 
mitchguyAuthor Commented:
I won't be able to try the stuff your telling me until monday. I'm stil a little confused with what exactly
the sequence of events that is happening. First off let me
give you a little more info. The machine will be used exclusively for demonstration of software I developed.
We had planned only for root as a user when off the network. So when off the network I can log in as root and
then it's when I type startx I get the repeated message
YPBINDPROC_DOMAIN: Domain not bound

Could you explain what is happening to cause this?
you may have already, but I'm not understanding.

Is it confusing the network root with the local root?
when I log in as root off the network it gives me
one message of YPBINDPROC_DOMAIN: Domain not bound
and then I get a prompt as root as oppossed to repeating
YPBINDPROC_DOMAIN: Domain not bound over and over
when I type startx.

0
 
jlevieCommented:
If NIS is configured correctly, there should not be a root user in the NIS tables, so that shouln'd be a problem. And you can easily check for this error by doing:

ypcat passwd | more

from a networked system. That will return a list of what users are defined in the NIS passwd map.

Based on the error you see when off the net, it looks to me like NIS is used for the networked machines for at least the distribution of user account & system information (passwd, group, hosts, services, etc). Depending on exactly what NIS maps are active, definitions of automount points for home dirs and printcap maps may also be in NIS. Since a machine that is a member of an NIS domain needs those defintions as soon as it boots, a system startup script will attempt to bind to the NIS server and if it's not available you'll see the YPBIND error. Telling the system not to start ypbind at boot may be all that's required to eliminate the error.

Now, since the system was configured to be a member of an NIS domain, there may be other things that need adjustment. It should be possible to configure those such that the box will work within the NIS domain (when networked) and as a standalone. In particular, you need to be sure that /etc/hosts has a localhost record. And if the network uses fixed IP's you'll need a hosts record. I've already touched on the need for local accounts and home dirs, but you should check /etc/nsswitch.conf and make sure that each item (hosts, passwd, etc) is set to use local files first.

As an aside, unless your demonstration really requires the software to be run by root, you'd be well advised to create an ordinary user local account to run the demo from. It's just way to easy when logged in a root to damage the system.
0

Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now