- Red Hat Enterprise Linux Troubleshooting Guide
- Benjamin Cane
- 1987字
- 2021-07-09 21:50:11
Finding useful information
Before starting to explore troubleshooting commands, I first want to cover locations of useful information. Useful information is a bit of a vague term, pretty much every file, directory, or command can provide useful information. What I really plan to cover are places where it is possible to find information for almost any issue.
Log files
Log files are often the first place to start looking for troubleshooting information. Whenever a service or server is experiencing an issue, checking the log files for errors can often answer many questions quickly.
By default, RHEL and most Linux distributions keep their log files in /var/log/
, which is actually part of the Filesystem Hierarchy Standard (FHS) maintained by the Linux Foundation. However, while /var/log/
might be the default location not all log files are located there (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard).
While /var/log/httpd/
is the default location for Apache logs, this location can be changed with Apache's configuration files. This is especially common when Apache was installed outside of the standard RHEL package.
Like Apache, most services allow for custom log locations. It is not uncommon to find custom directories or file systems outside of /var/log
created specifically for log files.
The following table is a short list of common log files and a description of what you can find within them.

For many issues, one of the first log files to review is the /var/log/messages
log. On RHEL systems, this log file receives all system logs of INFO
priority or higher. In general, this means that any significant event sent to syslog
would be captured in this log file.
The following is a sample of some of the log messages that can be found in /var/log/messages
:
Dec 24 18:03:51 localhost systemd: Starting Network Manager Script Dispatcher Service... Dec 24 18:03:51 localhost dbus-daemon: dbus[620]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Dec 24 18:03:51 localhost dbus[620]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Dec 24 18:03:51 localhost systemd: Started Network Manager Script Dispatcher Service. Dec 24 18:06:06 localhost kernel: e1000: enp0s3 NIC Link is Down Dec 24 18:06:06 localhost kernel: e1000: enp0s8 NIC Link is Down Dec 24 18:06:06 localhost NetworkManager[750]: <info> (enp0s3): link disconnected (deferring action for 4 seconds) Dec 24 18:06:06 localhost NetworkManager[750]: <info> (enp0s8): link disconnected (deferring action for 4 seconds) Dec 24 18:06:10 localhost NetworkManager[750]: <info> (enp0s3): link disconnected (calling deferred action) Dec 24 18:06:10 localhost NetworkManager[750]: <info> (enp0s8): link disconnected (calling deferred action) Dec 24 18:06:12 localhost kernel: e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Dec 24 18:06:12 localhost kernel: e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Dec 24 18:06:12 localhost NetworkManager[750]: <info> (enp0s3): link connected Dec 24 18:06:12 localhost NetworkManager[750]: <info> (enp0s8): link connected Dec 24 18:06:39 localhost kernel: atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly. Dec 24 18:07:10 localhost systemd: Starting Session 53 of user root. Dec 24 18:07:10 localhost systemd: Started Session 53 of user root. Dec 24 18:07:10 localhost systemd-logind: New session 53 of user root.
As we can see, there are more than a few log messages within this sample that could be useful while troubleshooting issues.
Many times log files are not in /var/log/
, which can be either because someone modified the log location to some place apart from the default, or simply because the service in question defaults to another location.
In general, there are three ways to find log files not in /var/log/
.
If you know a service is using syslog for its logging, the best place to check to find which log file its messages are being written to is the rsyslog configuration files. The rsyslog service has two locations for configuration. The first is the /etc/rsyslog.d
directory.
The /etc/rsyslog.d
directory is an include directory for custom rsyslog configurations. The second is the /etc/rsyslog.conf
configuration file. This is the main configuration file for rsyslog and contains many of the default syslog configurations.
The following is a sample of the default contents of /etc/rsyslog.conf
:
#### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron
By reviewing the contents of this file, it is fairly easy to identify which log files contain the information required, if not, at least, the possible location of syslog managed log files.
Not every application utilizes syslog; for those that don't, one of the easiest ways to find the application's log file is to read the application's configuration files.
A quick and useful method for finding log file locations from configuration files is to use the grep
command to search the file for the word log
:
$ grep log /etc/samba/smb.conf # files are rotated when they reach the size specified with "max log size". # log files split per-machine: log file = /var/log/samba/log.%m # maximum size of 50KB per log file, then rotate: max log size = 50
The grep
command is a very useful command that can be used to search files or directories for specific strings or patterns. This command will be used throughout this book in various methods. The simplest command can be seen in the preceding snippet where the grep
command is used to search the /etc/samba/smb.conf
file for any instance of the pattern "log
".
After reviewing the output of the preceding grep
command, we can see that the configured log location for samba is /var/log/samba/log.%m
. It is important to note that %m
, in this example, is actually replaced with a "machine name" when creating the file. This is actually a variable within the samba configuration file. These variables are unique to each application but this method for making dynamic configuration values is a common practice.
The following are examples of using the grep
command to search for the word "log
" in the Apache and MySQL configuration files:
$ grep log /etc/httpd/conf/httpd.conf # ErrorLog: The location of the error log file. # logged here. If you *do* define an error logfile for a <VirtualHost> # container, that host's errors will be logged there and not here. ErrorLog "logs/error_log" $ grep log /etc/my.cnf # log_bin log-error=/var/log/mysqld.log
In both instances, this method was able to identify the configuration parameter for the service's log file. With the previous three examples, it is easy to see how effective searching through configuration files can be.
The find
command, which we will cover in depth later in this chapter, is another useful method for finding log files. The find
command is used to search a directory structure for specified files. A quick way of finding log files is to simply use the find
command to search for any files that end in ".log
":
# find /opt/appxyz/ -type f -name "*.log" /opt/appxyz/logs/daily/7-1-15/alert.log /opt/appxyz/logs/daily/7-2-15/alert.log /opt/appxyz/logs/daily/7-3-15/alert.log /opt/appxyz/logs/daily/7-4-15/alert.log /opt/appxyz/logs/daily/7-5-15/alert.log
The preceding is generally considered a last resort solution, and is mostly used when the previous methods do not produce results.
Configuration files
As discussed previously, configuration files for an application or service can be excellent sources of information. While configuration files won't provide you with specific errors such as log files, they can provide you with critical information (for example, enabled/disabled features, output directories, and log file locations).
In general, system, and service configuration files are located within the /etc/
directory on most Linux distributions. However, this does not mean that every configuration file is located within the /etc/
directory. In fact, it is not uncommon for applications to include a configuration directory within the application's home
directory.
So how do you know when to look in the /etc/
versus an application directory for configuration files? A general rule of thumb is, if the package is part of the RHEL distribution, it is safe to assume that the configuration is within the /etc/
directory. Anything else may or may not be present in the /etc/
directory. For these situations, you simply have to look for them.
In most scenarios, it is possible to find system configuration files within the /etc/
directory with a simple directory listing using the ls
command:
$ ls -la /etc/ | grep my -rw-r--r--. 1 root root 570 Nov 17 2014 my.cnf drwxr-xr-x. 2 root root 64 Jan 9 2015 my.cnf.d
The preceding code snippet uses ls
to perform a directory listing and redirects that output to grep
in order to search the output for the string "my
". We can see from the output that there is a my.cnf
configuration file and a my.cnf.d
configuration directory. The MySQL processes use these for its configuration. We were able to find these by assuming that anything related to MySQL would have the string "my
" in it.
If the configuration files were deployed as part of a RPM package, it is possible to use the rpm
command to identify configuration files. To do this, simply execute the rpm
command with the –q
(query) flag, and the –c
(configfiles) flag, followed by the name of the package:
$ rpm -q -c httpd /etc/httpd/conf.d/autoindex.conf /etc/httpd/conf.d/userdir.conf /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.modules.d/00-base.conf /etc/httpd/conf.modules.d/00-dav.conf /etc/httpd/conf.modules.d/00-lua.conf /etc/httpd/conf.modules.d/00-mpm.conf /etc/httpd/conf.modules.d/00-proxy.conf /etc/httpd/conf.modules.d/00-systemd.conf /etc/httpd/conf.modules.d/01-cgi.conf /etc/httpd/conf/httpd.conf /etc/httpd/conf/magic /etc/logrotate.d/httpd /etc/sysconfig/htcacheclean /etc/sysconfig/httpd
The rpm
command is used to manage RPM packages and is a very useful command when troubleshooting. We will cover this command further in the next section as we explore commands for troubleshooting.
Much like finding log files, to find configuration files on a system, it is possible to utilize the find
command. When searching for log files, the find
command was used to search for all files where the name ends in ".log
". In the following example, the find
command is being used to search for all files where the name begins with "http
". This find
command should return at least a few results, which will provide configuration files related to the HTTPD (Apache) service:
# find /etc -type f -name "http*" /etc/httpd/conf/httpd.conf /etc/sysconfig/httpd /etc/logrotate.d/httpd
The preceding example searches the /etc
directory; however, this could also be used to search any application home directory for user configuration files. Similar to searching for log files, using the find
command to search for configuration files is generally considered a last resort step and should not be the first method used.
The proc filesystem
An extremely useful source of information is the proc
filesystem. This is a special filesystem that is maintained by the Linux kernel. The proc
filesystem can be used to find useful information about running processes, as well as other system information. For example, if we wanted to identify the filesystems supported by a system, we could simply read the /proc/filesystems
file:
$ cat /proc/filesystems nodev sysfs nodev rootfs nodev bdev nodev proc nodev cgroup nodev cpuset nodev tmpfs nodev devtmpfs nodev debugfs nodev securityfs nodev sockfs nodev pipefs nodev anon_inodefs nodev configfs nodev devpts nodev ramfs nodev hugetlbfs nodev autofs nodev pstore nodev mqueue nodev selinuxfs xfs nodev rpc_pipefs nodev nfsd
This filesystem is extremely useful and contains quite a bit of information about a running system. The proc filesystem
will be used throughout the troubleshooting steps within this book. It is used in various ways while troubleshooting everything from specific processes to read-only filesystems.
- Node.js Design Patterns
- Angular UI Development with PrimeNG
- Oracle從新手到高手
- Visual FoxPro程序設計教程
- HTML5+CSS3基礎開發教程(第2版)
- 機械工程師Python編程:入門、實戰與進階
- 機器學習與R語言實戰
- 從零開始學Linux編程
- 微服務從小白到專家:Spring Cloud和Kubernetes實戰
- C語言從入門到精通
- OpenGL Data Visualization Cookbook
- Vue.js光速入門及企業項目開發實戰
- Learning C++ by Creating Games with UE4
- Java EE項目應用開發
- Python數據預處理技術與實踐