Skip to main content

We have been running four Xserves (first-generation Intel) on 10.6.4 since
August with no (critical) issues. Just this past Wednesday, I got this
message:

The volume ServerHD on [Xserve name] is running out of free space.
It has only 7.46 GB (9.82%) free.

This Xserve only has two Xserve processes running, file sharing for AFP, and
file sharing for SMB. It also runs Atempo Time Navigator daemons, but is not
the catalog server ‹ just one of the servers that is backed up.

After the above email notification, I kept an eye on it, and it was bleeding
disk space over a GB per hour. Using the du command did not show any large
files or directories. Similarly, using the utility WhatSize did not show any
large files or directories. I (and some others) poked around in Unix but
could not discover the issue or find any runaway files.

Restarting the Xserve immediately took the available space back up to 73GB,
but it also immediately started bleeding again, and is once again down to
zero.

One of our system administrators suspects that the disk space is being used
up as virtual memory, but wouldn't those files show up with the du command?

One additional oddity about this particular Xserve: When it is booted, it
does not go immediately to the sign-on screen, but goes to a Unix screen and
seems to boot in Unix before going to the GUI. The Apple engineer noticed
this when he was installing 10.6.4, and it is the only one of four Xserves
that exhibits this behavior. All four were wiped and clean install of 10.6.4
Server in August. Still, it has been running just fine until the day before
Thanksgiving when it went haywire. This is an important file server for us,
and I plan on opening a call with Apple on Monday. I also plan on
automatically restarting the server in the wee hours of the morning on a
daily basis until the issue can be resolved.

Anyone have any suggestions on tracking down and eliminating this problem?
Thanks!

--
Karl Schoenefeld | IT Department
SGS St Louis | 1035 Hanley Industrial Court | St Louis, MO 63144
Direct: 314-918-3126 | Cell: 314-680-0359

While you may not have found the culprit yet, this sounds like a classic
On 11/26/10 3:36 PM, "Schoenefeld, Karl" <Karl.Schoenefeld at SGSintl.com> wrote:
case of a log file getting bloated.

I'm not sure what UNIX method you used but this line has always worked
well for me:

du -ch -d 1 /

This is "disk utility".

The -c displays a grand total for your entire disk at the end.

The -h makes the output human readable.

The "-d 1" only displays totals for one item deep. This will give you a
total each for Applications, Library, System, Users, etc, private, etc.

More than likely you're looking for the /private/var/log directory to be
larger than normal. If you find that it is then re-run the command:

du -ch -d 1 /private/var/log

and keep narrowing down 'til you find the bloating file. You can try
deleting it but you may find that you need to troubleshoot the process
that writes to the file. The log should indicate what's going wrong.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Terms & ConditionsCookie settingsAccessibility statement