Eliminating 10,000‑Line DHCP Server Spam in Syslog Without Disabling the Service

Problem: DHCP Spamming Syslog

A running DHCP server can generate thousands of “client request” and “lease granted” messages every hour. On busy networks this inflates /var/log/syslog to 10 k lines a day, making it hard to spot genuine errors and bloating disk usage. The service must stay online, so the goal is to silence the noise without turning the daemon off.

Why You Can’t Just Disable the Service

Disabling dhcpd or dhcp-server removes the spam but also removes the ability to hand out IPs. In a homelab or small office you may have a separate DHCP server (e.g., a router) that you can stop, but in many setups the Linux box is the sole DHCP provider. The logs are useful for troubleshooting mis‑configurations, but the volume is excessive.

Solution 1 – Rsyslog Filtering

Most modern distributions ship with rsyslog as the syslog daemon. It allows fine‑grained filtering by program name, facility, or priority.

Create a dedicated drop file:

sudo nano /etc/rsyslog.d/99-dhcp-drop.conf

Add:

# Drop all DHCP daemon messages
if $programname == 'dhcpd' then stop

The stop action tells rsyslog to discard the message after the filter matches. Reload rsyslog:

sudo systemctl reload rsyslog

What Happens

All lines originating from the dhcpd binary are discarded.
Other DHCP‑related logs that come from different programs (e.g., dhclient) remain untouched.
The DHCP server continues to run and serve leases.

Caveats

If you need to debug a DHCP issue, you’ll have to comment out the filter or temporarily change the facility.
Some distributions log DHCP via systemd-journald directly; in that case the filter above won’t see the messages. See the next section.

Solution 2 – Change the DHCP Log Facility

dhcpd can be instructed to log to a different syslog facility. By default it uses daemon, which is the most common facility. Switch it to a less‑used one (e.g., local0) and then drop that facility in rsyslog.

Edit /etc/dhcp/dhcpd.conf:

# Use local0 for DHCP logs
log-facility local0;

Restart the server:

sudo systemctl restart isc-dhcp-server

Now drop local0 in rsyslog:

sudo nano /etc/rsyslog.d/99-dhcp-drop.conf

# Drop DHCP logs sent to local0
if $syslogfacility-text == 'local0' then stop

Reload rsyslog again. This approach keeps the DHCP daemon’s internal logging intact while preventing the messages from reaching the main log files.

Trade‑off

You lose the ability to see DHCP logs in /var/log/syslog unless you re‑enable the filter. If you need a quick audit trail, you can temporarily comment out the drop rule and restart rsyslog.

Solution 3 – systemd‑journald Filters

If your distro uses systemd‑journald as the primary log sink (many do), you can filter messages before they hit the journal or before they are forwarded to rsyslog.

Create a drop rule in /etc/systemd/journald.conf.d/99-dhcp-filter.conf:

[Journal]
# Drop DHCP daemon messages from the journal
SystemMaxLevel=info
# The following line is a placeholder; systemd-journald itself does not filter by program.
# Use a separate service or rsyslog for fine filtering.

Because journald lacks a native “drop by program” filter, the most reliable path remains rsyslog. However, you can reduce the journal size by setting SystemMaxUse and SystemMaxFileSize to keep the disk usage in check.

Trade‑offs and Security Considerations

Approach	Pros	Cons	Security Impact
Rsyslog filter by program	Simple, immediate	Requires rsyslog; loses logs	Minimal; you lose audit trail for DHCP events
Change facility + drop	Keeps daemon logs separate	Requires config change; still no logs	Same as above; but you can enable facility temporarily
Journald size limits	Keeps all logs, just limits disk	Requires manual rotation; still noisy	No loss of audit data

Auditability: Discarding DHCP logs removes a source of evidence for mis‑configurations or malicious activity. If your network is critical, consider keeping a separate, read‑only log file for DHCP events. For example, redirect dhcpd logs to a dedicated file:

sudo nano /etc/rsyslog.d/99-dhcp-archive.conf

# Store DHCP logs in a separate file
if $programname == 'dhcpd' then /var/log/dhcpd.log
& stop

Now you have a compact, searchable log without cluttering the main syslog.

Troubleshooting

Filter not working?
Verify the program name matches. Use journalctl -u isc-dhcp-server -f to see the exact $programname. Rsyslog’s $programname is derived from the PRI field; if the daemon logs via systemd-journald, you may need to use $syslogfacility-text instead.
Logs still appear
Ensure rsyslog is running: systemctl status rsyslog. If it’s inactive, start it with sudo systemctl start rsyslog.
Double‑check the config file syntax; a missing } or stray character can break the rule.
You still see a few DHCP lines
Some packets are logged by dhclient or other clients. The filter above only drops the server’s output. If you want to silence those too, add a second rule for dhclient:
```
if $programname == 'dhclient' then stop
```
You need the logs back temporarily
Comment out the drop rule, reload rsyslog, and then re‑enable when you’re done diagnosing.

That’s the gist of keeping your syslog tidy while still having a DHCP server that actually works. Happy hacking!