HP 3000 Manuals

General Troubleshooting Procedures [ Managing HP X.400 Administrator's Guide ] MPE/iX 5.0 Documentation


Managing HP X.400 Administrator's Guide

General Troubleshooting Procedures 

Follow these general troubleshooting procedures before beginning to
troubleshoot for a specific problem:

   1.  Run x4stat to make sure all the components are up and running.

       If a component is not running, start the component.

   2.  Run x4perm to check the attributes of all files.

       If any incorrect permissions or ownerships are fixed, stop and
       restart the components affected by the incorrect permissions.  If
       you are not sure which components are affected, restart the entire
       X.400 system.

       If any problems with links, checksum, size, or version are
       reported, run x4dump and contact your HP Representative.

       If there are no problems with links, checksum, size, or version
       and any problems with permissions or ownership have been fixed,
       try to send a message again.

If you are still having problems sending a message, proceed to the
appropriate section to continue troubleshooting.

HP as Initiator 

The following procedures help trace outgoing messages in order to
determine where a problem is occurring.

Did Not Receive a Non-delivery Notification.   

If you did not receive a non-delivery notification, do the following:

   1.  If you sent a message from OpenMail, refer to the Getting Mail
       from OpenMail to X.400 section in OMSolve (OpenMail's online
       troubleshooting guide) to troubleshoot messages sent from OpenMail
       to the X.400 MTA.

   2.  Scan the x4mout.evnt log file for events logged concerning the
       message sent.  Note the outgoing filename created by x4mailer.
       The following is an example of a logged event:

            ****************************************************************

            08/14-09:07:03 Processing outbound message ... (X4EVENT 413)
                     Subject : test
                     Mpdu-id : US TELEMAIL HP    F102253  650650022B
                     Originator : root///US/TELEMAIL/HP////
                     Recipient : rattlesnake//x25/us/telemail/ibm

            08/14-09:07:04 UMPDU submitted to MTA : (X4EVENT 414)
                     MPDU File [/usr/spool/x400/iq/I0814090703a.000
                     Mpdu-id : US TELEMAIL HP     F102243  650650022B

            ****************************************************************

       The subject of this message is test, the outgoing filename created
       by x4mailer is /usr/spool/x400/iq/I0814090703a.000, and the
       Mpdu-id of the outgoing message is US TELEMAIL HP F102243
       650650022B .

       If there are no events logged for the message, check that x4mailer
       is running, x4mailer event logging is enabled, and that Sendmail
       is configured correctly for X.400 (check /usr/spool/mqueue/syslog
       for more information).

   3.  Using the outgoing filename created by x4mailer, track the message
       by typing:

        x4msgtrack -f I0814090703a.000 -o 2

       Refer to Appendix B for more information on x4msgtrack.

       If the message is not found in the log files, go to step 4.  If
       the message is found in the log files, go to step 5.

   4.  Use x4stat to check that all components are running and the event
       logging is enabled for all X.400 components (MTA, RTS, and
       x4mailer).  If a component is not running, restart it.  If event
       logging is disabled, enable it and send the message again.

   5.  Using the x4msgtrack output, check the MTA events to verify the
       message was sent to the RTS.

   6.  Using the x4msgtrack output, check if the outbound message passed
       through the RTS. If it did not pass through successfully, check
       the RTS event log file for this adjacent MTA. Refer to Appendix A
       in this manual for information on how to determine the name of the
       event log file and the cause and recommended actions for the
       event.

       If the x4msgtrack output indicates that the message is located in
       a local queue, verify that the component that reads from the local
       queue is running.  Also verify how the component is configured to
       handle the message.

       If the component that reads from the queue is not transferring the
       message, check the events logged in that component's event log
       file.  Use x4logview to view any errors and x4solve to retrieve
       causes and recommended actions for these errors.  Refer to
       Appendix A for more information on x4solve.  If the error
       indicates a connection failure at the RTS, refer to the "Testing
       X.400 Interoperability" section of the OSI Planning and 
       Troubleshooting Guide.

   7.  If the outbound message has been transferred to the remote node,
       go to the remote node and check if it generated a non-delivery
       report.

       If the remote node did not generate a non-delivery report, verify
       that the remote system successfully received the message.
       Troubleshoot the remote system for the problem.

       If the remote node generated a non-delivery report, check the RTS
       event log file for this adjacent MTA to see if the non-delivery
       report has arrived (refer to Appendix A in this manual for
       information on how to determine the name of the event log file).
       If the non-delivery report has arrived, run x4msgtrack with the
       incoming filename.  Examine the x4msgtrack output and find out why
       the message did not pass through to Sendmail.

   8.  Check the originator's O/R address of the original message.  This
       address must be specified correctly for the non-delivery
       notification to be delivered.

   9.  If the problem still exists, run x4dump and call your HP
       Representative.

Received a Non-delivery Notification.   

If you received a non-delivery notification, do the following:

   1.  Examine the non-delivery notification and correct any specified
       problems.

       If the notification is from Sendmail, mail an X.400 message to
       yourself.  If you receive the message, verify the recipient's
       address of the original message.  If you did not receive the
       message, verify the configuration in the sendmail.cf file (refer
       to the OSI Planning and Troubleshooting Guide).

       If the notification was from the X.400 network, use x4rtview to
       verify the route.  If the route exists, refer to the "Testing
       X.400 Interoperability" section of the OSI Planning and 
       Troubleshooting Guide.  If the route does not exist, verify that
       the recipient's address is correct and send the message again.  If
       you receive another non-delivery notification, you are not
       configured to send to that recipient.  To configure a route to
       that recipient, refer to the "Configuring Routes and Alternate
       Routes" chapter of the Installing and Configuring HP X.400 manual.

   2.  Scan the x4mout.evnt log file for events logged concerning the
       message sent.  Note the outgoing filename created by x4mailer.
       The following is an example of a logged event:

            ****************************************************************

            08/14-09:07:03 Processing outbound message ... (X4EVENT 413)
                     Subject : test
                     Mpdu-id : US TELEMAIL HP    F102253  650650022B
                     Originator : root///US/TELEMAIL/HP////
                     Recipient : rattlesnake//x25/us/telemail/ibm

            08/14-09:07:04 UMPDU submitted to MTA : (X4EVENT 414)
                     MPDU File [/usr/spool/x400/iq/I0814090703a.000
                     Mpdu-id : US TELEMAIL HP     F102243  650650022B

            ****************************************************************

       The subject of this message is test, the outgoing filename created
       by x4mailer is /usr/spool/x400/iq/I0814090703a.000, and the
       Mpdu-id of the outgoing message is US TELEMAIL HP F102243
       650650022B .

   3.  Using the outgoing filename created by x4mailer, track the message
       by typing:

        x4msgtrack -f I0814090703a.000 -o 2

       Refer to Appendix B for more information on x4msgtrack.

   4.  Using the x4msgtrack output, check the x4mailer events to verify
       the message was sent to the MTA. If no x4mailer events are logged,
       check if x4mailer is running and if event logging is enabled.
       Then run sendmail -bt to verify that a Sendmail route exists and
       can accept X.400 addresses.

   5.  Using the x4msgtrack output, check the MTA events for a
       non-delivered message.  Check the reason listed and use x4solve to
       retrieve the recommended actions.  Refer to Appendix A for more
       information on x4solve.

       If the MTA successfully delivered the message, check the RTS
       events for a non-delivered message.

   6.  Check on the remote node that the user is configured and the
       routing to the remote MTA is correct.  Check with the remote
       system administrator for reasons of non-delivery.

HP as Responder 

The following procedures help trace incoming messages in order to
determine where a problem is occurring.

Remote Node Did Not Receive a Non-delivery Notification.   

If the remote node did not receive a non-delivery notification, do the
following:

   1.  Verify that the message was successfully delivered from the remote
       machine.

   2.  Check for incoming events logged in the RTS event log file for
       this adjacent MTA (refer to Appendix A in this manual for
       information on how to determine the name of the event log file).
       If the RTS successfully received the message, run x4msgtrack using
       the incoming filename.

   3.  Verify that all components are running and that all event logging
       is enabled.

   4.  Using the x4msgtrack output, check the MTA events for a
       non-delivered message.  Check the reason listed and use x4solve to
       retrieve the recommended actions.  Refer to Appendix A for more
       information on x4solve.

       If the MTA successfully delivered the message, go to step 5.

       If a non-delivery report was generated by the MTA, get the
       incoming filename created by the MTA and run x4msgtrack using this
       filename.  Using the x4msgtrack output, check the RTS events for
       the outbound message.  If it was sent successfully, check the
       remote node for problems.  Otherwise, check the RTS event log for
       this adjacent MTA (refer to Appendix A in this manual for
       information on how to determine the name of the event log file).

   5.  If the MTA successfully delivered the message from the remote
       machine to OpenMail, refer to the Getting Mail from X.400 to
       OpenMail section in OMSolve (OpenMail's online troubleshooting
       guide) to determine if OpenMail could not deliver the
       notification.

       If x4mailer successfully delivered the message, check
       /usr/spool/mqueue/syslog for more information.  If the event log
       indicates that the user could not be found and Sendmail generated
       a non-delivery report, then go to step 6.  If a non-delivery
       report was not generated by Sendmail, check the Sendmail
       configuration and refer to the Installing and Administering ARPA 
       Services manual for more information.

   6.  Scan the x4mailer event log for a non-delivery report.  The
       following is an example:

            08/15-12:58:43 Processing outbound message ... (X4EVENT 413)
                     Subject : Returned mail: User unknown
                     Mpdu-id : US TELEMAIL HP   F102253  650750322B
                     Originator : MAILER-DAEMON///US/TELEMAIL/HP////
                     Recipient : root//lan/us/telemail/dec////

            08/15-12:35:02 UMPDU submitted to MTA : (X4EVENT 414)
                     MPDU File [/usr/spool/x400/iq/I0815123502a.000]
                     Mpdu-id : US TELEMAIL HP   F102253  650748901B

       Using the outgoing file I0815123502a.000, track the message by
       typing:

        x4msgtrack -f /usr/spool/x400/iq/I0815123502a.000

   7.  Using the x4msgtrack output, check for any events logged for the
       MTA and RTS. Use x4solve to retrieve the recommended actions.
       Refer to Appendix A for more information on x4solve.

Remote Node Received a Non-delivery Notification.   

If the remote node received a non-delivery notification, do the
following:

   1.  Examine the non-delivery notification and correct any specified
       problems.

   2.  Check if the remote system delivered the message to the HP system.
       If the remote system delivered the message, go to step 3.  If the
       remote system did not deliver the message, troubleshoot the remote
       node.

   3.  Check the RTS event log files (refer to Appendix A in this manual
       for information on how to determine the name of the event log
       file) and get the incoming filename.  Run x4msgtrack using this
       filename.

   4.  Using the x4msgtrack output, check the MTA events.  Use x4solve to
       retrieve the recommended actions.  Refer to Appendix A for more
       information on x4solve.

   5.  If the MTA successfully delivered the message to the x4mailer,
       check /usr/spool/mqueue/syslog.  If the event log indicates that
       the user could not be found, the user account has not been
       configured or Sendmail has not been configured correctly.  Refer
       to the "Configuring a Destination" chapter of the Installing and
       Configuring HP X.400 manual for more information on the Sendmail
       configuration.

   6.  If the MTA successfully delivered the message to OpenMail, refer
       to the Getting Mail from X.400 to OpenMail section of OMSolve
       (OpenMail's online troubleshooting guide) for more information.



MPE/iX 5.0 Documentation