I’m working on upgrading an old Pritunl cluster from CentOS7 to Alma9, which is actively hosting our enterprise users.
We have less than 10 hosts on centos7 including a dedicated web console across various aws regions (Pritunl v1.30.3343.47), and I’ve added an Alma9 host to the cluster with upgraded Pritunl version (v1.34.4681.89) to attempt to start a process of upgrading OSes with no downtime to the user.
However, this new node is restarting every hour and will not accept new user connections, even though I have successfully granted the node access via IP to the mongodb, and a command like pritunl logs shows logs from other hosts across the cluster. All hosts are served via a single public IP hostname and live within the same local IP space.
The restart looks like:
[INFO] Starting server
version = "1.34.4681.89"
python_version = "3.12.13 (main, Jul 8 2026, 12:24:28) [GCC 11.5.0 20240719 (Red Hat 11.5.0-14)]"
ssl_version = "OpenSSL 3.5.5 27 Jan 2026"
selinux_context = "system_u:system_r:unconfined_service_t:s0"
web_auth_strict = true
Any pointers in the right direction would be greatly appreciated as I’m not quite seeing anything relevant in the docs. Please let me know if I can provide more context.
Thanks in advance!
Is the entire host rebooting every hour or just the Pritunl process? Check the events at the end of the previous shutdown sudo journalctl -b -1 -n 200 --no-pager. Run sudo dmesg -Tkw check for out of memory errors. Run sudo journalctl -n 200 -p warning..emerg and check for recent errors.
Thanks for the response Zach - it was just the process dying from OOM, which is no longer happening as I have added a respective Route53 healthcheck, which I believe was the root solution to cutting down on those repeated failed attempts; I do not have any to paste as they’re gone with a reboot.
However, I am now seeing repeated 404s on the vpn_healthcheck.service which disallows a successful Route53 check, confirmed by curl -i http://127.0.0.1:<port redacted>/
HTTP/1.0 404 Not Found
Server: SimpleHTTP/0.6 Python/3.9.25
Date: Wed, 16 Sep 2026 22:35:29 GMT
Content-type: text/html
while sudo ss -lntp | grep ':<port redacted>' show the port still listening:
No openvpn process is running either as no user can connect, so still failing healthcheck in that regard. I’m not sure how to connect directly as a test user to a specific server vs just the pool to try and mitigate this.
I can verify MongoDB connectivity with pritunl logs and though I haven’t had to do anything with licensing or server setup, I may have missed something in that setup process.
I’m pretty new to managing Pritunl and have inherited this quite old cluster so I really appreciate your help thus far.
There should be a pritunl-web process check the output of sudo journalctl -u pritunl-web and sudo systemctl status pritunl-web. This service can’t be manually started, it must be started by the pritunl service during startup which provides the state data for the service. If the Systemd unit isn’t working running sudo pritunl set app.web_systemd false will run the process directly but this reduces the security isolation.
Run sudo netstat -tulpn to find what is using port 443 and stop that service or change the port for the Pritunl web server with the command sudo pritunl set app.server_port 443. This will change the port on all hosts.
Older versions of the software did not use the isolated Systemd unit.
Curious. The web and Pritunl services are definitely in a weird state. Looks like the Pritunl daemon is started and ports 80 and 443 are fine, but then the -web service thinks they’re already in use.
I think I’m going to attempt a reinstall and then check to see whether that port change command will affect the rest of my cluster here. Not sure how the node got into this state really.
I think we can close this one - found old non-Pritunl-related VPNhealthcheck scripting that was causing the OOM rebooting issue and dropping from our Route53 cluster, and a reinstall/reconfig got ports and everything started up correctly.
Now on to testing whether I can actually get users connected. Thanks again Zach.