XCOM for Linux xcomd stop/start does not stop/start the listener ports
Article ID: 276177
Updated On:
Products
Issue/Introduction
When the XCOM for Linux daemon xcomd has been stopped it is noticed that the listeners ports 8044, 8045, 8046, 8047 remain active and are owned by the xinetd process.
Does the xcomd not control the stop/start of the listeners when it itself is stopped/started?
Environment
XCOM Data Transport for Linux
Releases: 11.6, 12.0
Resolution
The behaviour is working as designed and XCOM under UNIX or Linux has always used the relevant internet daemon (inetd or xinetd) to control the starting/stopping of its listener ports (typically at machine startup/shutdown).
In the original design, when the xcomd is started and stopped it was probably decided it was not feasible/sensible for it to issue any commands to the xinetd daemon to specifically start/stop just the XCOM listeners because that would require dynamically changing each of the 4 txpi* files in directory /etc/xinetd.d. For example to stop a listener the file would have to have the line "disable = no" changed to "disable = yes" and a reload of xinetd (systemctl reload xinetd) would be needed. Although a reload should not impact the existing xinetd process and other internet services the fact that those txpi* files are being changed could cause problems if they have been deliberately manually changed to have some services permanently disabled. When xcomd starts and needs to change "disable = no" to "disable = yes" it would not know what was an automated change or a manual change.
XCOM Engineering also advised that additional problems caused by changing txpi definitions would also include the possibility of issuing xcomd stop commands simultaneously from multiple sessions which can corrupt txpi text files.
In PTF LU11905 Engineering made changes for the XCOM 12.0 support of RHEL 9 where the xinetd is no longer provided with the OS (deprecated in RHEL 8).
The XCOM listener services are redefined to be under systemd, but there is no fundamental change in behaviour i.e. the port management remains independent and they remain in the same state.
However, if xcomd is enabled as a Linux systemd service for automated startup/shutdown at machine startup/shutdown (How to enable automatic startup of Xcom on Linux at system restart) then that service could be capable of running a script with multiple commands when that service is started/stopped.
With the systemd style of RHEL 9, it is possible to start/stop each txpi service independently.
For example, the command "systemctl stop txpis.socket" will stop the txpis service and port 8045.
So potentially the defined xcomd service file could be enhanced to include these additional commands as required when stopping/starting xcomd using systemctl.
Additional Information
NOTE: This architecture is different to XCOM for Windows where there is a different level of control i.e. the xcomd.exe (service name xcomdsrv) runs its own listener program caxcgsvr.exe and start/stop of the xcomd automatically starts/stops the listener.
Doc. references:
XCOM Data Transport for UNIX/Linux 11.6 > Reference > Operating Environment > Remote Session Control Parameters
XCOM Data Transport for UNIX/Linux 12.0 > Installing > Complete Configuration Tasks > Configure the Listener Services
Feedback
