LDP/LDP/guide/docbook/Linux-Filesystem-Hierarchy/var.xml

288 lines
16 KiB
XML

<sect1 id="var">
<title>/var</title>
<para>
Contains variable data like system logging files, mail and printer
spool directories, and transient and temporary files.
Some portions of /var are not shareable between different systems. For
instance, /var/log, /var/lock, and /var/run. Other portions may be shared,
notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.
Why not put it into /usr? Because there might
be circumstances when you may want to mount /usr as read-only, e.g. if it is
on a CD or on another computer. &#39;/var&#39; contains variable data, i.e.
files and directories the system must be able to write to during operation,
whereas /usr should only contain static data. Some directories can
be put onto separate partitions or systems, e.g. for easier backups, due to
network topology or security concerns. Other directories have to be on the
root partition, because they are vital for the boot process.
&#39;Mountable&#39; directories are: &#39;/home&#39;, &#39;/mnt&#39;,
&#39;/tmp&#39;, &#39;/usr&#39; and &#39;/var&#39;. Essential for booting
are: &#39;/bin&#39;, &#39;/boot&#39;, &#39;/dev&#39;, &#39;/etc&#39;,
&#39;/lib&#39;, &#39;/proc&#39; and &#39;/sbin&#39;.
</para>
<para>
<screen>
If /var cannot be made a separate partition, it is often preferable to move /
var out of the root partition and into the /usr partition. (This is sometimes
done to reduce the size of the root partition or when space runs low in the
root partition.) However, /var must not be linked to /usr because this makes
separation of /usr and /var more difficult and is likely to create a naming
conflict. Instead, link /var to /usr/var.
Applications must generally not add directories to the top level of /var. Such
directories should only be added if they have some system-wide implication, and
in consultation with the FHS mailing list.
</screen>
</para>
<para><variablelist><varlistentry><term>/var/backups</term><listitem><para>Directory
containing backups of various key system files such as /etc/shadow,
/etc/group, /etc/inetd.conf and dpkg.status. They are normally renamed to
something like dpkg.status.0, group.bak, gshadow.bak, inetd.conf.bak,
passwd.bak, shadow.bak</para></listitem></varlistentry>
<varlistentry><term>/var/cache</term><listitem><para>Is
intended for cached data from applications. Such data is locally generated
as a result of time-consuming I/O or calculation. This data can generally be
regenerated or be restored. Unlike /var/spool, files here can be deleted
without data loss. This data remains valid between invocations of the
application and rebooting of the system. The existence of a separate
directory for cached data allows system administrators to set different disk
and backup policies from other directories in /var.</para></listitem></varlistentry>
<varlistentry><term>/var/cache/fonts</term><listitem><para>Locally-generated
fonts. In particular, all of the fonts which are automatically generated by
mktexpk must be located in appropriately-named subdirectories of /var/cache/
fonts. </para></listitem></varlistentry>
<varlistentry><term>/var/cache/man</term><listitem><para>A
cache for man pages that are formatted on demand. The source for manual
pages is usually stored in /usr/share/man/; some manual pages might come
with a pre-formatted version, which is stored in /usr/share/man/cat* (this
is fairly rare now). Other manual pages need to be formatted when they are
first viewed; the formatted version is then stored in /var/man so that the
next person to view the same page won&#39;t have to wait for it to be
formatted (/var/catman is often cleaned in the same way temporary
directories are cleaned).</para></listitem></varlistentry>
<varlistentry><term>/var/cache/&#39;package-name&#39;</term><listitem><para>Package
specific cache data.</para></listitem></varlistentry>
<varlistentry><term>/var/cache/www</term><listitem><para>WWW
proxy or cache data.</para></listitem></varlistentry>
<varlistentry><term>/var/crash</term><listitem><para>This
directory will eventually hold system crash dumps. Currently, system crash
dumps are not supported under Linux. However, development is already
complete and is awaiting unification into the Linux kernel.</para></listitem></varlistentry>
<varlistentry><term>/var/db</term><listitem><para>Data
bank store.</para></listitem></varlistentry>
<varlistentry><term>/var/games</term><listitem><para>Any
variable data relating to games in /usr is placed here. It holds variable
data that was previously found in /usr. Static data, such as help text,
level descriptions, and so on, remains elsewhere though, such as in
/usr/share/games. The separation of /var/games and /var/lib as in release
FSSTND 1.2 allows local control of backup strategies, permissions, and disk
usage, as well as allowing inter-host sharing and reducing clutter in
/var/lib. Additionally, /var/games is the path traditionally used by BSD.</para></listitem></varlistentry>
<varlistentry><term>/var/lib</term><listitem><para>Holds
dynamic data libraries/files like the rpm/dpkg database and game scores.
Furthermore, this hierarchy holds state information pertaining to an
application or the system. State information is data that programs modify
while they run, and that pertains to one specific host. Users shouldn&#39;t
ever need to modify files in /var/lib to configure a package&#39;s
operation. State information is generally used to preserve the condition of
an application (or a group of inter-related applications) between
invocations and between different instances of the same application. An
application (or a group of inter-related applications) use a subdirectory of
/var/lib for their data. There is one subdirectory, /var/lib/misc, which is
intended for state files that don&#39;t need a subdirectory; the other
subdirectories should only be present if the application in question is
included in the distribution. /var/lib/&#39;name&#39; is the location that
must be used for all distribution packaging support. Different distributions
may use different names, of course.</para></listitem></varlistentry>
<varlistentry><term>/var/local</term><listitem><para>Variable
data for local programs (i.e., programs that have been installed by the
system administrator) that are installed in /usr/local (as opposed to a
remotely mounted &#39;/var&#39; partition). Note that even locally installed
programs should use the other /var directories if they are appropriate,
e.g., /var/lock.</para></listitem></varlistentry>
<varlistentry><term>/var/lock</term><listitem><para>Many
programs follow a convention to create a lock file in /var/lock to indicate
that they are using a particular device or file. This directory holds those
lock files (for some devices) and hopefully other programs will notice the
lock file and won&#39;t attempt to use the device or file.</para><para>Lock
files should be stored within the /var/lock directory structure. Lock files
for devices and other resources shared by multiple applications, such as the
serial device lock files that were originally found in either
/usr/spool/locks or /usr/spool/uucp, must now be stored in /var/lock. The
naming convention which must be used is LCK.. followed by the base name of
the device file. For example, to lock /dev/ttyS0 the file LCK..ttyS0 would
be created. The format used for the contents of such lock files must be the
HDB UUCP lock file format. The HDB format is to store the process identifier
(PID) as a ten byte ASCII decimal number, with a trailing newline. For
example, if process 1230 holds a lock file, it would contain the eleven
characters: space, space, space, space, space, space, one, two, three, zero,
and newline.</para></listitem></varlistentry>
<varlistentry><term>/var/log</term><listitem><para>Log
files from the system and various programs/services, especially login
(/var/log/wtmp, which logs all logins and logouts into the system) and
syslog (/var/log/messages, where all kernel and system program message are
usually stored). Files in /var/log can often grow indefinitely, and may
require cleaning at regular intervals. Something that is now normally
managed via log rotation utilities such as &#39;logrotate&#39;. This utility
also allows for the automatic rotation compression, removal and mailing of
log files. Logrotate can be set to handle a log file daily, weekly, monthly
or when the log file gets to a certain size. Normally, logrotate runs as a
daily cron job. This is a good place to start troubleshooting general
technical problems.</para></listitem></varlistentry>
<varlistentry><term>/var/log/auth.log</term><listitem><para>Record
of all logins and logouts by normal users and system processes.</para></listitem></varlistentry>
<varlistentry><term>/var/log/btmp</term><listitem><para>Log
of all attempted bad logins to the system. Accessed via the lastb command.</para></listitem></varlistentry>
<varlistentry><term>/var/log/debug</term><listitem><para>Debugging
output from various packages.</para></listitem></varlistentry>
<varlistentry><term>/var/log/dmesg</term><listitem><para>Kernel
ring buffer. The content of this file is referred to by the dmesg command.</para></listitem></varlistentry>
<varlistentry><term>/var/log/gdm/</term><listitem><para>GDM
log files. Normally a subset of the last X log file. See /var/log/xdm.log
for mode details.</para></listitem></varlistentry>
<varlistentry><term>/var/log/kdm.log</term><listitem><para>KDM
log file. Normally a subset of the last X log file. See /var/log/xdm.log for
more details.</para></listitem></varlistentry>
<varlistentry><term>/var/log/messages</term><listitem><para>System
logs.</para></listitem></varlistentry>
<varlistentry><term>/var/log/pacct</term><listitem><para>Process
accounting is the bookkeeping of process activity. The raw data of process
activity is maintained here. Three commands can be used to access the
contents of this file dump-acct, sa (summary of process accounting) and
lastcomm (list the commands executed on the system).</para></listitem></varlistentry>
<varlistentry><term>/var/log/utmp</term><listitem><para>Active
user sessions. This is a data file and as such it can not be viewed
normally. A human-readable form can be created via the dump-utmp command or
through the w, who or users commands.</para></listitem></varlistentry>
<varlistentry><term>/var/log/wtmp</term><listitem><para>Log
of all users who have logged into and out of the system. The last command
can be used to access a human readable form of this file. It also lists
every connection and run-level change.</para></listitem></varlistentry>
<varlistentry><term>/var/log/xdm.log</term><listitem><para>XDM
log file. Normally subset of the last X startup log and pretty much useless
in light of the details the X logs is able to provide us with. Only consult
this file if you have XDM specific issues otherwise just use the X logfile.</para></listitem></varlistentry>
<varlistentry><term>/var/log/XFree86.0.log,
/var/log/XFree86.?.log</term><listitem><para>X startup logfile. An excellent
resource for uncovering problems with X configuration. Log files are
numbered according to when they were last used. For example, the last log
file would be stored in /var/log/XFree86.0.log, the next
/var/log/XFree86.9.log, so on and so forth.</para></listitem></varlistentry>
<varlistentry><term>/var/log/syslog</term><listitem><para>The
&#39;system&#39; log file. The contents of this file is managed via the
syslogd daemon which more often than not takes care of all log manipulation
on most systems.</para></listitem></varlistentry>
<varlistentry><term>/var/mail</term><listitem><para>Contains
user mailbox files. The mail files take the form
/var/mail/&#39;username&#39; (Note that /var/mail may be a symbolic link to
another directory). User mailbox files in this location are stored in the
standard UNIX mailbox format. The reason for the location of this directory
was to bring the FHS inline with nearly every UNIX implementation (it was
previously located in /var/spool/mail). This change is important for
inter-operability since a single /var/mail is often shared between multiple
hosts and multiple UNIX implementations (despite NFS locking issues).</para></listitem></varlistentry>
<varlistentry><term>/var/opt</term><listitem><para>Variable
data of the program packages in /opt must be installed in
/var/opt/&#39;package-name&#39;, where &#39;package-name&#39; is the name of
the subtree in /opt where the static data from an add-on software package is
stored, except where superceded by another file in /etc. No structure is
imposed on the internal arrangement of /var/opt/&#39;package-name&#39;.</para></listitem></varlistentry>
<varlistentry><term>/var/run</term><listitem><para>Contains
the process identification files (PIDs) of system services and other
information about the system that is valid until the system is next booted.
For example, /var/run/utmp contains information about users currently logged
in.</para></listitem></varlistentry>
<varlistentry><term>/var/spool</term><listitem><para>Holds
spool files, for instance for mail, news, and printing (lpd) and other
queued work. Spool files store data to be processed after the job currently
occupying a device is finished or the appropriate cron job is started. Each
different spool has its own subdirectory below /var/spool, e.g., the cron
tables are stored in /var/spool/cron/crontabs.</para></listitem></varlistentry>
<varlistentry><term>/var/tmp</term><listitem><para>Temporary
files that are large or that need to exist for a longer time than what is
allowed for /tmp. (Although the system administrator might not allow very
old files in /var/tmp either.)</para></listitem></varlistentry>
<varlistentry><term>/var/named</term><listitem><para>Database
for BIND. The Berkeley Internet Name Domain (BIND) implements an Internet
domain name server. BIND is the most widely used name server software on the
Internet, and is supported by the Internet Software Consortium, www.isc.org.</para></listitem></varlistentry>
<varlistentry><term>/var/yp</term><listitem><para>Database
for NIS (Network Information Services). NIS is mostly used to let several
machines in a network share the same account information (eg. /etc/passwd).
NIS was formerly called Yellow Pages (YP).</para></listitem></varlistentry></variablelist></para>
<para>The following directories, or symbolic links to directories, are
required in /var for FSSTND compliance:</para>
<para><screen>
/var/cache Application cache data
/var/lib Variable state information
/var/local Variable data for /usr/local
/var/lock Lock files
/var/log Log files and directories
/var/opt Variable data for /opt
/var/run Data relevant to running processes
/var/spool Application spool data
/var/tmp Temporary files preserved between system reboots
</screen></para>
<para>Several directories are &#39;reserved&#39; in the sense that they must
not be used arbitrarily by some new application, since they would conflict
with historical and/or local practice. They are:</para>
<para><screen>
/var/backups
/var/cron
/var/msgs
/var/preserve
</screen></para>
<para>The following directories, or symbolic links to directories, must be in /var,
if the corresponding subsystem is installed:</para>
<para><screen>
account Process accounting logs (optional)
crash System crash dumps (optional)
games Variable game data (optional)
mail User mailbox files (optional)
yp Network Information Service (NIS) database files (optional)
</screen></para>
</sect1>