Just took over a Linux server that suddenly reports “Service failed to start” and can’t find the critical logs after searching through the /var/log directory? Many new operations staff may fall into the “log confusion” dilemma. In fact, by mastering 3 core commands and remembering common log paths, you can locate the issue in just 5 minutes.
1. First, solve the “Where are the logs”: Quick reference for common Linux log paths
No need to memorize, just bookmark this “log path table” and refer to it during troubleshooting:
| Log Path | Content Recorded | High-Frequency Usage Scenarios |
|---|---|---|
| /var/log/messages | System core logs (kernel, hardware, service startup) | Server blue screen, abnormal service startup, hardware failure troubleshooting |
| /var/log/secure | Security logs (SSH login, user authorization, sudo operations) | Troubleshooting “login failed” and “permission denied” security issues |
| /var/log/nginx/access.log | Nginx access logs | Analyzing user requests, locating “404/502” error sources |
| /var/log/mysqld.log | MySQL operation logs | Database startup failures, SQL execution error troubleshooting |
| /var/log/cron | Scheduled task logs (crontab) | Troubleshooting “scheduled task not executed” and “script error” issues |
2. Next, learn “how to check”: 3 commands to efficiently filter logs
After finding the log files, instead of scrolling through line by line, use these 3 commands to quickly lock onto key information:
1. Filter by “time”: Locate faults in a specific time period
For example, to check the Nginx error logs for “today from 14:00 to 15:00”, use<span><span>grep</span></span> with the time format:
# View records in the Nginx error log from 2024-06-11 14:00 to 15:00grep "2024/06/11 14:" /var/log/nginx/error.log
Key Tip: Different logs have different time formats (e.g., MySQL uses “2024-06-11T14:30:00”). First, check one line of the log to determine the format, then adjust the grep keyword accordingly.
2. Filter by “keyword”: Lock onto core fault information
If you encounter “service failed to start”, directly search for keywords like “error” or “fail”. For example, to troubleshoot SSH login failures:
# Find all "login failed" records in the secure log (keyword: Failed password)grep "Failed password" /var/log/secureAdvanced Usage: Use<span><span>-i</span></span> to ignore case (e.g.,<span><span>grep -i "error"</span></span>), to avoid missing variations like “Error” or “ERROR”.
3. View logs in real-time: Monitor ongoing issues
If a service is currently reporting errors, use<span><span>tail -f</span></span> to track logs in real-time, for example, monitoring MySQL operation status:
# View MySQL logs in real-time, new content will refresh automaticallytail -f /var/log/mysqld.log
Emergency Tip: Press<span><span>Ctrl+C</span></span> to stop real-time monitoring. If the logs are refreshing too quickly, add<span><span>-n 50</span></span> to view the last 50 lines:
tail -n 50 -f /var/log/mysqld.log.3. Pitfall Reminder: Can’t find logs? Check these 2 points first
- Permission issues: Regular users may not have permission to read logs like /var/log/secure, and need to use
<span><span>sudo</span></span>to elevate privileges (e.g.,<span><span>sudo cat /var/log/secure</span></span><code><span><span>);</span></span> - Log rotation: Old logs may be compressed into
<span>.gz</span>files (e.g.,<span>messages-20240601.gz</span>), use<span>zcat</span>to view compressed logs:zcat /var/log/messages-20240601.gz | grep "error"
Finally, I want to ask: When you usually check Linux logs, do you most often encounter the issue of “logs not found” or “low filtering efficiency”? Share your pain points in the comments, and I will provide targeted tips next time.