GUI troubleshooting

This page provides troubleshooting tips and debugging techniques for the VoIPmonitor web GUI.

GUI Debug Mode

The GUI debug mode allows you to see SQL queries and other debugging information directly in your browser's Developer Console.

Enabling Debug Mode

To enable debug mode in the VoIPmonitor web GUI, add the parameter ?debug=31415 to the end of any GUI URL. For example:

http://your-server/voipmon/admin.php?debug=31415

This enables the following features:

• SQL queries executed by the GUI are logged to the browser's Developer Console
• Additional debugging information is displayed for dashboard panels and charts
• Performance timing and query execution details become visible

Finding SQL Queries for Dashboard Panels

To see the exact SQL query executed by a dashboard panel:

1. Add ?debug=31415 to your GUI URL and navigate to the dashboard
2. Open your browser's Developer Tools (press F12 or Ctrl+Shift+I)
3. Switch to the Console tab
4. Interact with the dashboard (e.g., refresh, change time range, or hover over panels)
5. The SQL queries will be printed to the console log

The queries appear in the console in the order the panels are rendered. If you need to isolate a specific panel, hover over it or interact with its filters after loading the page - this often triggers a re-query which will appear as a new entry in the console.

Disabling Debug Mode

Simply remove the ?debug=31415 parameter from the URL, or navigate to any GUI page without it. Debug mode is not persistent and must be re-enabled each time by adding the URL parameter.

GUI Upgrade Issues

The following are common issues that may occur during GUI upgrades and their solutions.

VM Binary (binary missing) Error

If you encounter an error message indicating "VM Binary (binary missing)" during or after a GUI upgrade, this indicates that the GUI application files were not completely updated. Perform a forced CLI upgrade to resolve this issue:

# Log in to the GUI host as root
# Navigate to the GUI installation directory (default is /var/www/html)
cd /var/www/html

# Execute the forced upgrade command
php php/run.php upgrade -f

The -f flag forces a complete upgrade, which updates any missing or corrupt GUI binaries.

Blank Screen with JavaScript ReferenceError After Update

If you can log in to the GUI after an update but are presented with a blank screen, and the browser's JavaScript console shows an error like:

ReferenceError: _AuditActivity_download_wav is not defined

This is typically caused by a conflicting PEAR file that was not removed during the upgrade. The fix is simple:

# Remove the conflicting old PEAR constants file
rm /usr/share/pear/constants.php

# Refresh your browser (Ctrl+Shift+R) to reload the GUI

After removing this file and refreshing the browser, the GUI should load correctly. This issue occurs because the old constants.php file from the system's PEAR installation conflicts with VoIPmonitor's internal JavaScript definitions.

MySQL/MariaDB Database Corruption

If the Web GUI fails to start and logs show MySQL/MariaDB database errors (such as corrupted tables, missing files, or startup failures), this indicates database corruption. This can occur after manual file deletion, disk failures, or improper MySQL shutdown procedures.

Symptoms

• Web GUI displays database connection errors or shows a blank page
• MySQL/MariaDB service fails to start or immediately crashes
• Error messages in MySQL logs indicating corrupted tables or missing database files
• CDR queries return empty results or throw SQL errors

Diagnosis

First, check the MySQL/MariaDB service status:

# Check if MySQL/MariaDB is running
systemctl status mysql
# or
systemctl status mariadb

# View MySQL error logs for corruption indicators
tail -100 /var/log/mysql/error.log
# or
tail -100 /var/log/mariadb/mariadb.log

Look for error messages such as:

• Table is marked as crashed
• InnoDB: Database page corruption
• Incorrect key file
• Can't open file

Solution: Restore from PCAP Files (Recommended)

If the database is corrupted, a complete restore is necessary. The recommended approach is to restore CDR data from the pcap files stored in the spool directory into a new, clean database. This preserves your call recordings and metadata while fixing the corruption issue.

Warning: This procedure requires stopping the VoIPmonitor services and may take significant time depending on the amount of data to restore.

The following diagram illustrates the restoration workflow:

Step 1: Stop VoIPmonitor Services

Stop all VoIPmonitor services to prevent further database corruption:

# Stop the sniffer service
systemctl stop voipmonitor

# Stop sniffer manager (if running)
systemctl stop voipmonitor-manager

