When installing the nav-debian package from scratch, the package initially tries to start the nav services after the package is configured. This appears to fail in many instances, but since the package startup is "behind the scenes" without verbose logging, it's not clear why this happens.
Attempting a manual start after the failure seems to work just fine.
The tracebacks provided further down seem to indicate a problem with using the NET-SNMP library, which seems strange, since that package should have been installed as part of the process (and starting a second time does not produce this error)
I patched the package to use the --verbose flag to the nav start command, and these two tracebacks provide some hints into why the full startup fails.
ipdevpoll:
Traceback (most recent call last):
File "/usr/bin/ipdevpolld", line 23, in <module>
from nav.ipdevpoll.daemon import main
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/daemon.py", line 45, in <module>
from nav.ipdevpoll import ContextFormatter, schedule, db
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/schedule.py", line 35, in <module>
from nav.ipdevpoll.snmp import SnmpError, AgentProxy
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/ipdevpoll/snmp/__init__.py", line 21, in <module>
import pynetsnmp.twistedsnmp
File "/opt/venvs/nav/lib/python3.7/site-packages/pynetsnmp/twistedsnmp.py", line 11, in <module>
from . import netsnmp
File "/opt/venvs/nav/lib/python3.7/site-packages/pynetsnmp/netsnmp.py", line 55, in <module>
lib.netsnmp_get_version.restype = c_char_p
File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__
func = self.__getitem__(name)
File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /opt/venvs/nav/bin/python: undefined symbol: netsnmp_get_version
snmptrapd:
Traceback (most recent call last):
File "/usr/sbin/snmptrapd.py", line 42, in <module>
from nav.snmptrapd import agent
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/snmptrapd/agent.py", line 17, in <module>
from nav.Snmp import BACKEND
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/Snmp/__init__.py", line 38, in <module>
from .pynetsnmp import *
File "/opt/venvs/nav/lib/python3.7/site-packages/nav/Snmp/pynetsnmp.py", line 36, in <module>
from pynetsnmp import netsnmp
File "/opt/venvs/nav/lib/python3.7/site-packages/pynetsnmp/netsnmp.py", line 55, in <module>
lib.netsnmp_get_version.restype = c_char_p
File "/usr/lib/python3.7/ctypes/__init__.py", line 369, in __getattr__
func = self.__getitem__(name)
File "/usr/lib/python3.7/ctypes/__init__.py", line 374, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /opt/venvs/nav/bin/python: undefined symbol: netsnmp_get_version
Environment (please complete the following information):
Describe the bug
When installing the nav-debian package from scratch, the package initially tries to start the nav services after the package is configured. This appears to fail in many instances, but since the package startup is "behind the scenes" without verbose logging, it's not clear why this happens.
Attempting a manual start after the failure seems to work just fine.
The tracebacks provided further down seem to indicate a problem with using the NET-SNMP library, which seems strange, since that package should have been installed as part of the process (and starting a second time does not produce this error)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The initial service startup should succeed.
Tracebacks
I patched the package to use the
--verboseflag to thenav startcommand, and these two tracebacks provide some hints into why the full startup fails.ipdevpoll:
snmptrapd:
Environment (please complete the following information):