IT26853: AFTER SYSTEM RESTART THE /VAR/RUN/DSMSERV_TSMINST1.PID CAN HAVE A STALE DSMSERV PROCESS ID.

8.1.7.000-IBM-SPSRV-Linuxppc64le
8.1.7.000-IBM-SPCMS-WindowsX64
8.1.7.000-IBM-SPCMS-WindowsI32
8.1.7.000-IBM-SPCMS-Linuxx86_64
8.1.7.000-IBM-SPOC-WindowsX64
8.1.7.000-IBM-SPOC-Linuxx86_64
8.1.7.000-IBM-SPOC-Linuxs390x
8.1.7.000-IBM-SPOC-LinuxPPC64le
8.1.7.000-IBM-SPOC-AIX
8.1.7.000-IBM-SPSRV-WindowsX64
8.1.7.000-IBM-SPSRV-Linuxx86_64
8.1.7.000-IBM-SPSRV-Linuxs390x
8.1.7.000-IBM-SPSRV-AIX
IBM Spectrum Protect Server V8.1 Fix Pack 7 (V8.1.7) Downloads

APAR status

• Closed as program error.

Error description

• After system restart the /var/run/dsmserv_tsminst1.pid can have
  a stale dsmserv process id.
  
  If Spectrum Protect is stopped with either HALT or using
  "service" or "systemctl" commands and then restarted with
  "service" or "systemctl" commands then all works fine - the
  "new" PID = Process ID is in the dsmserv_tsminst1.pid  file.  If
  the system is shutdown in such a way that the IBM Spectrum
  Protect server cannot halt in an orderly manner then the problem
  can occur.
  
  Customer/L2 Diagnostics (if applicable)
  
  Dsmserv.rc gets the server's PID from the file
  $instance_dir/dsmserv.v6lock.  This file is created by the IBM
  Spectrum Protect server during initialization, and is deleted
  when the server halts.  If the server crashes, or  the system is
  shutdown in such a way that the server cannot halt in an orderly
  manner, then the file will be left behind.  The next time the
  server starts it will overwrite the previous contents with the
  new PID, but if it takes more than 5 seconds to start up and
  rewrite the v6lock file, then the startup script will end up
  using stale information written by the previous process, and
  store that in the pid file in /var/run.
  
  *NOTE*
  - This was seen on Suse 12 with IBM Spectrum Protect 8.1.6.0
  - The script uses the contents of the PID file to tell which
  process should be killed when shutting down.  So having a stale
  value in the file will likely prevent something like "systemctl
  stop tsminst1" from working.
  
  
  Platforms affected:
  Linux 7.1, 8.1
  
  Initial Impact: Low
  

Local fix

• 1) Change the /etc/init.d/tsminst1 startup script to use sleep
  60 (default uses sleep 5)
       Note: When setting up an instance to start automatically,
  a customized version of the dsmserv.rc is copied into an
  instance-specific file in /etc/init.d, For example
  /etc/init.d/tsminst1 for instance tsminst1 or
  /etc/init.d/tsminst2 for instance tsminst2.   The customized
  versions of dsmserv.rc in /etc/init.d is the startup script to
  change.
  
  or
  2) Halt the Spectrum Protect Server before a planned system
  restart.   This local fix does not correct the problem in the
  event of an unexpected shutdown/crash.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All IBM Spectrum Protect server users.                       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See error description.                                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply fixing level when available. This problem is currently *
  * projected to be fixed in level 8.1.7. Note that this is      *
  * subject to change at the discretion of IBM.                  *
  ****************************************************************
  

Problem conclusion

• This problem was fixed.
  Affected platforms for reported release:  Linux.
  Platforms fixed:  Linux.
  

Temporary fix

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

  TSM SERVER

• Fixed component ID

  5698ISMSV

Applicable component levels