Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2002 13:53:03 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Brad Knowles <brad.knowles@skynet.be>
Cc:        Mike Meyer <mwm-dated-1012390758.50933b@mired.org>, chip <chip@wiegand.org>, freebsd-chat@freebsd.org
Subject:   Re: Bad disk partitioning policies (was: "Re: FreeBSD Intaller  (was   "Re: ... RedHat ...")")
Message-ID:  <3C51D3BF.FB72A84C@mindspring.com>
References:  <20020123114658.A514@lpt.ens.fr> <20020123124025.A60889@HAL9000.wox.org> <3C4F5BEE.294FDCF5@mindspring.com>	<20020123223104.SM01952@there> <p0510122eb875d9456cf4@[10.0.1.3]> <15440.35155.637495.417404@guru.mired.org> <p0510123fb876493753e0@[10.0.1.3]> <15440.53202.747536.126815@guru.mired.org> <p05101242b876db6cd5d7@[10.0.1.3]> <15441.17382.77737.291074@guru.mired.org> <p05101245b8771d04e19b@[10.0.1.3]>

next in thread | previous in thread | raw e-mail | index | archive | help
There is a fundamental problem with /var.

Having /var/run and /var/log on the same partition means
that if your log files fill up, you will be unable to
start some programs.

Having /var/log on the same parititon as TMPDIR (for whatever
program, and by whatever means... e.g. environment, sendmail.cf,
or a symbolic link of /tmp to /var/tmp, etc.) means that if
you fill up your log files, then you fill up your /tmp
directory.  For email, this means no more email received,
and other programs have similar bad behaviour.

Historically, I have seen this very often with programs that
rely on these resources; sendmail has been a particular
problem, though not because of any fault on its part: it's
just that email is about the most visible service failure
you can have with any server, no matter what else you run on
it.

My particular problems (in a commercial product, which sold,
or leased, tens of thousands of units) was that "newsyslog"
would not recreate history when it failed and then was
rerun, and "samba" log files are hard to rotate using the
standard means.

Specifically, if cron dies (common, particularly if your
password file is read-only, due to an infrequent VM bug
having to do with copy-on-write of modified read-only
pages from the mmap of the passwd.db files, since "cron"
rewrites the password entry from getpwent(3) in place,
making it dirty, by its assumption that the pointers
point to a static buffer in libc, not a memory mapped
region in a read-only file), then newsyslog stops being
run by cron.

When that happens, log files become huge, and then when
newsyslog is restarted, it only "rolls the files over" by
one -- leaving the huge accumulated log files as the
one-behind ...and incidently, leaving /var/log *still full*.


In any case, the point of this is to note that, no matter
how you slice it, there is going to be a monster in the
closet, waiting for your mother to turn out the light and
close the door.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C51D3BF.FB72A84C>