# Stop any other VoIPmonitor services
systemctl stop voipmonitor-gui

Step 2: Backup the Corrupted Database

Although corrupted, create a backup of the existing database for troubleshooting purposes:

# Stop MySQL/MariaDB service
systemctl stop mysql

# Create a backup of the MySQL data directory
sudo cp -a /var/lib/mysql /var/lib/mysql-backup-corrupted

Step 3: Remove the Corrupted Database

Move or remove the corrupted database files to prepare for a fresh database:

# Remove the corrupted VoIPmonitor database directory
sudo rm -rf /var/lib/mysql/voipmonitor

# Alternatively, move it instead of deleting:
sudo mv /var/lib/mysql/voipmonitor /var/lib/mysql/voipmonitor.corrupted

Step 4: Start MySQL/MariaDB Service

Restart the MySQL/MariaDB service:

# Start MySQL/MariaDB
systemctl start mysql

# Verify the service is running
systemctl status mysql

Step 5: Create a Fresh VoIPmonitor Database

Create a new empty database for VoIPmonitor:

# Log in to MySQL as root
mysql -u root -p

Run the following SQL commands:

CREATE DATABASE voipmonitor;
CREATE USER 'voipmonitor'@'localhost' IDENTIFIED BY 'your_password_here';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Replace your_password_here with a strong password.

Step 6: Restore CDRs from PCAP Files

Instruct the sniffer to reprocess all PCAP files from the spool directory and populate the new database:

# 1. Verify your spool directory path
# Check voipmonitor.conf for the spooldir setting (default: /var/spool/voipmonitor)
grep "^spooldir" /etc/voipmonitor.conf

# 2. Clear the sniffer's manager socket for the restore process
# This ensures clean communication with the sniffer
rm -f /tmp/vmsck

# 3. Start the sniffer in restore mode
# The sniffer will read all PCAP files from the spool directory
# and regenerate CDR records in the new database
voipmonitor --config-file /etc/voipmonitor.conf --readpcapdir /var/spool/voipmonitor

Note: The --readpcapdir parameter instructs the sniffer to process all PCAP files in the specified directory. This may take considerable time depending on the amount of historical data.

Step 7: Monitor the Restore Process

Monitor the restore progress:

# Monitor sniffer output for progress
journalctl -u voipmonitor -f

# Alternatively, check the database for new CDR records
mysql -u root -p voipmonitor -e "SELECT COUNT(*) FROM cdr;"

Step 8: Restart Normal Service

Once the restore is complete, restart the sniffer in normal operation mode:

# Stop the restore process (Ctrl+C if running manually)
# Then start the normal sniffer service
systemctl start voipmonitor

# Verify the sniffer is running and capturing
systemctl status voipmonitor

# Test Web GUI access
# Navigate to http://your-server/ in your browser

Prevention: Database Backup Strategies

To avoid future data loss due to database corruption:

Automatic Filesystem Backup

Configure regular backups of the MySQL data directory:

# Example: Daily backup using cron
0 2 * * * /usr/bin/rsync -av --delete /var/lib/mysql/ /backup/mysql-$(date +\%Y\%m\%d)/

MySQL Replication

Set up MySQL master-slave replication for redundancy:

• See the Mysql_master-slave_replication_hints guide for detailed instructions
• This provides a real-time backup database that can be promoted if corruption occurs

VoIPmonitor Database Replication

Use VoIPmonitor's built-in database backup mode (Redundant_database):

• This replicates CDR data to a secondary database server
• No traditional MySQL replication required
• Useful for GUI migrations and disaster recovery

RRD Graph Errors After Hardware Upgrades

After a hardware upgrade or system migration, RRD (Round Robin Database) graphs in the VoIPmonitor GUI may display errors indicating that Data Sources (DS) are missing from RRD files. This occurs because RRD files are created with a specific hardware-dependent schema that may become incompatible after system changes.

Symptoms

• RRD graphs in the Web GUI show display errors instead of rendering data
• Error message: ERROR: No DS called '...' in '/var/spool/voipmonitor/rrd/..."'
• Example: ERROR: No DS called 'SQLq-SM' in '/var/spool/voipmonitor/rrd/3db-SQL.rrd'
• The error appears after hardware upgrades, CPU changes, or system migrations
• Multiple RRD files may be affected, affecting various graph types

