Log Management and Troubleshooting on FreeBSD

 

 

 

“Don’t panic—check the logs first!” A relaxed, in-depth guide (roughly 1,200 words) for beginners and seasoned admins alike.

 

Why Do Logs Matter?

Picture yourself as a detective and your server as a bustling city. Log files are the police reports: every incident—failed logins, a disk filling up, or a hacker probing your ports—gets written down. When performance suddenly tanks or strange errors pop up, the first thing you should do is look at the logs.

FreeBSD sticks to classic UNIX philosophy—simple, powerful, flexible—so its logging framework is built right in. Even if you’re not a veteran sysadmin, you can master it quickly.

 

Log Directory Structure

By default, every system log lives under:

/var/log/

Log File	Description
/var/log/messages	Kernel and general daemon messages
/var/log/auth.log	Login, sudo, and authentication events
/var/log/maillog	Email activity (Sendmail, Postfix, etc.)
/var/log/cron	Cron job runs and output
/var/log/dmesg.today	Boot-time dmesg output
/var/log/security	Security-related audit events

You’ll also see service-specific logs, e.g. /var/log/nginx/error.log for NGINX or /var/log/httpd-access.log for Apache.

 

Managing Logs: syslogd and newsyslog

 

1 · syslogd — The Log Router

syslogd decides which messages go to which files. Configuration lives in:

/etc/syslog.conf

Syntax:

facility.level    destination

Example:

auth.info        /var/log/auth.log
cron.*           /var/log/cron

Send a test entry with logger:

logger "Custom log test"

 

2 · newsyslog — Automatic Rotation & Compression

Without rotation, a busy log can balloon into gigabytes. newsyslog keeps things tidy.

/etc/newsyslog.conf

/var/log/messages   644  7  100  *  Z

• 644 → file permissions
• 7 → keep seven backups
• 100 → rotate if >100 KB
• Z → compress with gzip

Run rotation manually if needed:

newsyslog

 

Understanding Log Levels

1. emerg — the system is unusable
2. alert — immediate action required
3. crit — critical conditions
4. err — general errors
5. warning — something odd but not serious
6. notice — significant but normal events
7. info — routine information
8. debug — verbose diagnostic data

Filter errors quickly:

grep -Ei 'warn|error|fail' /var/log/messages

 

Common Troubleshooting Scenarios

 

1 · Server Feels Slow or Hangs

1. Check load: top or uptime
2. Read general log: less /var/log/messages
3. Scan recent kernel lines: dmesg | tail -20
4. Inspect RAM/swap: vmstat 1

 

2 · SSH Login Failures

less /var/log/auth.log

Look for wrong passwords, blocked IPs (Fail2Ban, PF), or unknown usernames.

 

3 · Cron Job Didn’t Run

less /var/log/cron

Ensure the script is executable and syntactically correct.

 

4 · Disk Space Suddenly Full

df -h       # Usage by filesystem
du -sh /var/log/*   # Which log is gigantic?

 

Extra Tools for Reading Logs

• logtail — output only the new lines since last run
• logwatch — daily summary emailed to you
• multitail — follow multiple logs simultaneously with color

multitail /var/log/messages /var/log/auth.log

 

Sending Logs to a Central Server (Remote Syslog)

Great for fleets of servers.

On the client:

# /etc/rc.conf
syslogd_flags="-s -v -v -v -a logserver.example.com:*"

On the log server:

# /etc/syslog.conf
*.*    @logserver.local

service syslogd restart

 

Tips

• Combine grep, awk, cut, tail, and sed for laser-focused searches.
• Real-time watch: watch -n 2 tail -n 20 /var/log/messages
• For large environments, pipe FreeBSD logs into Graylog, the ELK Stack, or Grafana Loki.

Log management isn’t just for emergencies—it’s a healthy habit that spares you future headaches. Make it routine to:

• Scan key logs daily (five minutes is plenty).
• Recognize recurring error patterns.
• Rotate and compress logs before they fill the disk.
• Leverage helpers like multitail or ship logs to a central server.

Remember: a “healthy” server isn’t one that never errors—it’s one whose issues are caught early and fixed fast. Logs are your lifelong companion in that mission. Happy troubleshooting!