XCOM 12.0 systemd listener services do not auto start after a server restart

Products

• XCOM Data Transport
• XCOM Data Transport - Linux PC

Issue/Introduction

Under Red Hat 9 (RHEL9) and later versions the XCOM listener services run under systemd.
Those services are created by PTF LU11905 or later PTF per XCOM Data Transport for UNIX/Linux 12.0 > Release Notes > New Features, section "New txpi Services for systemd on Red Hat 9 and SUSE 15 SP03 (LU11905)"

Each service 3 symbolic links are created to files in directory /opt/CA/XCOM/txpi e.g. txpi.socket (port 8044) has:

/etc/systemd/system/txpi.socket -> /opt/CA/XCOM/txpi/txpi.socket 
/etc/systemd/system/[email protected] -> /opt/CA/XCOM/txpi/[email protected] 
/etc/systemd/system/sockets.target.wants/txpi.socket -> /opt/CA/XCOM/txpi/txpi.socket 

It has been reported that for some servers the systemd listener services do not automatically start after a server restart/reboot and they need to be manually started.

Environment

XCOM™ Data Transport® for Linux 12.0

Cause

It has been determined that the problem only occurs when /opt is mounted as separate file system to / and is not mounted when system tries to start the services. The var/log/messages file will show this at boot time:

*****
Dec 31 11:33:54 xcom_server systemd: txpis6.socket: Failed to open /etc/systemd/system/txpis6.socket: No such file or directory
Dec 31 11:33:54 xcom_server systemd: txpis.socket: Failed to open /etc/systemd/system/txpis.socket: No such file or directory
Dec 31 11:33:54 xcom_server systemd: txpi6.socket: Failed to open /etc/systemd/system/txpi6.socket: No such file or directory
Dec 31 11:33:54 xcom_server systemd: txpi.socket: Failed to open /etc/systemd/system/txpi.socket: No such file or directory
...
...

Dec 31 11:33:54 xcom_server systemd[1]: Mounting /opt...
...
Dec 31 11:33:54 xcom_server systemd[1]: Mounted /opt.
*****

Resolution

Workaround

Replace the 2 symbolic links in directory /etc/systemd/system with actual copies of the files from the /opt/CA/XCOM/txpi directory

Example steps to do this for txpi.socket (port 8044) are below:

1. 
   # systemctl stop txpi.socket

# netstat -na|grep 804
tcp        0      0 0.0.0.0:8045            0.0.0.0:*               LISTEN
tcp6       0      0 :::8047                 :::*                    LISTEN
tcp6       0      0 :::8046                 :::*                    LISTEN

# systemctl disable txpi.socket
Removed "/etc/systemd/system/sockets.target.wants/txpi.socket".

# unlink /etc/systemd/system/txpi.socket

# unlink /etc/systemd/system/[email protected]

# cp -a /opt/CA/XCOM/txpi/txpi.socket /etc/systemd/system/txpi.socket

# cp -a /opt/CA/XCOM/txpi/[email protected] /etc/systemd/system/[email protected]

# systemctl daemon-reload

# systemctl enable txpi.socket
Created symlink /etc/systemd/system/sockets.target.wants/txpi.socket → /etc/systemd/system/txpi.socket.

# netstat -na|grep 804
tcp        0      0 0.0.0.0:8045            0.0.0.0:*               LISTEN
tcp6       0      0 :::8046                 :::*                    LISTEN
tcp6       0      0 :::8047                 :::*                    LISTEN

# systemctl start txpi.socket

# netstat -na|grep 804
tcp        0      0 0.0.0.0:8044            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8045            0.0.0.0:*               LISTEN
tcp6       0      0 :::8046                 :::*                    LISTEN
tcp6       0      0 :::8047                 :::*                    LISTEN
   
   
2. Test an XCOM loopback transfer on the server.
   
   
   
3. Repeat the process for the other 3 services ports as required.
   
   
   
4. Reboot server to confirm XCOM ports are listening after reboot using the commands:
   # systemctl status txpi.socket
# netstat -na|grep 804

 

Resolution

February 2026: XCOM Engineering are researching this problem and will look at providing a future resolution.