When managing BSD systems, receiving immediate notifications for critical log events (err priority or higher) can be crucial for system administration. The traditional syslogd daemon doesn't natively support email notifications, but we can implement this through several robust methods.

This approach leverages syslog's ability to pipe messages to external programs:

# /etc/syslog.conf
*.err |/var/log/err_pipe

Create a processing script:

#!/bin/sh
# /usr/local/bin/log_monitor.sh
while read -r line
do
  echo "$line" | mail -s "SYSLOG ALERT: $line" admin@example.com
done < /var/log/err_pipe

For more modern systems, consider migrating to syslog-ng which has built-in email support:

# syslog-ng.conf
destination d_mail {
  smtp(
    host("mail.example.com")
    port(587)
    username("syslog@example.com")
    password("secret")
    tls(yes)
    from("syslog@example.com")
    to("admin@example.com")
    subject("ALERT: $LEVEL on $HOST")
  );
};

filter f_errors { level(err..emerg); };
log { source(s_src); filter(f_errors); destination(d_mail); };

Third-party tools provide more sophisticated monitoring:

# Example Swatch configuration
watchfor /ERR|ERROR|CRITICAL/
  throttle 1:00
  mail=admin@example.com,subject=ALERT

When implementing email alerts:

• Use TLS for email transmission
• Consider rate limiting to prevent mail floods
• Sanitize log content to prevent header injection

Each method has different resource requirements:

If emails aren't being sent:

# Test mail functionality first
echo "Test message" | mail -s "Test" admin@example.com

# Verify pipe permissions
ls -l /var/log/err_pipe

# Check syslogd debug output
/etc/rc.d/syslogd restart -d

Getting real-time email notifications for critical system events (err priority or higher) requires bridging syslog's local logging with SMTP capabilities. BSD's syslogd doesn't natively support email forwarding, but we can implement this through intelligent piping.

While both methods work, named pipes (mkfifo) introduce complexity without significant benefits for this use case. A cleaner approach modifies /etc/syslog.conf to trigger a script:

# /etc/syslog.conf modification
*.err |/usr/local/bin/logalert.sh
*.emerg |/usr/local/bin/logalert.sh

Here's the end-to-end implementation using a shell script with sendmail:

#!/bin/sh
# /usr/local/bin/logalert.sh
while read -r line
do
  echo "Subject: Syslog Alert - $(hostname)
From: syslog@$(hostname)
To: admin@yourdomain.com

Priority: $1
Message: $line" | sendmail -t
done

For production systems, consider these enhancements:

#!/bin/sh
# Enhanced version with throttling
ALERT_FILE="/var/log/.last_alert"
THROTTLE_MIN=30

if [ -f "$ALERT_FILE" ]; then
  last_alert=$(stat -f %m "$ALERT_FILE")
  current_time=$(date +%s)
  if [ $((current_time - last_alert)) -lt $((THROTTLE_MIN * 60)) ]; then
    exit 0
  fi
fi

touch "$ALERT_FILE"
printf "Subject: [$(hostname)] %s\n\n%s" "$1" "$(date)" | sendmail -t admin@yourdomain.com

When implementing this solution:

• Restrict script permissions (chmod 750)
• Use a dedicated mail user with limited privileges
• Implement message sanitization to prevent mail header injection

For more complex environments, consider:

• rsyslog with omemail module
• syslog-ng's destination email templates
• Log monitoring tools like Swatch or Logcheck