XCOM ports not in LISTEN state after xinetd is started
search cancel

XCOM ports not in LISTEN state after xinetd is started

book

Article ID: 264780

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC

Issue/Introduction

Completed an XCOM installation on new Linux RHEL 8 server and able to transfer files from the server to other XCOM servers.

However when try to transfer from other servers to the new Linux RHEL 8 server seeing below error:

#XCOMU0298E Unable to allocate remote transaction program: Txpi  211: Socket connect error return value = 111

The XCOM ports are not in a LISTEN state after starting xinetd i.e. this command returns no information:
ss -tlnp | grep 804 | grep LISTEN

Environment

XCOM™ Data Transport® for Linux PC

Cause

The reason why xinetd could not start the XCOM ports was found in the /var/log/messages file. In this case xinetd received the following message when it started:

SELinux is preventing /usr/sbin/xinetd from search access on the directory /etc/xinetd.d/txpi

         SELinux is preventing /usr/sbin/xinetd from search access on the directory /etc/xinetd.d/txpis

         SELinux is preventing /usr/sbin/xinetd from search access on the directory /etc/xinetd.d/txpi6

         SELinux is preventing /usr/sbin/xinetd from search access on the directory /etc/xinetd.d/txpi6s

In addition to other messages.

Resolution

In this case xinetd needed the proper access/permission in order to read the /etc/xinetd.d directory.
That is the directory that contains tsymbolic links to the $XCOM_HOME/txpi* files that xinetd needs in order to start the XCOM ports.
Access need to be requested via the Linux/Unix Security Administrator.

Once that is corrected, the xinetd service needs to be restarted using command: systemctl restart xinetd

Issue the following command to check if the XCOM 804* ports are in a LISTEN state:  ss -tlnp | grep 804 | grep LISTEN

Additional Information

1. This problem has also been reported when the symbolic link for /usr/lib/xcom/xcomtcp was missing because each txp* file references /usr/lib/xcom/xcomtcp.  
After checking /var/log/messages it showed this type of message:
... xinetd[214022]: Server /usr/lib/xcom/xcomtcp is not executable [file=/etc/xinetd.d/txpi] [line=16]
... xinetd[214022]: Error parsing attribute server - DISABLING SERVICE [file=/etc/xinetd.d/txpi] [line=16]

In this case the XCOM installation had become corrupted and these symbolic links needed to be restored to the /usr/lib/xcom directory:
# ls -l /usr/lib/xcom
total 0
lrwxrwxrwx. 1 root root 24 Oct  2 15:05 xcomend -> /opt/CA/XCOM/cmd/xcomend
lrwxrwxrwx. 1 root root 23 Oct  2 15:06 xcomlp -> /opt/CA/XCOM/cmd/xcomlp
lrwxrwxrwx. 1 root root 25 Oct  2 15:06 xcomntfy -> /opt/CA/XCOM/cmd/xcomntfy
lrwxrwxrwx. 1 root root 23 Oct  2 15:06 xcompp -> /opt/CA/XCOM/cmd/xcompp
lrwxrwxrwx. 1 root root 24 Oct  2 15:06 xcompre -> /opt/CA/XCOM/cmd/xcompre
lrwxrwxrwx. 1 root root 24 Oct  2 15:24 xcomtcp -> /opt/CA/XCOM/bin/xcomtcp

2. Other things that can be checked for this particular problem: