---
type: Article
title: "Configure /etc/default/snmpd"
description: "The Debian file that decides whether snmpd even starts: SNMPDRUN and the options snmpd launches with — how to edit them and confirm the agent is listening."
resource: "https://snmp-monitoring.com/setup/default-snmpd-daemon/"
tags: [setup, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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](/setup/install-snmpd-ubuntu-debian.md) 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](/setup/centos-rhel.md).
- **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](/setup/snmpd-conf.md) and the [OID allowlist](/setup/oid-allowlist.md).
- Net-SNMP client tools on hand to test — `snmpwalk` and friends from the [Net-SNMP toolkit](/tools/net-snmp.md).

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:**
   ```bash
   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:
   ```bash
   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:
   ```bash
   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:
   ```bash
   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:
   ```bash
   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](/setup/custom-port.md) 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`:

| Setting | Value | Effect |
|---|---|---|
| `SNMPDRUN` | `yes` | start the `snmpd` daemon on boot |
| `TRAPDRUN` | `no` | do not start `snmptrapd` |
| `SNMPDOPTS` | daemon flags | listen options, run-as user/group, pid file |


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

```bash
# /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.

![Annotated /etc/default/snmpd file highlighting SNMPDRUN=yes and the snmpd daemon options line](https://snmp-monitoring.com/img/setup/etc-default-snmpd.webp)

## Verify it works

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

```bash
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:

```bash
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:

```bash
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](/setup/troubleshooting.md) 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](/setup/custom-port.md).
- **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](/setup/secure-community-string.md) and a tight [OID allowlist](/setup/oid-allowlist.md).
- **Prefer SNMPv3** on untrusted networks; v2c communities travel in clear text.

The full threat picture lives in the [security section](/security/index.md).

## 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](/monitoring/double-durability.md).

[ostr.io Monitoring](https://ostr.io/service/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](/setup/add-endpoint-ostrio.md) to wire it up.

![Diagram of an external monitor polling a Debian host whose snmpd was enabled via /etc/default/snmpd](https://snmp-monitoring.com/img/setup/external-monitor-daemon.webp)

## FAQ

**What does `SNMPDRUN=yes` actually do?**
It's the master on-switch in `/etc/default/snmpd`. The init/service wrapper reads it; if it isn't `yes`, `snmpd` won't be started at boot even when `snmpd.conf` is perfect. Flipping it to `yes` and restarting is the fix for "my config is right but nothing answers."

**Where do I set the listening port — here or in snmpd.conf?**
Both are possible depending on your Net-SNMP version, but pick one. Modern packages favor the `agentAddress` line in `snmpd.conf`; older ones read an options variable in `/etc/default/snmpd`. Setting it in both risks a conflict, so choose the file your distro honors and keep it there.

**Do I need `TRAPDRUN` for external monitoring?**
No. Traps are the daemon *pushing* notifications out. External polling — the model ostr.io uses — *pulls* values on a schedule, so you can leave `TRAPDRUN=no` and lose nothing.

**Why does the service run but not respond to snmpwalk?**
The defaults file did its job — the process is up. A non-responsive agent past that point is a config, community, port, or firewall issue, not a `/etc/default/snmpd` one. Work through the [troubleshooting guide](/setup/troubleshooting.md).

## Conclusion

`/etc/default/snmpd` is the file that decides whether your agent lives. Set `SNMPDRUN=yes` to start it, keep `TRAPDRUN=no` unless you collect traps, and use the options line for logging and PID handling — not for duplicating a port you've already set in `snmpd.conf`. Restart, confirm "active (running)," and prove it with a `snmpget` against uptime. With the daemon reliably up, hand its OIDs to an external monitor so a dead server still tells you it died.