PM15424: SENDMAIL NOT DELIVERING MAIL WHEN INVOKED FROM A OSHELL BATCH JOB

APAR status

• Closed as fixed if next.

Error description

• Sendmail is invoked from an OSHELL batch job using
  /usr/sbin/sendmail.  The default config for sendmail uses a
  devliverymode of background.  This causes sendmail to do some
  processing and then fork a sendmail child to deliver the email.
  Then the parent task ends and the OSHELL job ends.  There is a
  timing window where if the OSHELL job ends before the sendmail
  child task is able to deliver an email, a SIGHUP is sent to thec
  child task causing it to end.  The child task needs to be
  changed to ignore the SIGHUP signal.
  .
  KEYWORDS: sendmail missing delivery deliver delivered lost
  .
  VERIFICATION STEPS:
  Look at the messages written to SYSLOGD.  It will show a
  sendmail message with from= information but not to= informaiton
  (this line indicates sendmail delivered the mail).
  .
  If you set LogLevel=80 in /etc/mail/sendmail.cf and invoke
  sendmail, you will see a sendmail message with the word
  interrupt.
  

Local fix

• There are multiple work arounds for this issue.
  1) In the batch job, add a sleep command after sendmail is
     invoked.  This will cause the batch job to stay around long
     enough for the sendmail child task to deliver the email
  2) Invoke sendmail using
     oshell exec nohup /usr/sbin/sendmail
     This causes sendmail to ignore the sighup signal
  3) Invoke sendmail using -v.  This causes sendmail not fork the
     child task and deliver the email under the original task.
  4) Invoke sendmail using a BPXBATCH job instead of OSHELL.
     An example of this is:
     //SENDMAIL EXEC PGM=BPXBATCH,REGION=30M,TIME=NOLIMIT
     //STDOUT   DD SYSOUT=*
     //STDERR   DD SYSOUT=*
     //STDPARM  DD *
     SH /usr/sbin/sendmail user@hostname </tmp/file
     .
     Note, if you need more room, just continue the command
     on the next line
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release(s) 10, 11, and    *
  *                 12 IP: Sendmail                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Due to a timing window, sendmail may    *
  *                      not be able to deliver the email        *
  *                      message before receiving a SIGHUP       *
  *                      signal from the parent task.            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Sendmail is invoked from an OSHELL batch job using
  /usr/sbin/sendmail.  The default config for sendmail uses a
  devliverymode of background.  This causes sendmail to do some
  processing and then fork a sendmail child to deliver the email.
  When the OSHELL job ends before the sendmail child task is able
  to deliver an email, a SIGHUP is sent to the child task to end
  as well.  So the email is not delivered.
  
  This appears to be a small timing window which can be easily
  circumvented by the invocation method used.
  +-------------------------------------------------------------+
  + Please check our Communications Server for OS/390 homepages +
  + for common networking tips and fixes.  The URL for these    +
  + homepages can be found in Informational APAR II11334.       +
  +-------------------------------------------------------------+
  

Problem conclusion

Temporary fix

Comments

• This APAR is being closed FIN (Fixed If Next) with concurrence
  from the submitting customer. This means that a fix to this
  APAR is expected to be delivered from IBM in a release (if any)
  to be available within the next 24 months.
  
  This problem will be tracked as Feature F151137
  by Communications Server for z/OS Development.
  
  The solution for this APAR is included in CS for z/OS Version 1
  Release 13.
  

APAR Information

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

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

Fix information

Applicable component levels

• R1A0 PSN

     UP

• R1B0 PSN

     UP

• R1C0 PSN

     UP