Managing Virtual File Systems
Virtual file systems (or pseudo file systems) are so named because they reside in memory instead of consuming physical hard disk space. The name virtual is a bit misleading, considering that two of the more important virtual file systems, the Cache File System (CacheFS) and the Temporary File System (TMPFS), both use disk space. A better way to think about virtual file systems is that they aren't used for permanent storage, as are disk-based file systems. Instead, virtual file systems exist to improve system performance or provide a specific function, such as maintaining a list of mounted file systems or managing virtual memory.
Table 11.1 lists 10 Solaris virtual file systems and their functions.
| File System Name | Type | Description |
|---|---|---|
| Cache | CacheFS | Improves performance of slow file systems and devices, such as remote file systems or CD-ROM drives. |
| Temporary | TMPFS | Manages temporary files and the /tmp directory (by default). Speeds up system performance. |
| Loopback | LOFS | Creates a new virtual file system, enabling you to access files by an alternate pathname. |
| Process | PROCFS | Contains a list of active processes and process numbers. Manages the /proc directory. |
| First-In First-Out | FIFOFS | Named pipe that gives processes common access to data. |
| File Descriptors | FDFS | Maintains a list of explicit names for opened files by using file descriptors. |
| Mount | MNTFS | Maintains a list of mounted file systems, as displayed by the /etc/mnttab file. |
| Name | NAMEFS | Used by STREAMS for dynamic mounts of file descriptors on top of files. |
| Special | SPECFS | Enables access to character special devices and block devices. |
| Swap | SWAPFS | Used by the kernel for swapping. Manages virtual memory. |
Most virtual file systems do not require any administration. The file systems you will likely never administer are FIFOFS, FDFS, MNTFS, NAMEFS, and SPECFS. On the other hand, because of their importance and because they are the virtual file systems that you'll most likely need to configure at some point, this chapter covers PROCFS, LOFS, CacheFS, TMPFS, and SWAPFS.
Core files and crash dumps, which often use virtual file systems, are also covered in this section.
Process File System
The Process File System (PROCFS) contains detailed information about running processes on your computer. When you execute the ps command (or other process management commands), the /proc file system is accessed for information.
/proc is mounted automatically at boot. Generally speaking, you won't need to perform any administrative tasks on /proc because it's self-administering. In fact, it's recommended that you not delete any files in the /proc directory, or processes could crash. Entries are automatically created in /proc when you start a process, and the same entries are automatically removed when the process is finished.
Each entry in the /proc directory is a decimal number that corresponds to a process ID. The directories in /proc contain additional files that contain more detailed information about those processes. Ownership of each file in /proc and its subdirectories is determined by the User ID of the process.
Here is a sample directory listing of /proc:
# ls /proc 0 164 196 219 254 294 309 318 335 386 402 411 422 54 1 177 2 232 256 295 310 319 342 387 403 412 434 76 124 179 201 243 257 298 316 320 352 389 409 414 438 78 141 188 214 253 285 3 317 333 356 401 410 421 47
Further analysis of the /proc directory listing will show that every one of these entries is in fact a directory. Here's a sample of the files you might find in a process's directory:
# ls -l /proc/319 total 13812 -rw------- 1 root root 7004160 Oct 26 15:33 as -r-------- 1 root root 152 Oct 26 15:33 auxv -r-------- 1 root root 72 Oct 26 15:33 cred --w------- 1 root root 0 Oct 26 15:33 ctl lr-x------ 1 root root 0 Oct 26 15:33 cwd -> dr-x------ 2 root root 528 Oct 26 15:33 fd -r--r--r-- 1 root root 120 Oct 26 15:33 lpsinfo -r-------- 1 root root 912 Oct 26 15:33 lstatus -r--r--r-- 1 root root 536 Oct 26 15:33 lusage dr-xr-xr-x 3 root root 48 Oct 26 15:33 lwp -r-------- 1 root root 11424 Oct 26 15:33 map dr-x------ 2 root root 2080 Oct 26 15:33 object -r-------- 1 root root 12976 Oct 26 15:33 pagedata -r--r--r-- 1 root root 336 Oct 26 15:33 psinfo -r-------- 1 root root 11808 Oct 26 15:33 rmap lr-x------ 1 root root 0 Oct 26 15:33 root -> -r-------- 1 root root 1472 Oct 26 15:33 sigact -r-------- 1 root root 1232 Oct 26 15:33 status -r--r--r-- 1 root root 256 Oct 26 15:33 usage -r-------- 1 root root 0 Oct 26 15:33 watch -r-------- 1 root root 18088 Oct 26 15:33 xmap #
From the directory listing, it's apparent that the root owns process 319. Although the information presented by this directory listing isn't likely to help you a great deal as displayed, Solaris uses it when you run utilities such as pgrep or ptree to look for process information.
| Note | For more information on process management and commands, see Chapter 8, "Managing Printers and Controlling Processes." |
Loopback File System
The Loopback File System (LOFS) enables you to create a new virtual file system within your existing file system. Files and directories that are in this new virtual file system can be accessed by their original path or by their new virtual path.
For example, imagine that you have created a UFS file system named /docs. Located in this /docs directory are critical project files that users in your engineering and production departments need to access. The users in your production department are accustomed to accessing project files in the /prod/projects directory, which is currently empty. With LOFS, you can create a copy of /docs located in /prod/projects.
To enable LOFS, you need superuser or equivalent rights. Here's how to set up LOFS:
-
Create the directory that you want to mount as a loopback, if necessary.
# mkdir loopback_directory
-
Create the new mount point, if necessary.
# mkdir /mount_point
-
Mount the LOFS file system.
# mount -F lofs loopback_directory /mount_point
-
Configure the appropriate permissions on the new mount point.
For the preceding example of the /docs directory, you wouldn't need to create the loopback directory or mount point directory. All you would need to do is mount the loopback:
# mount -F lofs /docs /prod/projects
To verify that the file system is mounted properly, use:
# mount -v
If you want the Loopback File System to mount at boot, you can add an entry for the file system in the /etc/vfstab file. It's best to add the entry for the Loopback File System to the end of the /etc/vfstab file, though. That way, you're assured that the file system you're shadowing is mounted and ready before you mount the loopback.
One question a lot of people wonder about is, when creating a Loopback File System, can you create an endless loop? Take an example of creating a loopback of the root on a mount point named /tmp/newroot. By doing so, the entire root directory is shadowed in the /tmp/newroot directory. So, if you navigate to /tmp/newroot/tmp/newroot, will you see another copy of the root? The answer is no. The /tmp/newroot/tmp/newroot directory will appear as it did before the loopback was performed. If /tmp/newroot was blank, then /tmp/newroot/ tmp/newroot will be blank as well.
Creating loopback file systems can potentially cause confusion for users and programs. Use Loopback File Systems sparingly to avoid confusion.
Using LOFS also can cause a few potential problems. To understand the problems, though, you need to know exactly how LOFS works. LOFS works by shadowing directories of the underlying file system. No other file types are shadowed. This can cause two problems:
-
Files located on a mounted read-only Loopback File System can be modified.
-
Loopback File Systems can be unmounted even if there is an open regular file on the file system.
Both of these things can happen because, again, the Loopback File System shadows only directories, not regular files. Therefore, file permissions (such as Read-only) are not shadowed, nor can the Loopback File System detect that a file is open. To alleviate the security problem, you need to set proper security on the Loopback File System. There is no work-around for detecting open files; LOFS simply cannot do it.
Cache File System
A cache can be defined as a temporary storage area. The Cache File System (CacheFS) is designed to be a temporary holding area, used to increase access times when users attempt to access data. Caching has little effect when accessing files on a local UFS file system. However, caching can provide a dramatic increase in speed for a user accessing networked file systems or slow devices such as CD-ROM drives.
When using CacheFS, you create a local, cached copy (called a front file system) of data located on a remote file system or CD-ROM (known as the back file system). Attempts to access data on the cached file system will result in the computer trying to access the data from the local cache first, and then the back file system if the data is not available in the cache. Table 11.2 lists some terms you need to be familiar with to understand CacheFS.
| Term | Description |
|---|---|
| Back file system | The file system located on the remote host or CD-ROM. This is the file system being cached and must be NFS or HSFS. Files located here are called back files. |
| Front file system | The local file system containing the cached data. Files located here are called front files. Front file systems must be UFS. |
| Cache directory | The local directory where the cached data is stored. |
| Cache hit | An attempt to access data that is currently in cache. |
| Cache miss | An attempt to access data that is not in the cache. |
| Cold cache | A front file system that does not contain any files. A front file system must be populated with files from the back file system before it is useful. |
| Warm cache | A front file system that contains the desired data, meaning that no action is needed from the back file system. |
Ideally, a cached file system not only speeds up user access to files but also reduces the amount of network traffic. If users are getting a lot of cache hits, then there's no need for the computer containing the front file system to request data from the computer with the back file system. CacheFS can greatly improve network performance over slow network links.
When a user initially attempts to access a file in a file system set up for caching, the access might appear slow because the file might not be populated into the cache yet. However, the user accessing the file causes the file to be placed in the front file system. Subsequent attempts to access the file will be much quicker.
Creating and Mounting CacheFS
To enable disk caching, you must first create a cache directory within a local file system. After the cache directory is created, you specify a file system to mount within the cache directory. This will be the back file system. No files are copied to the front file system when you mount the back file system. By default, files are copied to the cache only when a user attempts to access them.
| Note | CacheFS cannot be used to cache the root (/) or /usr file systems. |
The cfsadmin command is used to create and manage a file system cache. To create a file system cache, use the following command:
# cfsadmin -c /cache_directory
The cache_directory variable is the name of the directory in which you will mount the cache. The only restriction as to where this directory can be created is that it must be on a local UFS file system. You have the option of creating a file system specifically for the cache or creating the cache as a subdirectory of an existing file system. For example, if you want to create a cache directory named cache01, you would use the following command:
# cfsadmin -c /cache01
| Warning | After creating the cache directory, do not perform any operations on the cache directory itself. Doing so will cause problems with the CacheFS software. |
After the cache directory has been created, you need to mount a file system in the cache. You have three options for mounting a file system into cache:
-
Manually mount the file system by using the mount command.
-
Create an entry in the local computer's /etc/vfstab file for the mount point.
-
Use the automounter (AutoFS).
If you choose to use the mount command, you will have to manually mount the file system every time you want it to be cached. Editing the /etc/vfstab file or using AutoFS is a one-time configuration, and both provide automatic mounting.
| Note | The automounter (AutoFS) will be covered in detail in the "Managing Network File System (NFS)" section of this chapter. |
If you want to use the mount command to mount the file system manually, here is the syntax:
# mount -F cachefs -o backfstype=fstype,cachedir=/cache_directory,options 
/back_file_system /mount_point Table 11.3 explains the variables used in mounting a cached file system.
| Variable | Description |
|---|---|
| fstype | The file system type of the back file system. Can be either NFS or HSFS. |
| /cache_directory | The name of the local UFS directory where the cache resides. |
| options | Mount options. Examples are noconst to disable cache consistency checking, suid to allow SetUID execution, and non-shared to specify the non-shared write mode. |
| /back_file_system | The mount point of the file system to cache. If the file system is remote, you must use the following format: host:/mount_point. |
| /mount_point | The directory where the file system is mounted. |
Here is an example: you want to mount into cache a file system named /docs on the server1 computer. The cache directory that you have created is called cache01. Here is the syntax:
# mount -F cachefs -o backfstype=nfs,cachedir=/cache01 server1:/docs /docs
| Tip | To mount a remote file system, the remote file system must be shared. |
After you have created and mounted your cache file system, you might want to verify that the cache is mounted properly:
# cachefsstat /mount_point
This command should return statistics about your cache file system, such as the cache hit rate. If the file system was not mounted properly in cache, you will receive an error message.
Each cache you create has a set of parameters that determine how it behaves. These parameters are listed in Table 11.4.
| Parameter | Default | Description |
|---|---|---|
| maxblocks | 90% | Defines the maximum number of blocks that the front file system is allowed to claim. |
| minblocks | 0% | Determines the minimum number of blocks that a front file system is allowed to claim. |
| threshblocks | 85% | Specifies the number of blocks that must be available in the front file system before CacheFS can claim more blocks than specified by minblocks. |
| maxfiles | 90% | Defines the maximum number of inodes that CacheFS is allowed to claim within the front file system. |
| minfiles | 0% | Determines the minimum number of inodes that CacheFS is allowed to claim within the front file system. |
| threshfiles | 85% | Specifies the number of inodes that must be available in the front file system before CacheFS can claim more inodes than specified by minfiles. |
These values are set to achieve optimal cache behavior and generally do not need to be modified. However, you can modify the maxblocks and maxfiles values if your front file system has room that's not being used by the cache, and you want to use the space for some other file system. These parameters are modified by using the cfsadmin -o command.
Managing CacheFS
For the most part, CacheFS is very good at managing itself. Consequently, it doesn't often require a lot of interactive management or maintenance.
If you modify the file system being cached, you will need to delete, re-create, and remount the cache. Modifications include moving the mount point of the cached file system or changing the size of the cached file system.
Displaying Cache Parameters
The cfsadmin -l command displays your cache parameters. Here is an example, using the cache of cache01 created earlier:
# cfsadmin -l /cache01 cfsadmin: list cache FS information maxblocks 90% minblocks 0% threshblocks 85% maxfiles 90% minfiles 0% threshfiles 85% maxfilesize 5MB server1:_docs
The parameters listed can be modified by using the cfsadmin -o command.
Checking Cache Consistency
CacheFS periodically checks its own consistency by comparing the file modification times of files in the cache with file modification times in the back file system. If CacheFS determines that data in the cache is not current, the cached data is purged and new data is retrieved from the back file system.
By default, consistency checks are performed when a user tries to open or perform another operation on a file in cache. If you want to be able to perform consistency checks on demand, you must first mount the cache file system with the -o demandconst option. You can then use the cfsadmin -s /mount_point command to request a consistency check.
Checking Cache File System Integrity
In Chapter 7, you learned that the fsck command is used to check file system integrity. Because CacheFS is a file system, you use fsck to check its integrity as well. To check the integrity of the cache01 cache created earlier, you would use the following:
# fsck -F cachefs /cache01
| Note | Consistency and integrity are terms that can cause confusion. Consistency refers to making sure that the data within the file system is current. Integrity refers to the well-being of the file system as a whole and not to whether the data within the file system is current. |
Deleting a Cache
If the cache file system is no longer needed, you can delete it. First, you must unmount the cache file system by using the umount command. Then, run the cfsadmin -d command:
# cfsadmin -d cache_ID /cache_directory
The cache directory is the directory in which you mounted the cache file system. The cache ID is the last line of the cfsadmin -l output as shown previously.
After you have deleted a cache, run the cfsadmin -l command again. If it was deleted properly, the cache ID should not be present.
Packing CacheFS
CacheFS runs automatically after being set up. When users request files from a cached file system, the front file system is checked first. If the file is not found or is not consistent with the cached file in the back file system, the file is retrieved from the back file system. Because the whole reason for using CacheFS is to increase speed, especially over slow network connections, waiting for first-time file retrieval can be frustrating.
By using the CacheFS packing feature, you can actively manage which files are included in the cache, as opposed to passively waiting for the first access. Files are specified for packing into cache with the cachefspack command.
To pack a file in cache, use cachefspack -p filename, as in the following example:
# cachefspack -p file1 file2 file3 /dir1
The files file1, file2, and file3 and the directory /dir1 will be packed into cache.
The cachefspack command can also be used to create a packing list, a list of specific files and directories to automatically be packed. This saves you the hassle of manually packing files every time you boot. Packing lists can also contain other packing lists. If you specify a directory to be packed, all of its contents, including subdirectories, are packed as well. For more information on packing, use the man cachefspack command.
Monitoring CacheFS Performance
As mentioned before, CacheFS runs automatically after being set up and is configured for optimal performance. However, there are commands you can use to collect statistics about CacheFS, which will enable you to determine an appropriate cache size as well as observe cache performance. The three commands are listed in Table 11.5.
| Command | Description |
|---|---|
| cachefslog | Displays where cache statistics are currently being logged, enables you to stop logging, and specifies the location of the log file. |
| cachefsstat | Provides statistical information about a specific cache or all cached file systems. |
| cachefswssize | Reads the log file and gives you a recommended cache size. You must be the superuser to execute this command. |
To get the most out of these cache statistics commands, you must first enable your cache, determine how long you want to gather statistical information (typically a workday, week, or month), and select a location for your log file. Keep in mind that the longer you log data, the larger the log file will be. Make sure that the log file is located on a file system where it has plenty of room to grow.
After your cache is enabled and you have collected data, you can review the data. By using cachefsstat to display statistics, you can determine how effective your caching is and perhaps decide whether you want to pack certain files or directories into cache. If you want to see what the recommended cache file size is for your computer, use the cachefswssize command. For more information on cache statistics, see the man page for the appropriate command.
Temporary File System
The Temporary File System (TMPFS) is the default file system for the /tmp directory. TMPFS uses local memory instead of disk space to perform file system reads and writes and, consequently, is much faster than disk-based file systems. Files can be moved in and out of the /tmp directory (or other TMPFS file systems) just as they can with any other directory in the directory structure. However, files located in a TMPFS file system do not survive across reboots. If you unmount the file system or reboot the computer, all files in a TMPFS file system are lost.
Creating a temporary file system is done by creating a directory and then mounting the TMPFS file system in it. You must have superuser privileges to create a TMPFS file system. Here's how:
-
Create a directory for the temporary file system.
# mkdir /mount_point
-
Mount the TMPFS file system by using the mount command.
# mount -F tmpfs -o size=number swap /mount_point
-
Verify the creation of the file system.
# mount -v
The /mount_point variable can be any directory on a local file system. When using the mount command to mount the file system, the -o size=number argument is optional. It is useful for limiting the size of the temporary file system, however. And because TMPFS uses swap space (physical memory, and virtual memory, if needed), you might want to limit TMPFS size if your computer is low on memory.
If you want to use a temporary file system that is created automatically during each boot, you can add an entry into the /etc/vfstab file.
Swap File System
Each process or application that runs on your Solaris computer uses memory. There are two types of memory available: physical memory and virtual memory. Physical memory is the amount of random access memory (RAM) in your computer. However, not all physical memory is available for use by processes or applications. A certain portion of physical memory is reserved for the operating system. The portion that is left over is called available memory.
After your computer's available memory is exhausted, virtual memory is used. Virtual memory is hard disk space reserved to emulate physical memory. Even though hard disk access is considerably slower than physical memory access, disk space is less expensive than RAM. Therefore, using virtual memory is a cost-effective alternative to adding gigabytes of RAM to your computer. Virtual memory is also called swap space. Swap space can take the form of its own partition (a swap partition) or a file in an existing slice (a swap file).
Applications and processes using memory are allocated memory in units called pages. When an application or process needs more memory than is physically available, certain pages are written to virtual memory. This process is known as paging or swapping.
The Swap File System (SWAPFS) is responsible for managing virtual and physical memory, as well as the paging process. Understand that applications cannot read information from virtual memory; the information must be in physical memory to be "used." Therefore, SWAPFS plays a critical role in transferring data between physical and virtual memory as needed.
| Tip | If your computer is performing slowly, and you suspect that it's because of excessive paging, the only proven way to increase system speed is to add RAM. |
By default, the system's swap space is also configured to be the computer's dump device. This will be covered further in the "Core Files and Crash Dumps" section later in this chapter.
| Note | The TMPFS file system uses memory instead of hard disk space. Consequently, TMPFS and SWAPFS work closely together. If you are using a lot of temporary space, or TMPFS is using a large amount of space, it will adversely affect your swap performance. One way to avoid this problem is to limit the size of your TMPFS files, as explained in the earlier "Temporary File System" section. |
Allocating Swap Space
Swap space is configured initially during Solaris installation. In many cases, you will not need to reallocate or add additional swap space. However, if you want to create additional swap space, you can do so with the mkfile and swap commands.
You will want to create additional swap space if your system requires it. Running out of swap space will generate "out of memory" errors and temporarily cause Solaris to appear locked up. Even if you become very low on virtual memory, Solaris performance will be seriously degraded. You might need additional swap space for one or more of the following reasons:
-
If applications that you are using require significant amounts of virtual memory. This can usually be determined by the application's documentation. Examples of "memory-hogging" applications are computer aided design programs and some database management tools.
-
If applications will be using the /tmp directory a lot. These additional used temporary resources will cut into the amount of available swap space.
-
If you want to save crash dumps. In the case of a fatal system crash, the contents of physical memory are "dumped" to swap space for future analysis. If you want to use this feature, your swap space needs to be at least as large as the amount of physical memory in your computer.
Monitoring Swap Usage
Another way to determine that you need additional swap space is to regularly monitor swap usage. Obviously, if you consistently get errors about applications being out of memory, you don't need to monitor your swap space to know you need more of it. Most of the time, though, you won't get errors but might notice that the computer seems to be running slower than it should be.
Two common commands to monitor swap usage are swap -l and swap -s. Here is sample output from each command:
# swap -l swapfile dev swaplo blocks free /dev/dsk/c0t0d0s1 136,1 16 1049312 1049312 # swap -s total: 32496k bytes allocated + 5424k reserved = 37920k used, 573864k available
Both of these commands show that plenty of swap space is available on this computer. No additional swap space configuration is necessary.
| Note | The swap -l command displays swap space in 512-byte blocks, and swap -s displays swap space in 1024-byte blocks. The swap -l command also does not include physical memory in its calculation of swap space. |
When you issue the swap -l and swap -s commands, you are taking a snapshot of a dynamic memory allocation process. Because memory allocation can change dramatically, you should periodically monitor swap usage if you're concerned that it could be a problem.
Adding More Swap Space
As mentioned previously, swap space is created during the initial installation of Solaris. The swap partition is created, and an entry for the slice is added to the /etc/vfstab file. If you want to add additional swap space, you have two choices. The first choice is to create an additional swap partition. The second choice is to create a swap file in an existing partition.
There is a lot of healthy debate in the computer industry about which is better: swap files or swap partitions. Sun recommends that you use swap files only as a temporary or short-term solution, and if you need a long-term solution, to use a swap slice. Here are a few notes about swap files and swap partitions:
-
Swap files are considered a file within the file system. Therefore, when backing up the file system, you will back up a large blank swap file unless you specifically exclude it.
-
You will not be able to unmount a file system containing a swap file that's in use. And you can assume that after the swap file is created, it's considered "being used" by Solaris.
-
Swap files work through their existing file system for disk reads and writes, whereas swap partitions use the SWAPFS file system directly, making them slightly faster because they can bypass the secondary file system.
-
Systems running 32-bit versions of Solaris cannot have swap areas that exceed 2GB. The 64-bit versions of Solaris can support swap areas of any size.
-
Spreading the swap area out among multiple physical disks provides a large performance boost. This is because you have multiple sets of disk read/write heads working at once to read and/or write swap information.
In an emergency, you can also create swap space on an NFS file system. However, because this would greatly increase network traffic, it's not a recommended solution.
Note that in order to create a swap file, you do not need superuser privileges. However, to prevent accidental overwriting of your swap file, it's recommended that the root create it. Here is how to create a swap file:
-
Create a directory specifically for the swap file, if needed. It's a good idea to do this, even though it's not necessary. That way, your swap file is easily identifiable.
-
Create the swap file with the mkfile command. The nnn variable represents the size of the file that you want to create, in bytes (b), kilobytes (k), or megabytes (m).
# mkfile nnn[b|k|m] filename
-
Activate the swap file with the swap command. You must supply the absolute pathname to the swap file.
# swap -a /path/filename
-
If you want the swap file to be permanently available, even after reboots, add an entry for the new swap file in the /etc/vfstab file.
To verify that the new swap space is available, use the swap -l command.
Creating a new swap partition is nearly identical to creating a swap file. However, you must first create the new partition and format it before creating the swap file on it. For information on creating and formatting partitions, see Chapter 6, "Device and Disk Management."
Removing Swap Files
If you no longer need the swap space that you created, you can remove the swap file and free up disk space for other uses. Here's how:
-
Remove the swap file. This step does not actually delete the swap file, but it makes the file unavailable for swapping purposes.
# swap -d /path/filename
-
If you added an entry for the swap file in the /etc/vfstab file, remove the entry.
-
Recover the disk space if needed.
# rm /path/filename
If the swap space is a separate slice, not a file within a partition, you can delete the slice and re-create it as necessary.
Core Files and Crash Dumps
Two of the automated system processes that makes extensive use of virtual file systems are the generation of core files and crash dumps. Core files and crash dumps are generated when an unexpected fatal error happens to an application or the operating system. Both can be used to troubleshoot problems in Solaris. Solaris can be configured to generate core files and crash dumps in different ways.
Managing Core Files
A core file is generated when an application or process terminates abnormally. Core files are used to troubleshoot problematic applications, although it helps to have programming experience to read them. Core files are managed with the coreadm command.
Solaris 9 provides two configurable core paths, which operate independently of each other. The first is a per-process core file path, which is enabled by default. If a process terminates abnormally, a core file is generated in the current working directory. The owner of the process has Read/Write permissions to the core file. No one else can read the file.
The second path is called a global core file path, and it's disabled by default. If it's enabled, an abnormally terminated process will generate an additional core file, with the same contents as the per-process core file, in a global core file directory.
| Note | By default, SetUID processes do not generate core files. |
If you have enabled global core files, you can establish a core file naming convention to distinguish one core file from another. Variables for distinguishing core file names are explained in Table 11.6.
| Variable | Description |
|---|---|
| %p | Process ID |
| %u | Effective User ID of the process |
| %g | Effective Group ID of the process |
| %f | Executable filename of the process generating the core file |
| %n | System node name |
| %m | Machine name |
To set global core file naming standards, use the coreadm command, as in:
# coreadm -i /corepath/core.%p.%u
Based on the example, a core file generated by the Process ID 5150, with an effective User ID of 1100, will have the name core.5150.1100 and be located in the /corepath directory. Global core values are stored in the /etc/coreadm.conf file.
The per-process core file naming pattern is configured with coreadm -p. After establishing a global or per-process naming pattern, you must enable the pattern with the coreadm -e command. The core file naming patterns can also be set in the user's .profile or .login files.
To display your current core file configuration, use the coreadm command with no arguments:
#coreadm global core file pattern: init core file pattern: core global core dumps: disabled per-process core dumps: enabled global setid core dumps: disabled per-process setid core dumps: disabled global core dump logging: disabled
Core files can be examined with the proc tools available for the /proc file system. Instead of supplying a process ID, supply the name of the core file you want to examine. Tools available include pcred, pflags, pldd, pstack, and pmap.
Managing System Crashes
While core dumps are the result of application crashes, crash dump files are the result of an operating system crash. If the system crashes, you will get a message displayed on the console, followed by a dump of the contents of physical memory to the dump device and a system reboot. When Solaris reboots, the savecore command automatically retrieves the dumped memory from the dump device and writes a crash dump to your savecore directory. The crash dump file can be helpful in troubleshooting the reason for the system crash.
The savecore command generates two files that compose the crash dump: unix.X and vmcore.X. The X identifies the dump sequence number. Also unlike core dumps, crash dump files are saved to a predetermined directory: /var/crash/hostname. Saving of crash dump files is enabled by default. Crash dump files and configuration are managed with the dumpadm command.
Crash dump configuration information is saved in the /etc/dumpadm.conf file. Don't edit this file directly; instead, use the dumpadm command to modify crash dump behavior.
Here are some features of dumpadm and crash dumps in Solaris:
-
The dumpadm command enables you to configure dump content, the dump device, and the dump directory.
-
Dumped data is stored in compressed format on the dump device, saving disk space and increasing dump speed.
-
If you have established a dedicated dump device, instead of the default swap area, the crash dump is performed in the background. The system will not wait for savecore to finish before rebooting, and the system might be available for use before savecore finishes. This is particularly true on systems with a large amount of physical memory.
-
The savecore -L command enables you to generate a crash dump of a live system. On the surface, this might not seem useful. But if the system is running in an error state but has not crashed, generating this dump can provide useful troubleshooting information. You can use savecore -L only if you have configured a dedicated dump device.
You must have superuser privileges to manage crash dump information. Running the dumpadm command displays your current crash dump configuration:
# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t0d0s1 (swap) Savecore directory: /var/crash/Q-Sol Savecore enabled: yes
To disable the automatic saving of crash dump information, use dumpadm -n. Re-enabling crash dumps is done with dumpadm -y.
# dumpadm -n Dump content: kernel pages Dump device: /dev/dsk/c0t0d0s1 (swap) Savecore directory: /var/crash/Q-Sol Savecore enabled: no # dumpadm -y Dump content: kernel pages Dump device: /dev/dsk/c0t0d0s1 (swap) Savecore directory: /var/crash/Q-Sol Savecore enabled: yes #
Because of the troubleshooting benefits of saving crash dump files, it's recommended that you leave crash dumps enabled and designate a specific device, such as a lesser-used hard disk, as the dedicated crash dump device.
|
|
EAN: 2147483647
Pages: 194