RRD File Location

RRD files are stored in the RRD directory within the VoIPmonitor spool directory:

/var/spool/voipmonitor/rrd/

Root Cause

RRD (Round Robin Database) files contain time-series data with a schema defined at creation time. Some data sources in RRD files are hardware-specific (e.g., CPU metrics tied to specific CPU identifiers). When hardware changes, the schema information stored in the RRD files may no longer match the current system configuration, resulting in missing Data Source (DS) errors.

Solution: Delete Corrupted RRD Files

The VoIPmonitor service will automatically recreate RRD files with the correct schema if they are missing. This is a safe operation because:

• New RRD files will be created with the current hardware's correct schema
• Historical RRD data is typically short-term (graph display purposes only)
• CDR data and call recordings are stored separately and are not affected

Step 1: Stop the VoIPmonitor Service

Stop the voipmonitor service to prevent file access conflicts:

systemctl stop voipmonitor

Step 2: Remove Corrupted RRD Files

Delete the affected RRD files from the RRD directory. You can remove individual problematic files or the entire RRD directory:

# Option 1: Remove specific corrupted RRD file (recommended)
rm /var/spool/voipmonitor/rrd/3db-SQL.rrd

# Option 2: Remove all RRD files if multiple errors exist
rm /var/spool/voipmonitor/rrd/*

Replace 3db-SQL.rrd with the actual filename from the error message.

Step 3: Start the VoIPmonitor Service

Start the voipmonitor service to recreate the RRD files:

systemctl start voipmonitor

The service will automatically detect the missing RRD files and recreate them with the correct schema based on the current hardware configuration. New graph data will begin accumulating immediately.

Step 4: Verify RRD Graphs

Check the Web GUI to verify that RRD graphs are now displaying correctly:

• Navigate to the VoIPmonitor Web GUI
• Access dashboard or reporting pages with RRD graphs
• Verify that graphs render without errors
• Note: Historical data in the affected RRD files will be lost, but new data will start appearing

Rerunning with Different Hardware

If you need to preserve RRD data when moving to different hardware (for example, testing on a different machine), consider these options:

• Don't copy RRD files - Let the new system create fresh RRD files with appropriate schemas
• Use rrdtool dump/restore - For advanced users, you can modify RRD file contents using rrdtool export/import tools
• Accept data loss - RRD data is typically short-term monitoring data, not critical call records

Related Information

• RRD files are separate from CDR data (cdr table in MySQL) and PCAP recordings
• The VoIPmonitor spooldir location is configurable in /etc/voipmonitor.conf
• RRD files are automatically created by the sniffer service when needed

IonCube Loader Issues

The VoIPmonitor GUI is protected with IonCube, which requires proper PHP configuration. Common issues include permission errors on temporary directories and security module interference.

Unable to create lock file / temp directory not writable

If you see errors like "Unable to create lock file" or "System temp directory check fails... not writable" from IonCube Loader, follow these troubleshooting steps:

Step 1: Update the system and restart

First, ensure your system packages are up to date:

# Debian/Ubuntu
sudo apt update && sudo apt upgrade -y

# RHEL/CentOS/AlmaLinux
sudo yum update -y
# or
sudo dnf update -y

# Then restart the server
sudo reboot

Step 2: Check SELinux or AppArmor

Security modules like SELinux (default on RHEL/CentOS/Red Hat systems) or AppArmor (default on Ubuntu/Debian) can block IonCube from accessing temporary directories.

Check if SELinux is enabled:

# Check current status
getenforce

# Common values: Enforcing (active), Permissive (logging only), Disabled

# To temporarily disable SELinux for testing:
sudo setenforce 0

If disabling SELinux resolves the issue, you can permanently configure it:

# Edit the SELinux configuration file
sudo nano /etc/selinux/config

# Change SELINUX= to either:
# SELINUX=permissive
# or
# SELINUX=disabled

# Then reboot the server
sudo reboot

Check if AppArmor is enabled:

# Check AppArmor status
sudo aa-status

# If AppArmor is running, temporarily disable individual profiles:
sudo aa-disable /etc/apparmor.d/*php*

# Or disable it entirely for testing:
sudo systemctl stop apparmor
sudo systemctl disable apparmor

Step 3: Check systemd PrivateTmp

Some systemd service configurations use PrivateTmp=true, which creates a private temporary directory for each service. This can cause issues if the private tmp directory has restrictive permissions.

Check if your web server is using PrivateTmp:

# For Apache
systemctl show httpd | grep PrivateTmp
# or
systemctl show apache2 | grep PrivateTmp

# For PHP-FPM
systemctl show php-fpm | grep PrivateTmp

If PrivateTmp is enabled (value=1), disable it in the service file:

# Create override directory if it doesn't exist
sudo mkdir -p /etc/systemd/system/httpd.service.d

# Create override file
sudo nano /etc/systemd/system/httpd.service.d/privatetmp.conf

Add the following content:

[Service]
PrivateTmp=false

Then reload and restart:

# Reload systemd and restart the service
sudo systemctl daemon-reload
sudo systemctl restart httpd
# or
sudo systemctl restart apache2

Step 4: Verify PHP Temporary Directory Configuration

Check which temporary directory PHP is using:

Create a PHP info file:

echo '<?php phpinfo(); ?>' > /var/www/html/info.php

Visit http://your-server-ip/info.php in your browser and search for:

• upload_tmp_dir
• sys_get_temp_dir
• session.save_path

Ensure these directories are writable by the web server user:

# Check ownership
ls -ld /tmp

# Fix ownership if needed
sudo chown www-data:www-data /tmp  # Debian/Ubuntu
# or
sudo chown apache:apache /tmp      # CentOS/RHEL

# Fix permissions
sudo chmod 1777 /tmp

Important: Clean up after troubleshooting:

rm /var/www/html/info.php

Step 5: Check open_basedir restrictions

If the above steps don't resolve the issue, check if PHP's open_basedir is restricting access to the temp directory:

# Check open_basedir in php.ini
grep open_basedir /etc/php/*/apache2/php.ini
# or
grep open_basedir /etc/php.ini

