mirror of https://github.com/tLDP/LDP
254 lines
14 KiB
XML
254 lines
14 KiB
XML
<sect1 id="var">
|
|
<title>/var</title>
|
|
|
|
<para>Contains variable data like system logging files, mail and printer
|
|
spool directories. It is specific for each system, i.e., not shared over the
|
|
network with other computers. 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. '/var' 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 of these 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.
|
|
'Mountable' directories are: '/home', '/mnt',
|
|
'/tmp', '/usr' and '/var'. Essential for booting
|
|
are: '/bin', '/boot', '/dev', '/etc',
|
|
'/lib', '/proc' and '/sbin'.</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.</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'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/'package-name'</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't
|
|
ever need to modify files in /var/lib to configure a package'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't need a subdirectory; the other
|
|
subdirectories should only be present if the application in question is
|
|
included in the distribution. /var/lib/'name' 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 '/var' 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'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 'logrotate'. 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
|
|
'system' 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/'username' (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/'package-name', where 'package-name' 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/'package-name'.</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 'reserved' 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>
|
|
|
|
</sect1>
|