|Linux Filesystem Hierarchy:
||Chapter 1. Linux
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. '/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 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'.
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.
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
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.
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.
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
Package specific cache data.
WWW proxy or cache data.
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.
Data bank store.
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.
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.
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.
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.
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,
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.
Record of all logins and logouts by normal users and system
Log of all attempted bad logins to the system. Accessed via the
Debugging output from various packages.
Kernel ring buffer. The content of this file is referred to by
the dmesg command.
GDM log files. Normally a subset of the last X log file. See
/var/log/xdm.log for mode details.
KDM log file. Normally a subset of the last X log file. See
/var/log/xdm.log for more details.
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
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.
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.
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.
- /var/log/XFree86.0.log, /var/log/XFree86.?.log
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
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.
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).
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
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.
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
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
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.
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
The following directories, or symbolic links to directories, are
required in /var for FSSTND compliance:
/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
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:
The following directories, or symbolic links to directories,
must be in /var, if the corresponding subsystem is installed:
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)