Systemd for voipmonitor service management

This guide provides the recommended method for managing the VoIPmonitor sensor service using systemd on modern Linux distributions.

Overview

Modern Linux distributions (Debian, Ubuntu, CentOS, RHEL, AlmaLinux) use systemd as the primary service manager. The recommended approach is to create a systemd unit file that wraps the reliable /etc/init.d/voipmonitor script, ensuring compatibility across various distributions.

⚠️ Warning: Always use systemctl commands to manage the service. Do not use the legacy service command (e.g., service voipmonitor start) as systemd may lose track of the process state.

Unit File Configuration

Create file /etc/systemd/system/voipmonitor.service:

[Unit]
Description=VoIPmonitor sniffer
After=syslog.target
After=network.target
After=mysql.service

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/voipmonitor start
ExecStop=/etc/init.d/voipmonitor stop
PrivateTmp=false

[Install]
WantedBy=multi-user.target

Dependency Customization

MySQL/MariaDB

The line After=mysql.service is only required if the database is installed locally on the same server. If your database runs on a remote server, you can remove this line.

Napatech Cards

If you use Napatech hardware acceleration cards, add the following lines to the [Unit] section to ensure drivers load before VoIPmonitor starts:

Before=network-pre.target
Wants=network-pre.target
After=ntservice.service
Requires=ntservice.service

Activation and Management

Reload systemd after changes

systemctl daemon-reload

Enable start on boot

systemctl enable voipmonitor

Standard management commands

# Start the service
systemctl start voipmonitor

# Stop the service
systemctl stop voipmonitor

# Restart the service
systemctl restart voipmonitor

# Check status and view recent logs
systemctl status voipmonitor

Troubleshooting

Service Not Starting vs Connection Failures

Before troubleshooting systemd issues, identify whether the problem is with the systemd service OR with network connectivity:

Problem Type	Symptoms	Solution
Service fails to start	systemctl start voipmonitor returns error, service shows failed status	Continue with this guide
Service starts but cannot connect	Service shows active (running) but logs show "cannot connect to server"	See Distributed Architecture Troubleshooting

Unit File Syntax Errors

If you encounter errors like:

Error: Assignment outside of section. Ignoring.
Job for voipmonitor.service failed because the control process exited with error code.

This indicates syntax errors in the unit file. To bypass and fix:

# 1. Identify existing processes
ps aux | grep voipmonitor

# 2. Kill the watchdog process first (find its PID from ps output)
kill <PID_WATCHDOG>

# 3. Kill the main voipmonitor process
kill -9 <PID_VOIPMONITOR>

# 4. Stop using init.d script
/etc/init.d/voipmonitor stop

# 5. Start using init.d script (bypasses broken systemd unit)
/etc/init.d/voipmonitor start

Common Unit File Errors

• Missing [Unit], [Service], or [Install] section headers
• Assignments placed outside of their proper sections
• Typos in directive names (e.g., ExecStar instead of ExecStart)
• Missing equals (=) signs between directive and value

After fixing the unit file:

systemctl daemon-reload
systemctl start voipmonitor

Internal Watchdog and SystemD

When using SystemD to manage the VoIPmonitor service, there is a potential issue if the internal watchdog restarts the VoIPmonitor process. By default, the internal watchdog may attempt to restart the binary directly. When this happens, the main process ID (PID) tracked by SystemD exits, causing SystemD to mark the service as "failed" or "dead," even though a new process has been spawned.

⚠️ Warning: If the internal watchdog is enabled but not configured to use SystemD for restarts, the SystemD service status will incorrectly show the service as failed after a watchdog-triggered restart.

Configuring the Watchdog to Use SystemD

To ensure that SystemD correctly tracks the service status after a watchdog-triggered restart, edit the /etc/voipmonitor.conf file:

1. Enable the watchdog (if not already enabled):

   watchdog = yes
   

2. Add the following line to make the watchdog use SystemD for restarts:

   watchdog_run_command = systemctl restart voipmonitor
   

Why This Works

Setting watchdog_run_command forces the watchdog to hand over the restart process to SystemD via systemctl restart. This ensures that SystemD manages the entire stop/start cycle, keeps its internal state tracking consistent, and correctly reports the service as active (running) after a watchdog-triggered restart.

Verification

After configuration, you can verify that SystemD correctly tracks the service:

# Check service status
systemctl status voipmonitor

# Service should show "active (running)" not "failed" or "dead"

AI Summary for RAG

Summary: Guide for managing VoIPmonitor sensor with systemd by wrapping the init.d script in a unit file. Configuration uses Type=forking with RemainAfterExit=yes. Key dependencies: After=mysql.service for local DB, After=ntservice.service with Requires=ntservice.service for Napatech. Always use systemctl commands (not legacy service) for reliable process tracking. For watchdog integration, set watchdog_run_command = systemctl restart voipmonitor to prevent systemd from incorrectly reporting failed status after watchdog-triggered restarts.

Keywords: systemd, systemctl, voipmonitor.service, init.d wrapper, unit file, Type=forking, RemainAfterExit, After=mysql.service, Napatech, daemon-reload, watchdog, watchdog_run_command, service management

Key Questions:

• What is the recommended systemd unit file for VoIPmonitor?
• Why should I use systemctl instead of the service command?
• How do I configure systemd dependencies for MySQL and Napatech?
• How do I make VoIPmonitor start automatically on boot?
• How do I bypass a broken systemd unit file?
• What causes "Assignment outside of section" error in systemd?
• Why does systemd show service as failed after watchdog restart?
• What should I set watchdog_run_command to when using systemd?