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: This guide provides the stable method for managing the VoIPmonitor sensor using systemd by wrapping the legacy init.d script in a unit file. This approach ensures compatibility across various distributions including AlmaLinux 9.5. The unit file configuration uses Type=forking with RemainAfterExit=yes and calls /etc/init.d/voipmonitor start/stop directly. Key dependencies include After=mysql.service for local databases and After=ntservice.service with Requires=ntservice.service for Napatech hardware. The guide emphasizes using systemctl commands exclusively (never the legacy service command) for reliable process tracking. A critical configuration for watchdog integration is setting watchdog = yes and watchdog_run_command = systemctl restart voipmonitor in /etc/voipmonitor.conf to prevent systemd from incorrectly reporting the service as failed after a watchdog-triggered restart. Troubleshooting covers distinguishing between systemd failures and network connectivity issues, and provides steps to bypass a faulty unit file using the init.d script directly.

Keywords: systemd, systemctl, voipmonitor.service, init.d wrapper, unit file, Type=forking, RemainAfterExit, dependency, After=mysql.service, Napatech, AlmaLinux, service management, daemon-reload, enable on boot, watchdog, watchdog_run_command, restart automation, process tracking

Key Questions:

• What is the recommended systemd configuration for VoIPmonitor?
• Why should I avoid the service command and use systemctl?
• How do I configure systemd to wait for MySQL before starting VoIPmonitor?
• How do I ensure Napatech drivers are loaded before the sniffer starts?
• What is the correct content of /etc/systemd/system/voipmonitor.service?
• How do I make VoIPmonitor start automatically on boot?
• How do I bypass a broken systemd unit file and start VoIPmonitor manually?
• What causes "Assignment outside of section" error in systemd?
• How do I troubleshoot VoIPmonitor service startup failures?
• How does the internal watchdog interact with systemd service management?
• Why does systemd incorrectly show the service as failed after a watchdog restart?
• What should I set watchdog_run_command to when using systemd?
• How do I ensure systemd correctly tracks the VoIPmonitor service after watchdog restarts?