When performing tasks in Linux or using programs that interact within a Linux environment, it is feasible that you will encounter errors. While some errors may be relatively minor and may not be associated with interruptions of major program functions; to avoid escalation of issues, even minor errors should be addressed. There are also errors associated with events that could potentially cause systems to stop responding, functions to not complete as intended, or loss of data. Errors can be displayed in the form of codes or messages that indicate an anomaly or other potential issue has been detected and provide information for the source of an issue.
Locating Error Logs
If you do not receive the expected output in a program or a program seems to have stopped responding, then locating the errors associated with the occurrence could prove to be an essential step in diagnosing the issue(s). In Linux, I have found that one of the best ways to gain more insight on events is to use file navigation to find details. When diagnosing issues, error logs often became my best friend. Of course, in order to navigate through file systems, one could first access a command line. An interface had been designed to provide user access to as well as use of a command line. The default command line interface for Linux is the Bourne Again Shell (BASH), which is an advanced version of the Bourne Shell (SH).
BASH is Unix based and although BASH is based on standards derived from a Portable Operating System Interface for Unix (POSIX) type shell, BASH also includes functions that had not originally been supported by POSIX shells. The means of access to a command line in Linux can vary as users can set access methods (such as by creating a shortcut for a terminal) and default methods may vary from version to version. Common ways to access a Linux command line are via a terminal (In some versions of Linux, the terminal can be accessed from the System Tools menu or from a toolbar) or console (can be accessed with combination keys, such as CTRL+ALT+F1). Explore a tutorial for more insight on BASH scripting.
Commands and scripts executed from a command line can be used for locating information, which can include errors. Although the concept of using scripts and using commands can be quite similar, one way to differentiate commands from scripts is as follows: a collection of commands (such as those in a function or module) can be encompassed as a script (which can then be stored in a directory and called from a directory); whereas, commands are typically manually typed line-by-line directly in a command line. Scripts can be created, edited, and saved from an editor; such as the vi editor as can be used for automation purposes. For more information on using a command line or editor for Linux, augment your studies by using a tutorial on Udemy.
While at the command line, you’ll want to find the directories that contain errors or information related to errors. You can view a list of logs by using a command, such as the following:
cd /var/logs ls
The commands shown above will change the directory from your current directory to the /var/logs directory and then list out the files in the directory. Of course; you can also use listing options, such as the following:
ls – a
The above switch would include hidden files in the output list. If you know which file in a directory that you would like to view, you could change/switch to the directory and then search for specific content, by using commands such as the following:
cd /var/logs/messages ls -l |grep -i error
The commands listed above would change the directory to the directory for messages and compose a list of information (for which the output may be viewed page-by-page) found from the directory that includes the keyword, error (for which the grep utility along with the keyword had been used). Note that -I had been included in this case; the case of characters being searched for can be ignored by using -i in a search, in order to include more possibilities in a search. An additional consideration would be that there are many keywords that can be searched for, when looking for errors, which may not include the word “error”. If you wanted to search through the contents (in a page-by-page manner) of a file without searching for a specific keyword, then you could use a command such as the following:
cat messages |pg
Subdirectories located in the /var directory may vary. There are common directories that may be found in the /var directory and other directories, which depend on factors such as the types of applications used within a system, may be found in the /var directory (this is the case for other directories as well). Examples of subdirectories associated with specific programs that may be on a system, include the following: /var/log/apache2, which may contain errors associated with Apache Web Server events; /var/log/samba, which may include errors and other logged information pertaining to Samba (software that functions as a third party allowing interaction and/or sharing between Windows and Linux servers); /var/log/sssd, which contains information for the System Security Services Daemon; /var/log/posIMB, which may be found in an IBM retail environment; etc. There are different directories in which information for diagnosis may be found. As an example of a case in which other directories should be searched; In order to gain more insight on the PIDs (Process Identification Number) for processes that may have been running during the same time frame that errors had occurred, you may want to view directories, such as the /var/run directory.
Examples of Errors and Scenarios
Official definitions of error codes have been documented in the errno.h file (error notification header file) for Linux.
Upon attempting to complete a transaction in a retail environment; a user received a message indicating that the transaction could be completed at that moment (the user has received this message because a system administrator has used error handling methods along with the STDOUT command to display messages when errors occur). The user contacted their tech support who had then searched through error logs to locate errors that occurred in the same time frame that the user had been unable to progress further with their transaction. While contacting tech support, other users in the store experience issues such as terminals that have stopped responding and credit cards not being authorized. The issues had occurred within minutes of tech support being contacted and the IT specialist decided to use the following command (after navigating to the appropriate directory) in order to have the last fifty lines of a file displayed:
tail -50 error.log
Note that the tail command is being used for a file called error.log; in this scenario, the error.log file had been created by an administrator who had root access (the administrator had redirected errors meeting a specific criteria to the non-standard error log). Additionally, if the system administrator had wanted to create a script that included steps; such as those for the following: navigating to the file, retrieving specific errors, and then having those errors displayed, then that would have also been possible. In some cases; it may be more ideal for those with limited permissions, which may include a majority of system users, to simply run a script from a terminal.
In this case, the following error had been found to be related to the issue: Error 112 – EHOSTDOWN
In addition to the Linux errors found, there had been other connection related issues found. The tech support line started to receive more calls from other locations regarding the same types of issues. After the cause had been discovered, the network issue had been corrected.
An administrator, who had implemented Samba, had been attempting to mount a Samba share when they received the error code, 127. The administrator views the error notification file header for more details and discovers that the code (EKEYEXPIRED) is usually security related and indicates that a key has expired. The administrator reattempted after their credentials had been updated and in this case, had then been able to mount the share.
An administrator is monitoring error logs and comes across an error 80 (ELIBBAD). After research, the administrator had found that a function could not be completed for a plugin due to the files the function had attempted to use being corrupt library files. Monitoring error logs and research are imperative tasks for system administration; find out how you can develop skills to become a system administrator.
While there is an array of possible scenarios and possible errors that may be generated, this article has covered some of the Linux error codes that may occur. You may use a relatively manual approach with searching of logs, use information retrieved and sent using automated processes, or use a combination of methods. In order to diagnose issues, you may also feel free to utilize other resources such as the Manual Pages (accessed with the man command) in Linux as well as by researching symptoms of system issues and searching log files. Not only can gaining insight on Linux codes help you with troubleshooting issues, but doing so may also help you prevent further issues.