Bug #17097
openWireGuard page incorrectly displays "The WireGuard service is not running" when service is fully operational
0%
Description
pfSense Version: 2.9.0 (Upgraded from 2.8.1, issue originally observed since 2.7.2)
Description:
Navigating to Status > WireGuard shows a red banner at the top of the page:
The WireGuard service is not running.
This issue has persisted across versions, present since pfSense 2.7.2, continuing through 2.8.1, and still existing on 2.9.0.
Despite the warning message, all WireGuard tunnels and peers listed below the banner are active and working properly. Latest handshakes continue to update, endpoints remain connected, and traffic counters (RX/TX) increase normally.
The status check logic (e.g., is_service_running('wireguard') or the daemon status checking routine called by status_wireguard.php) incorrectly returns false while the underlying WireGuard module/daemon is fully operational.
Steps to Reproduce:
Configure and enable WireGuard on pfSense 2.7.2, 2.8.1, or 2.9.0.
Ensure WireGuard tunnels and peers are active, connected, and passing traffic.
Navigate to Status > WireGuard (or /status_wireguard.php).
Observe the banner warning stating that the WireGuard service is not running.
Expected Behavior:
The banner "The WireGuard service is not running" should NOT appear when the WireGuard service is active and tunnels/peers are actively communicating.
Actual Behavior:
The top banner displays The WireGuard service is not running, contradicting the active status, active handshakes, and traffic statistics shown in the status table directly below.
Files
HZ Updated by hao zhang 1 day ago
Issue Replication & Lifecycle Bug Confirmation:
Testing confirmed the following behavior:
Manually removing /var/run/wireguardd.pid and clicking Start Service (Play button in WebGUI) restores normal status: the "not running" error banner disappears.
However, clicking Start Service re-creates /var/run/wireguardd.pid.
Once the initial start process/script completes, the PID file is left stale on disk without an active flock or running owner process.
Subsequent page reloads call wg_is_service_running(), which successfully obtains a lock on the leftover /var/run/wireguardd.pid, evaluating $not_running = true and throwing the false "The WireGuard service is not running" error.
Resolution path for developers:
Either ensure the process responsible for /var/run/wireguardd.pid properly cleans up (unlink) the PID file upon termination,
Or refactor wg_is_service_running() to check active kernel interfaces (tun_wg*) rather than relying on ephemeral PID file locks.
HZ Updated by hao zhang 1 day ago
The issue was resolved with two changes to /usr/local/pkg/wireguard/includes/wg_service.inc.
The WireGuard PID did not exist, but fstat /var/run/wireguardd.pid showed multiple dpinger processes holding the PID file open. WireGuard reported “already running” despite having no running daemon, consistent with an inherited lock causing a false positive in wg_is_service_running().
1. Prevent PID file descriptor inheritance across exec
In wg_register_service_env(), change:
if ($h_lock = fopen($wgg['pid_path'], 'a+')) {
to:
if ($h_lock = fopen($wgg['pid_path'], 'a+e')) {
The e flag sets close-on-exec, preventing external programs such as dpinger from inheriting the descriptor.
2. Clean up the temporary PID file and lock after early-boot initialization
In wg_service_cli_start(), add wg_deregister_service_env() before returning from the boot-time branch:
if (is_platform_booting()) {
unmute_kernel_msgs();
fwrite(STDERR, "{$s(gettext('done.'))}\n");
wg_deregister_service_env();
return $ret_code;
}
This branch only creates the tunnels and exits; it does not enter the persistent daemon loop.
These changes resolved the issue on my system running pfSense CE 2.9.0-RELEASE with WireGuard 0.2.13_4.