IJ33315: WHEN USING THE SCRIPTING FEATURE, THE SCRIPT RESULTS ARE NOT DISPLAYED AND THE FCP_DAEMON IS CONTINUALLY RESTARTED

IBM Tivoli Monitoring 6.3.0 Fix Pack 7 Service Pack 9 (6.3.0.7-TIV-ITM-SP0009)

APAR status

• Closed as program error.

Error description

• Environment:
  Reported Release: 630 FP7 Unix OS agent (could be 6.30 FP4 and
  higher)
  This can potentially also occur for the UNIX, Linux, and Windows
  OS Agents
  
  
  Problem Description:
  When using the Scripting feature, the script results are not
  displayed and the fcp_daemon is continually restarted. This is
  not a common condition and is dependent on the length of data
  returned from the script and the number of attributes.
  
  
  Related Files and Output:
  In the OS Agent RAS1 log, with tracing at ERROR the following
  message is displayed:
  (60CC960D.0000-3C:factorycustomprovidertemplate.cpp,2999,"facto
  ryProviderCPCICheckThread")WARNING: timeout waiting on CPCI requ
  restarting fcp_daemon. Now: '1624020493', previous timeout:
  '1624020493'  (-1 means no timeout)
  
  In the agent RAS1 log with tracing at (UNIT:clientsocket ALL),
  the following message will appear:
  (Wed Jun 16 07:43:56
  2021.007A-5:clientsocket.cpp,290,"ClientSocket::receive") Did
  not find newline, continue reading
  

Local fix

• N/A
  

Problem summary

• When using the Scripting feature, the script results are not
  displayed and the fcp_daemon may be continually restarted.
  
  
  When using the Scripting feature, the script results are not
  displayed and the fcp_daemon is continually restarted.  This is
  not a common condition and is dependent on the length of data
  returned from the script and the number of attributes.  The
  issue can occur on the Monitoring Agent for UNIX OS, Linux OS,
  or Windows OS.
  

Problem conclusion

• The issue occurs when the data combined with the xml tags that
  fcp_daemon returns to the OS Agent reaches a specific length.
  The data ends up being not properly formatted and so the OS
  Agent believes the fcp_daemon is not responsive so it might try
  to restart the daemon.   The code has been updated to address
  the issue.
  
  
  The fix for this APAR is contained in the following maintenance
  packages:
  
     | service pack | 6.3.0.7-TIV-ITM-SP0009
  

Temporary fix

• Modify the script to return slightly more or less data.
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  ITM AGENT UNIX

• Fixed component ID

  5724C040U

Applicable component levels