Kbase P130720: How to read truss, strace or tusc to trouble shoot webspeed or app server start up problems?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/22/2008 |
|
Status: Unverified
GOAL:
How to read truss, strace or tusc to trouble shoot webspeed or app server start up problems?
GOAL:
How to interprete contents of truss, strace or tuse contents to help trouble shooting webspeed or app server startup problems?
FACT(s) (Environment):
UNIX
Progress 9.x
OpenEdge 10.x
WebSpeed 3.x
FIX:
In solution P76735, series of trouble shooting steps are listed on how to attack app server or webspeed startup problems with very limited logging information. In the last step, it was suggested that truss (tusc for HP and strace for Linux) is used to further diagnose the issue if all other means failed. truss or " trace operating system call", is an OS utility that will give you insight of series of OS calls that was made during the agent start up process and which calls were successful and which ones were not.
Following is an analysis of strace analysis that was derived during a troubed webspeed agent startup.
Line 1:
execve is the starting of the _progres process. In this case, we see command line parameters. You might not always get this.
Lines 386 - 389:
Opening promsgs, assigning file descriptor 3.
Lines 504 - 513:
Creating the lbi file. Checking to see if it exists, creating it, and assigning file descriptor 5.
Lines 1016 - 1019:
stat64 is looking for web/objects/web-disp.r and web/objects/web-disp.p, first in ., then in /apps/mfgpro, then in /apps/dlc/tty. Refering to the man pages, the return value of -1 with errno ENOENT means that the file does not exist. The agent finally finds web/objects/web-disp.r in /apps/dlc/tty/. This would suggest the agent is searching for web/objects/web-disp.r using PROPATH.
Lines 1020 - 1029:
open() opens the found web/objects/web-disp.r, giving it file desciptor 9. read(9,...) reads bytes from the opened file. close(9) closes the file. The agent just read the contents of the .r file into memory.
web-disp.p is the program given on the agent command line, so we know at this point the agent has initialised correctly, and has started executing r-code.
Lines 1067 - 1083:
Search and open of webutil/webstart.p. A look at web-disp.p in WITCH shows:
RUN webutil/webstart.p PERSISTENT SET hWebStart.
So we know the agent got this far through web-disp.p.
Lines 1086 - 1087:
Reads a message from promsgs. Still using fd 3. This is displaying an error message, so for every error message, you might expect to see a read from promsgs first.
Lines 1088 - 1134:
Search and open of web/objects/stateaware.p, using PROPATH. stateaware.p is executed by webstart.p:setSuperStack(), called from the main block of webstart.p. We know that webstart.p is running. The same for web-util.p and session.p.
Lines 1231 - 1234:
Starting the search for tagmap.dat, again using PROPATH. WITCH shows us there are a couple of places we use tagmap.dat. One of these is in reset-tagmap-utilities in web-util.p, which is called by web-disp.p right after running webstart.p. The specific 4GL construct is SEARCH("tagmap.dat"). We see that the targets of ., /apps/mfgpro and /apps/dlc/tty are searched with no success.
Lines 1235 - 1245:
The agent opens procedure library adeshar.pl, assigns fd 10, then reads in the table of contents for the procedure library. This probably means it is searching for something in PROPATH. The agent is still searching for tagmap.dat. Note that there is no close() for this, as it is a procedure library, and we will probably need to access it later. The same happens for adecomm.pl, adeedit.pl, as4dict.pl, prodict.pl, and adecomp.pl.
Lines 1361 - 1362:
Looking for tagmap.dat in /apps/dlc and /apps/dlc/bin, with no luck. We are still executing the SEARCH statement here.
Line 1367:
close(5). From above, fd 5 is the lbi file. This happens only at the end of a client session. So for some reason, the agent is shutting down (gracefully, not crashing). From this, we can deduce that some time after SEARCH, the agent decided to stop. There are no reads from promsgs, so the client did not generate any error to cause the agent to fail. The agent is probably getting a. STOP or ERROR condition before going into the WAIT-FOR-BLOCK. A code review of reset-tagmap-utilities shows that if SEARCH("tagmap.dat") fails, it returns ERROR. This is probably causing the agent to terminate the processing of web-disp.p, so the agent will terminate..