Last modified by Carlijn Kokkeler on 2024/09/17 15:13

From version 7.1
edited by Tudor Neacsu
on 2024/06/21 08:59
Change comment: There is no comment for this version
To version 8.1
edited by Tudor Neacsu
on 2024/06/21 08:59
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,29 +1,28 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -In this document, we will use the information from the actual root cause analysis to make a generic view that can be used if you run into the same or a similar problem in the future. Finally, the document will describe the situation, the problem, the analysis, and the result.
2 +In this microlearning, we will give insights into what is an exit code, the main exit codes returned by a container when it stops and how can that help a Support Engineer to conduct an RCA.
3 3  
4 4  Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 -== 1. Situation ==
6 +== 1. Key concepts ==
7 7  
8 -No data is delivered to a backend system.
9 9  
10 -== 2. Problem ==
9 +== 2. Exit code values ==
11 11  
12 -The problem in this case was that the backend system was not receiving any data. This was caused by an unstable H2 database.
11 +* Exited with code *0*: The application inside the container completed its work successfully without any errors.
13 13  
14 -== 3. Analysis ==
13 +* Exited with code 1: There was a general error in the application, which could be due to a variety of reasons like incorrect arguments or a failed dependency.
15 15  
16 -=== 3.1 Reproduction ===
15 +* Exited with code 125: The docker run command was not executed successfully
17 17  
18 -N/A
17 +* Exited with code 126: The command inside the container was found but cannot be executed. This can be due to permission issues or if the command is not executable.
19 19  
20 -=== 3.2 Analysis ===
19 +* Exited with code 127: The command was not found. This usually happens if a script is missing or the path is not set correctly.
21 21  
22 -The problem led us to investigate the queue statistics of the flow responsible for delivering the data. Here, it was seen that data was flowing throught the queue, but in a repetitive pattern. In the runtime statistics a very high CPU was observed. Consequently, the health of the H2 database was investigated. The H2 database was processing the messages repeatedly after the connector had undergone auto-healing. Therefore, it was not processing the new messages.
21 +* Exited with code 137: The container was forcefully stopped. This happens when the container exceeds its memory resource limit (OOM)
23 23  
24 -== 4. Result ==
23 +* Exited with code 139: The application inside the container crashed due to a segmentation fault, which is usually caused by accessing memory that the process does not have permission to access.
24 +* Exited with code 255: Container exited, returning an exit code outside the acceptable range, meaning the cause of the error is not known
25 25  
26 -The removal and re-addition of the H2 database caused the H2 database to return to normal behavior. Afterwards, the problem did not reoccur. The resetting of the H2 database should also solve the problem. This can be done by moving to Deploy -> Architecture and pressing 'Reset H2'. Do remember that resetting the H2 database or removing and readding it will result in a loss of all the data on the database.
27 27  
28 28  == 5. Suggested Additional Readings ==
29 29  For more information on resetting a H2 Database, please check out the following microlearning: