Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2012 12:00:12 -0600
From:      Gary Aitken <freebsd@dreamchaser.org>
To:        FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   /var overflow and named pipes?
Message-ID:  <5061F12C.3030304@dreamchaser.org>

next in thread | raw e-mail | index | archive | help
Hi all,

After running for a whopping 10 days or so, during which the use of my /var
as shown by df stayed at 62%, my system hung in X.
I was able to exit to a vty using <ctl><alt>fn

At that point I killed X using kill -SIGHUP

I then attempted to restart X.
It came up, but in a clobbered condition with some icons under xfwm4 not showing,
and some of the top menu bar text hosed (showing the square box char which usually
indicates bad character data).
I was able to shut it down by exiting the controlling xterm.

Somewhere in there I'm pretty sure I saw a message something like
  "Too many named pipes"

When trying to start X again, there were a boatload of messages:
  Fatal IO Error 35 (Resource temporarily unavailable) on X server :0.0
Messages showed up for programs being started in the startx script
 (xfwm4, xterm)
and some spawned by those
 (thunar...)
Then the message:
  XIO: Fatal IO error 35 (...)
  after 518 requests (388 known processed)
  with 0 events remaining

At that point, /var was at 109%

Examining /var, there was one huge file, Xorg.0.log.
Neither head nor tail nor the portions of the interior I've looked at
of that file shows anything particularly interesting;
however, what is interesting is it seems to contain a never-ending repeat
of reinitialization of the graphics card for monitor configuration.
I copied the offending Xorg.0.log file to save it in a place with more space
so I could examine it later, then deleted it.
Portion appended below.

However, when I restarted X I was still getting the fatal io errors,
so I shutdown the system and rebooted.

Also, since I was editing several (small) text files using vi, 
upon rebooting I got the usual messages about recovery.
One of those files, when I attempted recovery, indicated it was huge.
The file itself was small, ~180 lines, and had been saved already
so the huge recovery file was somehow corrupt.
I interrupted the recovery attempt (^C, took a *long* time to respond), 
checked /var size with du, and it was still only 62% 
so I may have averted another overflow there.

/var/log/messages shows nothing for 16 hrs and then:
Sep 24 16:22:01 breakaway kernel: pid 59110 (dd), uid 2 inumber 113248 on /var: filesystem full
Sep 24 16:33:00 breakaway kernel: pid 79946 (dd), uid 2 inumber 113453 on /var: filesystem full
Sep 24 17:33:00 breakaway last message repeated 501 times
etc...

I *think* all of the above is true; 
unfortunately, I didn't write notes until some things had passed and
some notes were incomplete as to where in the process they occurred.

Questions:

1. Can anyone shed light on the "too many named pipes" message?
   Is this likely caused by xfwm4 / thunar ipc?

2. Is the XIO error 35 (Resource temporarily unavailable) probably referring
   to the unavailability of named pipes?
   Or the unavailability of space in the Xorg.0.log file?
   Or does a pipe require space on /var and therefore when /var fills,
   no pipes are available?
   Are the X log files supposed to cycle the way system logs do?

3. Is there a way to see which processes have named pipes opened?
   After killing X and restarting,
     /usr/local/libexec/gam_server
   was still running and showing a runtime of 6472:54.82,
   very large compared to everything else.
   It's my understanding gam_server is used to detect changes in a file or
   directory; and might be using pipes for this purpose.
   Is this likely holding onto pipes?
   Is there an easy way to cause it to exit when X exits?

4. I've noticed the growing Xorg.0.log file in the past, 
   but since /var was staying small it seemed like I had plenty of room.
   Then it seemed to suddenly explode when the system hung.
   Is this a known issue with resetting the graphics card?
     (In this case an unsupported Visiontek 900331 which used Radeon HD 5550)
   There is a redhat bug which may be relevant:
     https://bugzilla.redhat.com/show_bug.cgi?id=820731
   Would getting a different graphics card likely solve this issue?

