Configure /etc/default/snmpd

People spend an afternoon perfecting snmpd.conf, restart the service, and then nothing answers. The culprit is almost always the other file — /etc/default/snmpd, the little Debian and Ubuntu defaults file that decides whether the daemon even starts and what flags it runs with. It's short, it's easy to overlook, and it controls the two switches that matter most: SNMPDRUN, which turns the agent on, and the command-line options snmpd launches with. This page is only about that file — the snmpd daemon options it holds, how to edit them, and how to confirm the agent is listening afterward.

Prerequisites

You need very little to work with this file, but the pieces have to be present:

• The Net-SNMP snmpd package already installed. On a fresh box, run install snmpd on Ubuntu/Debian first.
• A Debian- or Ubuntu-family system. This is where /etc/default/snmpd lives; Red Hat derivatives put equivalent settings elsewhere, covered in install snmpd on CentOS/RHEL.
• Root or sudo — it's a system file and the service commands are privileged.
• A working /etc/snmp/snmpd.conf with at least a community string and a view. The defaults file starts the daemon; snmpd.conf tells it what to serve. See the snmpd.conf reference and the OID allowlist.
• Net-SNMP client tools on hand to test — snmpwalk and friends from the Net-SNMP toolkit.

If those boxes are ticked, editing the defaults file is a two-minute job.

Step-by-step

The goal here is simple: make sure the agent runs at boot and listens where you expect. Here's the sequence.

1. Open the file as root:

   sudo nano /etc/default/snmpd
   

2. Enable the daemon. Find the run flag and set it to yes. This is the single switch that most often blocks a working config:

   SNMPDRUN=yes
   

3. Leave the trap receiver off unless you actually collect traps. ostr.io-style external polling doesn't need it, and an idle listener is just extra surface:

   TRAPDRUN=no
   

4. Review the launch options line. Depending on your release this is SNMPDOPTS or an OPTIONS/ARGS variable. It carries the flags snmpd starts with — logging destination, PID file, and the listening address. A typical line looks like:

   SNMPDOPTS='-Lsd -Lf /dev/null -p /run/snmpd.pid'
   

   -Lsd logs to syslog at daemon priority; -p names the PID file. If your build pins the listen address here rather than in snmpd.conf, that's where a trailing udp:161 would sit.
5. Save and reload systemd, then restart so the new defaults take effect:

   sudo systemctl daemon-reload
   sudo service snmpd restart
   

One habit that saves grief: decide where the listening port is set and keep it in one place. Older packaging expected the address in this defaults file; modern Net-SNMP prefers the agentAddress line in snmpd.conf. Split it across both and they can fight. If you're moving off UDP 161 for security — which the ostr.io docs recommend — do it once, in whichever file your distro honors, and verify. The custom port guide walks through the move. Everything else in /etc/default/snmpd is about lifecycle: does the daemon start, does it log where you can find it, does it clean up its PID file on stop.

Configuration example

The settings that control the daemon in /etc/default/snmpd:

A finished, commented /etc/default/snmpd is refreshingly small. Here's the whole thing with notes:

# /etc/default/snmpd — Debian/Ubuntu daemon defaults

# Start the SNMP agent at boot? This is the master switch.
SNMPDRUN=yes

# Run the trap daemon (snmptrapd)? Off unless you receive traps.
TRAPDRUN=no

# Command-line options passed to snmpd on start:
#   -Lsd     log to syslog, daemon facility
#   -Lf ...  send file logging to /dev/null (rely on syslog)
#   -p ...   write the process ID here
SNMPDOPTS='-Lsd -Lf /dev/null -p /run/snmpd.pid'

That's genuinely all the defaults file does. The heavy lifting — communities, groups, views, which OIDs are exposed — happens in /etc/snmp/snmpd.conf, which is a deliberate separation: this file governs the process, that file governs the data. Once the agent is running, it serves the real metrics from the Host Resources MIB (RFC 2790) and friends — host uptime at 1.3.6.1.2.1.25.1.1.0, CPU load at 1.3.6.1.2.1.25.3.3.1.2, storage used at 1.3.6.1.2.1.25.2.3.1.6. Toggle the daemon on here; expose those OIDs there.

Verify it works

Two commands close the loop. First, is the service actually up?

service snmpd status

You want an "active (running)" line. If it says the service is disabled or masked, SNMPDRUN didn't take, or systemd needs another daemon-reload. Second, does it answer a real query? Poll uptime from the same host:

snmpget -v2c -c <community> localhost 1.3.6.1.2.1.25.1.1.0

A TimeTicks value comes back and you're done — the daemon started, read its config, and is serving OIDs. Confirm it's listening on the port you meant:

sudo ss -lnup | grep snmpd

That shows the UDP socket the agent bound to. If the status is running but queries time out, the problem has moved past the defaults file into config or firewall territory — the SNMP troubleshooting guide picks it up from there.

Security note

The defaults file is small but it still sets the daemon's posture. Keep these in mind:

• Don't start what you don't use. Leave TRAPDRUN=no unless you genuinely receive traps — fewer listeners, less surface.
• Bind tightly. If the listen address lives here, restrict it to the interface your monitor reaches, not a blanket 0.0.0.0.
• Move off the default port. UDP 161 draws automated scans; a random high port cuts the noise. See set a custom SNMP port.
• The daemon is only as safe as its config. A running agent with a weak community leaks everything — pair this with a strong community string and a tight OID allowlist.
• Prefer SNMPv3 on untrusted networks; v2c communities travel in clear text.

The full threat picture lives in the security section.

Next: connect external monitoring

Getting the daemon running is step one. But a locally-running agent shares a fate with its host: if the machine crashes, the agent dies with it and stops answering — right when you most need to know. External monitoring dodges that. An independent poller outside your network keeps hitting the agent on its own cadence, and the silence of a dead host becomes an alert instead of a blind spot. That independence is the whole point of double durability.

ostr.io Monitoring does this without any extra software on the box — it polls the OIDs your agent exposes and sends real-time email and SMS alerts from the outside. Once /etc/default/snmpd has the daemon running cleanly, add an SNMP endpoint in ostr.io to wire it up.