[Troubleshooting Mac OS X Kernels W Dmesg
Jamar Lizarraga
Possible post-boot messages include system errors, device errors, and information about any USB device that someone might plug in. For example, the following dmesg information appeared after inserting a USB drive:
As you can see, I used the grep command with the -i option so it ignores case and I will see everything associated with USB devices regardless of that (Usb, usb, or USB). This practice is good for any subsystem or filter that you want to use. Always ignore your filter's case.
The use of the -i option here is superfluous but I always include it just in case there are any results that I wouldn't see otherwise. I use the up arrow key to replay my last command (a most excellent Bash feature) and just backspace over the last thing I searched for and replace it with my new keyword, so once I enter the command, I never have to bother with anything except what I'm searching for. No harm is done either way.
The last four lines display information about the CD-ROM drive. Although the CD-ROM drive is virtual on this system, if the virtual machine's complement of hardware includes it the drive can load ISO image files as if they were a bootable image on physical media.
The dmesg command isn't big and flashy. It doesn't do a lot of things or have a long list of options. Instead, it is elegant in its simplicity and as practical as that your pocket protector. Rather than as an afterthought, you should get into the habit of running dmesg on a regular basis on your systems. And, when something goes wrong, run it again to find out what the kernel knows about the problem. You might save yourself some grief and a few troubleshooting steps. You also might also look like a hero to your coworkers and management for finding the problem so quickly. Remember, time is money and you're trying to save it and the day.
Ken has used Red Hat Linux since 1996 and has written ebooks, whitepapers, actual books, thousands of exam review questions, and hundreds of articles on open source and other topics. Ken also has 20+ years of experience as an enterprise sysadmin with Unix, Linux, Windows, and Virtualization. More about me
The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. The content published on this site are community contributions and are for informational purpose only AND ARE NOT, AND ARE NOT INTENDED TO BE, RED HAT DOCUMENTATION, SUPPORT, OR ADVICE.
Linux is a popular and powerful operating system used by many system administrators, developers, and IT professionals for various purposes, including server management, data centers, and embedded systems. Troubleshooting and diagnosing issues in a Linux system are crucial tasks for maintaining its optimal performance and ensuring smooth operation.
To effectively troubleshoot and diagnose Linux systems, there are several built-in diagnostic and monitoring tools available. These tools provide insights into the system's performance, logs, and various metrics that can help identify and resolve issues. In this article, we will explore three essential Linux diagnostic tools: dmesg, syslog, and sar.
The dmesg, syslog, and sar tools are command-line utilities that are commonly used in Linux for troubleshooting and diagnosing issues. These tools provide valuable information about system logs, performance metrics, and events, which can be useful in identifying and resolving problems.
The dmesg Linux command stands for "display message" and is used to display the kernel ring buffer messages. The kernel ring buffer is a log that contains messages generated by the Linux kernel during boot time and runtime. These messages provide information about various system events, including hardware detection, device drivers, system errors, and warnings.
The dmesg Linux command provides a convenient way to view these kernel messages and helps in troubleshooting hardware-related issues, driver problems, and system errors. It allows system administrators to monitor the system's health and diagnose problems in real-time or by reviewing past logs.
Analyzing system events: The dmesg Linux command can provide logs related to various system events, such as power management events, ACPI events, and system events triggered by user-level processes.
You can print logs for various levels. Logs are essentially divided into eight different levels; emerg, alert, crit, fail, caution, notice, data and investigate. You have the option to print logs of these levels by utilizing --level option. The dmesg --level=err command, as an example, is used to print all error-related to dmesg logs, as shown below.
You can filter the dmesg output to only display specific types of messages using the grep command. For example, if you only want to see messages related to USB devices, you can use the following command:
The dmesg Linux command retrieves messages from the kernel's circular buffer, which has a limited size. Over time, the buffer can become full, and old messages may be overwritten by new messages. If you want to clear the dmesg buffer and start fresh, you can use the -c option. For example:
Linuxsyslog is a standard logging protocol used in Unix-based systems, including Linux, for collecting, storing, and managing system logs. It allows various system components, applications, and services to send log messages to a central logging server or store them locally for later analysis.
syslog provides a standardized format for logging messages, including a priority level, a timestamp, a hostname, and a message text. The priority level indicates the severity of the message, ranging from "emerg" (emergency) to "debug" (debugging information), which helps in filtering and categorizing log messages based on their severity.
syslog allows system administrators to configure log collection, storage, and processing according to their requirements. It provides flexibility in managing logs, such as forwarding logs to remote logging servers, storing logs locally, rotating logs to prevent disk space issues, and filtering logs based on priority or other criteria.
Linux syslog is managed by the syslog daemon, which is responsible for receiving, processing, and storing log messages. The syslog daemon reads the configuration file /etc/syslog.conf to determine how log messages should be handled.
Step 2. Configuring logging rules : In the syslog.conf file, you can specify logging rules that define how log messages should be handled. Each logging rule consists of two parts: a selector and an action. The selector specifies the criteria for filtering log messages, such as the facility and priority level, and the action specifies what should be done with the matching log messages, such as storing them locally or forwarding them to a remote logging server.
Step 3. Defining logging destinations : In syslog, you can define logging destinations, such as local files or remote logging servers, where log messages should be sent. You can specify the logging destinations in the action part of the logging rules in the syslog.conf file. For example, you can configure syslog to store log messages in local files under /var/log directory, or forward them to a remote logging server using the IP address or hostname of the server.
Step 4. Configuring log rotation : Log rotation is a process of managing log files to prevent them from consuming excessive disk space. In syslog, you can configure log rotation by specifying the maximum size or age of log files in the action part of the logging rules in the syslog.conf file. Log rotation can help in managing log files efficiently and preventing disk space issues.
Step 5. Restarting the Linux syslog daemon : After making changes to the syslog.conf file, you need to restart the Linux syslog daemon to apply the changes. You can do this by running the appropriate command for your Linux distribution, such as systemctl restart syslog or service syslog restart.
If you want to configure remote system logging in Linux, where log messages from multiple systems are forwarded to a central logging server, you need to configure both the server and client systems. Here are the steps to configure the server for remote system logging:
Step 1. Install Linux syslog server software : You need to install syslog server software on the central logging server. There are several syslog server software available for Linux, such as rsyslog, syslog-ng, and syslogd. You can choose the one that best fits your requirements and install it using the package manager of your Linux distribution.
Step 2. Configure Linux syslog server : Once the syslog server software is installed, you need to configure it to receive log messages from remote systems. This typically involves editing the configuration file of the syslog server software, such as /etc/rsyslog.conf for rsyslog, to specify the logging destinations for remote log messages.
Step 3. Specify logging destinations : In the configuration file of the syslog server software, you need to specify the logging destinations where log messages from remote systems should be stored. You can specify local files, remote files, or other destinations, such as databases or external logging services, depending on your requirements. For example, you can configure Linux syslog to store log messages from remote systems in separate log files under /var/log directory, or forward them to a remote logging service using a specific protocol.
Step 4. Configure firewall : If you have a firewall enabled on the central logging server, you need to configure it to allow incoming log messages from remote systems. You can do this by opening the necessary ports for syslog communication, such as UDP port 514 or TCP port 601 for rsyslog, in the firewall configuration.
Step 5. Restart Linux syslog server : After making changes to the configuration file of the syslog server software, you need to restart the syslog server to apply the changes. You can do this by running the appropriate command for your Linux distribution, such as systemctl restart rsyslog or service rsyslog restart.
795a8134c1