karnovsk
asked on
X server crash on RHL 7.2
Recently, I had to replaced the video card. The new card configured without any problems, but X server cannot start.
Here is startx error log:
XFree86 Version 3.3.6a / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: April 19, 2001
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.4.7-0.13.1smp i686 [ELF]
Configured drivers:
SVGA: server for SVGA graphics adaptors (Patchlevel 1):
s3_savage, NV1, STG2000, RIVA 128, RIVA TNT, RIVA TNT2,
RIVA ULTRA TNT2, RIVA VANTA, RIVA ULTRA VANTA, RIVA INTEGRATED,
GeForce 256, GeForce DDR, Quadro, GeForce2 GTS, GeForce2 GTS (rev1),
GeForce2 Ultra, Quadro 2 Pro, GeForce2 MX, GeForce2 MX DDR,
Quadro 2 MXR, ET4000, ET4000W32, ET4000W32i, ET4000W32i_rev_b,
ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a, ET4000W32p_rev_b,
ET4000W32p_rev_c, ET4000W32p_rev_d, ET6000, ET6100, et3000, pvga1,
wd90c00, wd90c10, wd90c30, wd90c24, wd90c31, wd90c33, gvga, r128, ati,
sis86c201, sis86c202, sis86c205, sis86c215, sis86c225, sis5597,
sis5598, sis6326, sis530, sis620, sis300, sis630, sis540, tvga8200lx,
tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga8900d, tvga9000,
tvga9000i, tvga9100b, tvga9200cxr, tgui9400cxi, tgui9420, tgui9420dgi,
tgui9430dgi, tgui9440agi, cyber9320, tgui9660, tgui9680, tgui9682,
tgui9685, cyber9382, cyber9385, cyber9388, cyber9397, cyber9520,
cyber9525, 3dimage975, 3dimage985, cyber9397dvd, blade3d, cyberblade,
clgd5420, clgd5422, clgd5424, clgd5426, clgd5428, clgd5429, clgd5430,
clgd5434, clgd5436, clgd5446, clgd5480, clgd5462, clgd5464, clgd5465,
clgd6205, clgd6215, clgd6225, clgd6235, clgd7541, clgd7542, clgd7543,
clgd7548, clgd7555, clgd7556, ncr77c22, ncr77c22e, cpq_avga, mga2064w,
mga1064sg, mga2164w, mga2164w AGP, mgag200, mgag100, mgag400, oti067,
oti077, oti087, oti037c, al2101, ali2228, ali2301, ali2302, ali2308,
ali2401, cl6410, cl6412, cl6420, cl6440, video7, ark1000vl, ark1000pv,
ark2000pv, ark2000mt, mx, realtek, s3_virge, AP6422, AT24, AT3D,
s3_svga, NM2070, NM2090, NM2093, NM2097, NM2160, NM2200, ct65520,
ct65525, ct65530, ct65535, ct65540, ct65545, ct65546, ct65548,
ct65550, ct65554, ct65555, ct68554, ct69000, ct64200, ct64300,
mediagx, V1000, V2100, V2200, p9100, spc8110, i740, i740_pci,
Voodoo Banshee, Voodoo3, i810, i810-dc100, i810e, i815, smi, generic
(using VT number 7)
XF86Config: /usr/X11R6/lib/X11/XF86Con
(**) stands for supplied, (--) stands for probed/default values
(**) XKB: keycodes: "xfree86"
(**) XKB: types: "default"
(**) XKB: compat: "default"
(**) XKB: symbols: "us(pc101)"
(**) XKB: geometry: "pc"
(**) XKB: rules: "xfree86"
(**) XKB: model: "pc101"
(**) XKB: layout: "us"
(**) Mouse: type: PS/2, device: /dev/mouse, buttons: 3
(**) Mouse: 3 button emulation (timeout: 50ms)
(**) SVGA: Graphics device ID: "Trident TGUI9660 (generic)"
(**) SVGA: Monitor ID: "Packard Bell PnP 3025"
(**) FontPath set to "unix/:7100"
(--) SVGA: PCI: Trident TGUI 96xx rev 211, Memory @ 0xd9400000, 0xd9800000
(--) Trident chipset version: 0xd3 (TGUI96xx)
(--) SVGA: BIOS reports Clock Control Bits 0x3
(--) SVGA: Detected a Trident ProVidia 9685.
(--) SVGA: Revision 33.
(--) SVGA: TV interface is NTSC
(--) SVGA: DAC is enabled for TV
(--) SVGA: VGA display is connected.
(--) SVGA: Using Trident programmable clocks
(--) SVGA: chipset: tgui9685
(--) SVGA: videoram: 4096k
(**) SVGA: Using 8 bpp, Depth 8, Color weight: 666
(--) SVGA: Maximum allowed dot-clock: 170.000 MHz
(**) SVGA: Mode "640x480": mode clock = 31.500
(--) SVGA: Virtual resolution set to 640x480
(--) SVGA: SpeedUp code selection modified because virtualX != 1024
(--) SVGA: Using Linear Frame Buffer at 0x0d9400000, Size 4MB
error opening security policy file /usr/X11R6/lib/X11/xserver
_FontTransSocketUNIXConnec
failed to set default font path 'unix/:7100'
Fatal server error:
could not open default font 'fixed'
When reporting a problem related to a server crash, please send
the full server output, not just the last messages
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.
Here is startx error log:
XFree86 Version 3.3.6a / X Window System
(protocol Version 11, revision 0, vendor release 6300)
Release Date: April 19, 2001
If the server is older than 6-12 months, or if your card is newer
than the above date, look for a newer version before reporting
problems. (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.4.7-0.13.1smp i686 [ELF]
Configured drivers:
SVGA: server for SVGA graphics adaptors (Patchlevel 1):
s3_savage, NV1, STG2000, RIVA 128, RIVA TNT, RIVA TNT2,
RIVA ULTRA TNT2, RIVA VANTA, RIVA ULTRA VANTA, RIVA INTEGRATED,
GeForce 256, GeForce DDR, Quadro, GeForce2 GTS, GeForce2 GTS (rev1),
GeForce2 Ultra, Quadro 2 Pro, GeForce2 MX, GeForce2 MX DDR,
Quadro 2 MXR, ET4000, ET4000W32, ET4000W32i, ET4000W32i_rev_b,
ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a, ET4000W32p_rev_b,
ET4000W32p_rev_c, ET4000W32p_rev_d, ET6000, ET6100, et3000, pvga1,
wd90c00, wd90c10, wd90c30, wd90c24, wd90c31, wd90c33, gvga, r128, ati,
sis86c201, sis86c202, sis86c205, sis86c215, sis86c225, sis5597,
sis5598, sis6326, sis530, sis620, sis300, sis630, sis540, tvga8200lx,
tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga8900d, tvga9000,
tvga9000i, tvga9100b, tvga9200cxr, tgui9400cxi, tgui9420, tgui9420dgi,
tgui9430dgi, tgui9440agi, cyber9320, tgui9660, tgui9680, tgui9682,
tgui9685, cyber9382, cyber9385, cyber9388, cyber9397, cyber9520,
cyber9525, 3dimage975, 3dimage985, cyber9397dvd, blade3d, cyberblade,
clgd5420, clgd5422, clgd5424, clgd5426, clgd5428, clgd5429, clgd5430,
clgd5434, clgd5436, clgd5446, clgd5480, clgd5462, clgd5464, clgd5465,
clgd6205, clgd6215, clgd6225, clgd6235, clgd7541, clgd7542, clgd7543,
clgd7548, clgd7555, clgd7556, ncr77c22, ncr77c22e, cpq_avga, mga2064w,
mga1064sg, mga2164w, mga2164w AGP, mgag200, mgag100, mgag400, oti067,
oti077, oti087, oti037c, al2101, ali2228, ali2301, ali2302, ali2308,
ali2401, cl6410, cl6412, cl6420, cl6440, video7, ark1000vl, ark1000pv,
ark2000pv, ark2000mt, mx, realtek, s3_virge, AP6422, AT24, AT3D,
s3_svga, NM2070, NM2090, NM2093, NM2097, NM2160, NM2200, ct65520,
ct65525, ct65530, ct65535, ct65540, ct65545, ct65546, ct65548,
ct65550, ct65554, ct65555, ct68554, ct69000, ct64200, ct64300,
mediagx, V1000, V2100, V2200, p9100, spc8110, i740, i740_pci,
Voodoo Banshee, Voodoo3, i810, i810-dc100, i810e, i815, smi, generic
(using VT number 7)
XF86Config: /usr/X11R6/lib/X11/XF86Con
(**) stands for supplied, (--) stands for probed/default values
(**) XKB: keycodes: "xfree86"
(**) XKB: types: "default"
(**) XKB: compat: "default"
(**) XKB: symbols: "us(pc101)"
(**) XKB: geometry: "pc"
(**) XKB: rules: "xfree86"
(**) XKB: model: "pc101"
(**) XKB: layout: "us"
(**) Mouse: type: PS/2, device: /dev/mouse, buttons: 3
(**) Mouse: 3 button emulation (timeout: 50ms)
(**) SVGA: Graphics device ID: "Trident TGUI9660 (generic)"
(**) SVGA: Monitor ID: "Packard Bell PnP 3025"
(**) FontPath set to "unix/:7100"
(--) SVGA: PCI: Trident TGUI 96xx rev 211, Memory @ 0xd9400000, 0xd9800000
(--) Trident chipset version: 0xd3 (TGUI96xx)
(--) SVGA: BIOS reports Clock Control Bits 0x3
(--) SVGA: Detected a Trident ProVidia 9685.
(--) SVGA: Revision 33.
(--) SVGA: TV interface is NTSC
(--) SVGA: DAC is enabled for TV
(--) SVGA: VGA display is connected.
(--) SVGA: Using Trident programmable clocks
(--) SVGA: chipset: tgui9685
(--) SVGA: videoram: 4096k
(**) SVGA: Using 8 bpp, Depth 8, Color weight: 666
(--) SVGA: Maximum allowed dot-clock: 170.000 MHz
(**) SVGA: Mode "640x480": mode clock = 31.500
(--) SVGA: Virtual resolution set to 640x480
(--) SVGA: SpeedUp code selection modified because virtualX != 1024
(--) SVGA: Using Linear Frame Buffer at 0x0d9400000, Size 4MB
error opening security policy file /usr/X11R6/lib/X11/xserver
_FontTransSocketUNIXConnec
failed to set default font path 'unix/:7100'
Fatal server error:
could not open default font 'fixed'
When reporting a problem related to a server crash, please send
the full server output, not just the last messages
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.
ASKER
xfs is not running.
The FontPath entry in /etc/X11/XF86Config is like you write:
FontPath "unix/:7100"
From the server output, "failed to set default font path 'unix/:7100'", it looks as if the server has read the config file correctly, but something happened afterwards.
The FontPath entry in /etc/X11/XF86Config is like you write:
FontPath "unix/:7100"
From the server output, "failed to set default font path 'unix/:7100'", it looks as if the server has read the config file correctly, but something happened afterwards.
ASKER
Sorry, I was probably wrong about xfs. I don's see xfs with ps -ef, but when the system boots/shuts down, I see that xfs is started/stopped.
"ps -ef" should show xfs running. Also, "netstat -n"
should show an entry for a socket in /tmp/.font-unix/ or port tcp/7100 or both.
It could be that xfs is starting and then immediately dying. Try restarting it from its init script and looking for errors in the syslog output.
should show an entry for a socket in /tmp/.font-unix/ or port tcp/7100 or both.
It could be that xfs is starting and then immediately dying. Try restarting it from its init script and looking for errors in the syslog output.
redhat comes out of the box with /tmp directory permissions set to
user root : rwx
owner group : r-x
user everybody : r-x
when the 7.2 is booting up it runs a set of rc scripts.
One of those is
--------------------
/etc/rc.d/init.d/xfs
--------------------
under the hood it starts xfs with the following parameters
xfs -droppriv -daemon
and in particular the -droppriv is the cause of the failure because it makes xfs service to run under account of built in user "xfs" Now, if you look at the permissions settings the world ( user everybody ) which security context is used to start xfs service, may not write under the /tmp directory. Why user xfs is using security context of user everybody – because user xfs has no any specific privileges granted to it to access directory /tmp and thus uses default context to access directory and default context in this case is the security context of user "everybody" - the world. Why is it so important, when xfs is starting it needs to create special device called socket, to complete the task, it needs to write a marker for this socket under the /tmp directory, exact name of this special device is
/tmp/.font-unix/fs7100
as you noted the xfs user may not write under the /tmp directory on redhat 7.2 using default settings, hence xfs is unable to start, causing to fail X server on start as well, in particular KDE depends on xfs being running. The fix at this moment is to change security settings on the /tmp directory you need to run the command
chmod 777 /tmp
this is not very secure settings though and experiment showed that once xfs is started it can continue to run if you switch default security settings back using command
chmod 755 /tmp
make sure that command chmod is run when you logged on with root account privileges. I asked an expert to explain if this setting was known to break X or other applications. Apparently redhat released it as a default, and I have a hope that this was a well thought out thing. So far I got quite general comments that are not holding to be correct in many places. Here is the link.
https://www.experts-exchange.com/questions/20348307/security-concern.html
May I also suggest you to visit ftp://updates.redghat.com and apply all the patches available on this site. I am not a typical Linux guru, it just this trouble caused me to forget about my RH7.2 for a few months until I had time and resources to discover all the gory details. Whishing you to have better experience.
--Cheers
user root : rwx
owner group : r-x
user everybody : r-x
when the 7.2 is booting up it runs a set of rc scripts.
One of those is
--------------------
/etc/rc.d/init.d/xfs
--------------------
under the hood it starts xfs with the following parameters
xfs -droppriv -daemon
and in particular the -droppriv is the cause of the failure because it makes xfs service to run under account of built in user "xfs" Now, if you look at the permissions settings the world ( user everybody ) which security context is used to start xfs service, may not write under the /tmp directory. Why user xfs is using security context of user everybody – because user xfs has no any specific privileges granted to it to access directory /tmp and thus uses default context to access directory and default context in this case is the security context of user "everybody" - the world. Why is it so important, when xfs is starting it needs to create special device called socket, to complete the task, it needs to write a marker for this socket under the /tmp directory, exact name of this special device is
/tmp/.font-unix/fs7100
as you noted the xfs user may not write under the /tmp directory on redhat 7.2 using default settings, hence xfs is unable to start, causing to fail X server on start as well, in particular KDE depends on xfs being running. The fix at this moment is to change security settings on the /tmp directory you need to run the command
chmod 777 /tmp
this is not very secure settings though and experiment showed that once xfs is started it can continue to run if you switch default security settings back using command
chmod 755 /tmp
make sure that command chmod is run when you logged on with root account privileges. I asked an expert to explain if this setting was known to break X or other applications. Apparently redhat released it as a default, and I have a hope that this was a well thought out thing. So far I got quite general comments that are not holding to be correct in many places. Here is the link.
https://www.experts-exchange.com/questions/20348307/security-concern.html
May I also suggest you to visit ftp://updates.redghat.com and apply all the patches available on this site. I am not a typical Linux guru, it just this trouble caused me to forget about my RH7.2 for a few months until I had time and resources to discover all the gory details. Whishing you to have better experience.
--Cheers
ASKER
Thank you, pgb1008 and miron, for your advice.
To pgb1008:
-----------
* I have started xfs by
/etc/rc3.d/S90xfs start
and got
starting xfs [OK]
Still no xfs in ps -ef.
* Have run
/etc/rc3.d/S90xfs status
Got
xfs dead but pid file exists
* Checked /var/log/messages. It contains the following lines:
xfs: xfs startup succeeded
xfs: listening on port 7100
* netstat -n mentions neither port 7100 nor font-unix.
To miron:
---------
The permissions of /tmp are rwxrwxtwt (777 + sticky bit)
To pgb1008:
-----------
* I have started xfs by
/etc/rc3.d/S90xfs start
and got
starting xfs [OK]
Still no xfs in ps -ef.
* Have run
/etc/rc3.d/S90xfs status
Got
xfs dead but pid file exists
* Checked /var/log/messages. It contains the following lines:
xfs: xfs startup succeeded
xfs: listening on port 7100
* netstat -n mentions neither port 7100 nor font-unix.
To miron:
---------
The permissions of /tmp are rwxrwxtwt (777 + sticky bit)
pls,
apply all patches as appropriate for xfs, fonts, X and remove files
/var/lock/subsys/xfs
/var/run/xfs.pid
Cheers
apply all patches as appropriate for xfs, fonts, X and remove files
/var/lock/subsys/xfs
/var/run/xfs.pid
Cheers
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Got it!!!
The problem was that there was no space left on /. I have freed some space, and now the problem disappeared.
Of course, I should have checked such thing first. (As an excuse I can tell that I am used to Sun/Solaris where /tmp resides in the memory, not on a disk, and is wiped out on each reboot).
Thank you both for helping me, especially Miron who explained the role of /tmp.
The problem was that there was no space left on /. I have freed some space, and now the problem disappeared.
Of course, I should have checked such thing first. (As an excuse I can tell that I am used to Sun/Solaris where /tmp resides in the memory, not on a disk, and is wiped out on each reboot).
Thank you both for helping me, especially Miron who explained the role of /tmp.
"...
I can tell that I am used to Sun/Solaris where /tmp resides in the memory, not on a disk
..."
it was my impression as well that on Linux /tmp suppose to be an extension of virtual memory mapped to disk while /dev/mem is a physical memory. Now, I should point out that /. fill up was happening at a very peculiar point in time - when you were starting X, and exactly when you needed to check for socket descriptor under /tmp, while the rest of descriptors needed to start X under ~/, /var, and the same /tmp directories were creating successfully and it was happening over and over again.
Cheers
I can tell that I am used to Sun/Solaris where /tmp resides in the memory, not on a disk
..."
it was my impression as well that on Linux /tmp suppose to be an extension of virtual memory mapped to disk while /dev/mem is a physical memory. Now, I should point out that /. fill up was happening at a very peculiar point in time - when you were starting X, and exactly when you needed to check for socket descriptor under /tmp, while the rest of descriptors needed to start X under ~/, /var, and the same /tmp directories were creating successfully and it was happening over and over again.
Cheers
Check the FontPath in the /etc/X11/XF86Config. It should be:
FontPath "unix/:7100"
if you are using a font server (check that xfs is running), or something like:
FontPath "/usr/X11R6/lib/X11/fonts/
FontPath "/usr/X11R6/lib/X11/fonts/
FontPath "/usr/X11R6/lib/X11/fonts/
FontPath "/usr/X11R6/lib/X11/fonts/
FontPath "/usr/X11R6/lib/X11/fonts/
if you want the X server to read the fonts directly.