On Fri, 2 Feb 2024 at 08:54, Rob Janssen <deb...@pe1chl.nl> wrote:
> I am using systemd.
>
Where are you seeing this error? The systemd socket is the thing that opens
up the socket, so shouldn't matter what the snmptrapd process is running as.
When I reboot, I get this:
$ sudo ss -unlp | grep 162
UNCONN 0 0 0.0.0.0:162 0.0.0.0:*
users:(("systemd",pid=1,fd=83))
UNCONN 0 0 [::]:162 [::]:*
users:(("systemd",pid=1,fd=84))
$ pgrep snmptrapd
So systemd is listening to the socket and snmptrapd is not even running.
After I send a trap:
$ sudo ss -unlp | grep 162
UNCONN 0 0 0.0.0.0:162 0.0.0.0:*
users:(("snmptrapd",pid=7296,fd=3),("systemd",pid=1,fd=83))
UNCONN 0 0 [::]:162 [::]:*
users:(("snmptrapd",pid=7296,fd=4),("systemd",pid=1,fd=84))
$ pgrep snmptrapd
7296
Maybe the issue is that this system does not have IPv6 enabled? In
> sysctl.conf it has:
> net.ipv6.conf.all.disable_ipv6 = 1
>
I added that and rebooted, it worked fine.
>
> That has effect on the default snmpd service as well, but I work around
> that by modifying the listen
> port in the config file.
> The snmptrapd.service file has "udp:162" and "udp6:162" args in the
> ExecStart but maybe these aren't used at all
> in this config? In bullseye I think it worked out of the box.
>
In a way, they're used.
In a proper systemd socket activation, the service doesn't need to know or
define the ports it's listening to, they just get a bunch of file
descriptors and use those.
So we could have a command line in the service file with no ports and it
looks like it works; but that is only because snmptrapd is sort-of looking
for UDP port 162.
If you change the socket definition to another port, say 164 you get this:
Feb 02 15:57:37 elmo snmptrapd[9123]: couldn't open udp:162 -- errno 13
("Permission denied")
Feb 02 15:57:37 elmo snmptrapd[9123]: couldn't open udp:162 -- errno 13
("Permission denied")
system opens port 164, a trap to port 164 starts snmptrapd which not only
listens to the systemd FD, but opens its own ports too running as a
non-priv user.
OK, so change the service definiton to listen to some port above 1024, it
should be ok because it can open that port and use the systemd FD. For some
reason
it doesn't (as in it starts but there are no messages).
What that means is the ports that are defined in the socket file need to
match the ports in the service file. snmptrapd is shipped with that:
$ grep 162 debian/snmptrapd.s*
debian/snmptrapd.service:ExecStart=/usr/sbin/snmptrapd -LOw -f udp:162
udp6:162
debian/snmptrapd.socket:ListenDatagram=0.0.0.0:162
debian/snmptrapd.socket:ListenDatagram=[::]:162
debian/snmptrapd.socket:# ListenStream=0.0.0.0:162
debian/snmptrapd.socket:# ListenStream=[::]:162
It would be more friendly when snmpd and snmptrapd degrade gracefully to
> IPv4-only when there is no IPv6 on the system.
>
I don't think its that.
- Craig