5. This *feels* like a sudden runaway condition.
   Shouldn't I normally get mail indicating /var is full before reaching 109%?
   There's 10 min between the first two full messages,
   and I didn't get *any* file sys full messages.

Minor Issue:
   /var/tmp contains a number of empty directories with names 
     "virtual-[user].xxxxxx" and "gvfs-[user]-xxxxxx"
   "cleanvar_enable" is set in /etc/defaults/rc.conf, I have not overridden it;
   but these dirs are obviously not being removed.
   Do I need to specifically turn on
     daily_clean_tmps_enable
     daily_clean_disks_enable
   Are there any reasons *not* to turn these on?
   In particular, if things are still running using some files in those places
   which were created early enough to be candidates for deletion?

Thanks for any insights,

Gary

================ Xorg.0.log repeated sequence =================
(II) RADEON(0): Monitor name: LCD1970NX
(II) RADEON(0): Serial No: 57302818YA
(II) RADEON(0): EDID (in hex):
(II) RADEON(0):         00ffffffffffff0038a3626601010101
(II) RADEON(0):         1e0f010380261e78eacb05a3584c9b25
(II) RADEON(0):         135054bfef80714f8140818001010101
(II) RADEON(0):         010101010101302a009851002a403070
(II) RADEON(0):         1300782d1100001e000000fd00384b1f
(II) RADEON(0):         510e000a202020202020000000fc004c
(II) RADEON(0):         4344313937304e580a202020000000ff
(II) RADEON(0):         00353733303238313859410a2020008f
(II) RADEON(0): EDID vendor "NEC", prod id 26210
Dac detection success
(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0
(II) RADEON(0): Output: HDMI-0, Detected Monitor Type: 0
(II) RADEON(0): EDID vendor "NEC", prod id 26210
(II) RADEON(0): Using hsync ranges from config file
(II) RADEON(0): Using vrefresh ranges from config file
(II) RADEON(0): Printing DDC gathered Modelines:
(II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
(II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz)
(II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
(II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz)
(II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz)
(II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
(II) RADEON(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz)
(II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
(II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz)
(II) RADEON(0): Output: DVI-0, Detected Monitor Type: 3
(II) RADEON(0): EDID data from the display on output: DVI-0 ----------------------
(II) RADEON(0): Manufacturer: NEC  Model: 6662  Serial#: 16843009
(II) RADEON(0): Year: 2005  Week: 30
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Digital Display Input
(II) RADEON(0): Max Image Size [cm]: horiz.: 38  vert.: 30
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): DPMS capabilities: StandBy Suspend Off
(II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.640 redY: 0.344   greenX: 0.299 greenY: 0.608
(II) RADEON(0): blueX: 0.145 blueY: 0.074   whiteX: 0.313 whiteY: 0.329
(II) RADEON(0): Supported established timings:
(II) RADEON(0): 720x400@70Hz
(II) RADEON(0): 640x480@60Hz
(II) RADEON(0): 640x480@67Hz
(II) RADEON(0): 640x480@72Hz
(II) RADEON(0): 640x480@75Hz
(II) RADEON(0): 800x600@56Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@72Hz
(II) RADEON(0): 800x600@75Hz
(II) RADEON(0): 832x624@75Hz
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): 1024x768@70Hz
(II) RADEON(0): 1024x768@75Hz
(II) RADEON(0): 1280x1024@75Hz
(II) RADEON(0): 1152x864@75Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported standard timings:
(II) RADEON(0): #0: hsize: 1152  vsize 864  refresh: 75  vid: 20337
(II) RADEON(0): #1: hsize: 1280  vsize 960  refresh: 60  vid: 16513
(II) RADEON(0): #2: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEON(0): Supported detailed timing:
(II) RADEON(0): clock: 108.0 MHz   Image Size:  376 x 301 mm
(II) RADEON(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) RADEON(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 v_border: 0
(II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 81 kHz, PixClock max 140 MHz




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5061F12C.3030304>