GUI troubleshooting

From VoIPmonitor.org
Revision as of 19:19, 4 January 2026 by Admin (talk | contribs) (Improve formatting, add database restore workflow diagram, fix PrivateTmp section to use systemd override, fix /tmp permissions (sticky bit), improve AI RAG section)


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:

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

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, 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, 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?
  • 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?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=GUI_troubleshooting&oldid=6571"