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