Ensure the temp directory is included in the list, e.g.:

open_basedir = /var/www/html:/tmp:/var/tmp

Alternative: MySQL General Log

If you need a persistent server-side log of all database queries (not just from the GUI), you can enable the MySQL general log:

-- Enable general log
SET GLOBAL general_log = 'ON';

-- Perform actions in the GUI...

-- Disable when done (important for performance)
SET GLOBAL general_log = 'OFF';

The log file location is typically /var/lib/mysql/hostname.log or as defined in your MySQL configuration.

Warning: The general log can grow very quickly on a busy system. Always disable it after debugging.

AI Summary for RAG

Summary: This page covers GUI troubleshooting techniques including debug mode activation, MySQL/MariaDB database corruption restoration from PCAP files, RRD graph errors after hardware upgrades (No DS errors in RRD files), upgrade issues (blank screen with JavaScript errors, conflicting constants.php file), and IonCube Loader problems with temp directory permissions, SELinux, AppArmor, and systemd PrivateTmp.

Keywords: GUI troubleshooting, debug mode, MySQL corruption, MariaDB corruption, database restore, PCAP restore, CDR restore, RRD graphs, RRD error, Round Robin Database, hardware upgrade, No DS called, delete RRD files, systemctl stop voipmonitor, IonCube, SELinux, AppArmor, PrivateTmp, temporary directory, permissions, open_basedir, upgrade issues, blank screen, JavaScript errors, constants.php, PEAR, ReferenceError

Key Questions:

• How do I enable debug mode in the GUI to see SQL queries?
• What should I do if the MySQL/MariaDB database is corrupted?
• How do I restore CDR data from PCAP files after database corruption?
• RRD graphs show error "No DS called 'SQLq-SM'" after hardware upgrade - how do I fix it?
• How do I fix RRD graph errors appearing after system migration or CPU change?
• Can I delete RRD files and will voipmonitor recreate them automatically?
• Where are VoIPmonitor RRD files stored?
• How do I fix "Unable to create lock file" errors from IonCube Loader?
• How do I check if SELinux or AppArmor is blocking the GUI?
• What is systemd PrivateTmp and how does it affect the GUI?
• Why is my GUI showing a blank screen with JavaScript ReferenceError after an update?
• How do I fix ReferenceError: _AuditActivity_download_wav is not defined?