Overview
You may find the MGR GUI not working correctly when the MGR is up and running. You could also see
Not Found The requested URL was not found on this server.
This article provides information on possible root causes of this issue, how to confirm whether this article applies, and the steps to resolve it.
Important: This article applies only when the node is expected to be serving the MGR GUI, which means the node is operating as the master/active MGR. In a multi-MGR setup, a slave/standby MGR is not expected to run the local MGR GUI / Apache service. On a slave/standby node, the absence of local listeners on ports 80 and 443, or the absence of the local MGR Apache process, is not by itself a fault.
Root Cause
- This issue is usually caused by a dead MGR subprocess.
- This issue could also be caused by the Apache HTTP server's ability to bind to a socket:
Diagnosis
Before using the checks below, first confirm that the node is intended to be the master/active MGR.
In a multi-MGR configuration:
- the master/active MGR is expected to provide the local MGR GUI service
- the slave/standby MGR is not expected to provide the local MGR GUI service
If the node is intended to be the master/active MGR, follow the steps below to confirm whether the issue is caused by a dead MGR subprocess or by Apache failing to bind to its sockets.
If the node is intended to be the slave/standby MGR, do not treat missing local Apache listeners on ports 80 and 443 as evidence of a problem by themselves. Instead, confirm the node’s role before proceeding with GUI-specific troubleshooting.
- Run the following command as the root user:
systemctl status mgr
- Check if the MGR status is inactive (dead). Please see the example output below.
mgr.service - MGR - An OAM element Loaded: loaded (/etc/systemd/system/mgr.service; enabled; vendor preset: disabled) Active: inactive (dead) since Thu 2020-02-20 09:55:29 CET; 1 weeks 4 days ago Process: 19153 ExecStop=/usr/TextPass/bin/tp_mgr_stop (code=exited, status=0/SUCCESS) Process: 20045 ExecStart=/usr/TextPass/bin/tp_mgr_start (code=exited, status=0/SUCCESS) Process: 20031 ExecStartPre=/usr/TextPass/bin/tp_mgr_stop (code=exited, status=0/SUCCESS) Main PID: 20086 (code=exited, status=0/SUCCESS)
If the inactive (dead) status is shown despite the MGR being active, there is a dead subprocess. Please continue with the resolution by following the steps provided in the next section.
- Check the output logs in the result of the status check
Oct 03 07:10:33 vlielandvm1 tp_mgr_stop[7293]: All processes finished. Oct 03 07:10:33 vlielandvm1 tp_mgr_start[7309]: Starting with clean XML cache Oct 03 07:10:35 vlielandvm1 tp_mgr_start[7309]: No peerfserver defined in '/...' Oct 03 07:10:35 vlielandvm1 tp_mgr_start[7309]: Continuing as stand-alone Master Oct 03 07:10:48 vlielandvm1 tp_mgr_start[7309]: (98)Address already in use: ...0 Oct 03 07:10:48 vlielandvm1 tp_mgr_start[7309]: (98)Address already in use: ...0 Oct 03 07:10:48 vlielandvm1 tp_mgr_start[7309]: no listening sockets availab...n Oct 03 07:10:48 vlielandvm1 tp_mgr_start[7309]: AH00015: Unable to open logs Oct 03 07:10:48 vlielandvm1 tp_mgr_start[7309]: Could not start apache with .... Oct 03 07:10:48 vlielandvm1 systemd[1]: Started MGR - An OAM element.
Resolution
- Stop all the MGR processes by running the following command as the root user:
/usr/TextPass/bin/tp_mgr_stop
- Wait for the "All processes finished" message, which indicates that all the processes are shut down.
- Restart the MGR service and all the subprocesses by executing the following command:
systemctl start mgr
- If this node is intended to be the master/active MGR and you still see errors regarding "Address already in use", perform the steps below as the root user.
Do not use the checks below for a slave/standby MGR node, because a slave/standby node is not expected to run the local MGR GUI / Apache service
-
Identify the Process Using Port 80: You can use the following command to identify the exact process using port 80 (Replace
80with the specific port if different. This will show which process is occupying the port.)lsof -i :80This will show you the process and its PID (process ID) associated with port 80.
-
Stop the Conflicting Process: Once you identify the process from the output of the
lsofcommand, you can stop it by killing the processes or stopping the httpd service:systemctl stop httpd -
Check if Port 80 is Free: After killing the process or stopping the service, rerun the
netstatcommand to verify that port 80 is no longer in use:netstat -tuln | grep :80 -
Restart MGR: Now that port 80 is available, try restarting the MGR service:
systemctl restart mgr - This should allow MGR to bind to port 80 successfully and resolve the "Address already in use" issue.
-
Confirmation
If this node is intended to be the master/active MGR
- Recheck the MGR status by running the following command as the
rootuser:
systemctl status mgr - Check if the MGR status is
active (running). A healthy master/active MGR is expected to show the local MGR Apache process, for example:
mgr.service - MGR - An OAM element Loaded: loaded (/etc/systemd/system/mgr.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2024-10-04 08:02:33 -04; 2 days ago Process: 8180 ExecStop=/usr/TextPass/bin/tp_mgr_stop (code=exited, status=0/SUCCESS) Process: 8222 ExecStart=/usr/TextPass/bin/tp_mgr_start (code=exited, status=0/SUCCESS) Process: 8206 ExecStartPre=/usr/TextPass/bin/tp_mgr_stop (code=exited, status=0/SUCCESS) Main PID: 8271 (/usr/sbin/httpd) CGroup: /textpass_oam.slice/mgr.service ├─ 8271 /usr/sbin/httpd -f /var/TextPass/MGR/conf/MGR.conf -DSSL ├─ 8272 /usr/sbin/rotatelogs /var/TextPass/MGR/logs/mgr_error_log ... ├─ 8374 /usr/sbin/rotatelogs /var/TextPass/MGR/logs/mgr_ssl_reques... ├─13352 /usr/sbin/httpd -f /var/TextPass/MGR/conf/MGR.conf -DSSL └─31529 /usr/sbin/httpd -f /var/TextPass/MGR/conf/MGR.conf -DSSL
- Check if the MGR GUI works properly.
If this node is intended to be the slave/standby MGR
Do not use the presence of local Apache listeners on ports 80 and 443, or the presence of the local MGR Apache process, as the confirmation criteria for this node.
For a slave/standby MGR, the expected checks are:
- confirm the node is operating in the intended slave/standby role
- confirm the master/active MGR is serving the GUI correctly
- if needed, validate the HA role / changeover state using the applicable MGR role procedures
If the node is operating as slave/standby, the absence of local GUI listeners on 80/443 is expected behavior and is not, by itself, evidence of a failure.
Priyanka Bhotika
Comments