)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"95b6e50a5a4070e73430d8f05697b6c5860026ed","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"eeccdfc8_4d25469f","updated":"2024-01-05 06:16:02.000000000","message":"I’m fine with that fix as long as we identify the list of services that need this, make a list in the bug - and this is a workaround until we fix it properly.","commit_id":"493b77b5b4e8749e84fd0a39a3d92fc462b2a92d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"4a412ce08bc034d70cb9c3c062c4b80bc6942ab7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"0d9a767f_3362ebfe","in_reply_to":"1191ea10_1b30c34d","updated":"2024-01-05 07:59:37.000000000","message":"Well, in commit message there is \"Details in\nbugreport.\" followed by link to bugreport. But as you wish 😊, added to commit message.","commit_id":"493b77b5b4e8749e84fd0a39a3d92fc462b2a92d"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"a79559dcd2284e8536e1069e678cd199cec77860","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"1191ea10_1b30c34d","in_reply_to":"5dcce7a4_f84862c7","updated":"2024-01-05 07:55:52.000000000","message":"So put that in the commit message, claiming this is ok without any background may be misleading for anybody that will revisit that in future.","commit_id":"493b77b5b4e8749e84fd0a39a3d92fc462b2a92d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"0745a5458881d6d71f52a943a9814163923d697c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5dcce7a4_f84862c7","in_reply_to":"eeccdfc8_4d25469f","updated":"2024-01-05 07:44:24.000000000","message":"do you mean Reno ? or bug report ? because they are already specified on launchpad bug report...\n\nThis is not workaround, this is regular fix. Program which is ending can choose some RC from 0 to 255. \n\nCheck https://komodor.com/learn/exit-codes-in-containers-and-kubernetes-the-complete-guide/ as 143 is regular RC.\n\n\"Exit Code 143 | Graceful termination  | Container received warning that it was about to be terminated, then terminated\"\n\nSo question is, what do you want to fix properly ? Rewrite apps inside container ?\n\nMark resolved.","commit_id":"493b77b5b4e8749e84fd0a39a3d92fc462b2a92d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"6749ea21469b5dfe5c7b9024d18b2f44be9bf44b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ab4f5f45_3c5af1e1","updated":"2024-01-05 08:44:28.000000000","message":"ChatGPT 4.0 answer :D :D :D :D \n\n\nHi ChatGPT, please can u explain why some docker containers wrapped in systemd unit service file exit with return code 143 instead of return code 0 as others when call systemd stop \u003cservice\u003e ?  \n\nChatGPT\nWhen you\u0027re dealing with Docker containers and systemd, the exit code 143 typically signifies that the container received a SIGTERM signal, prompting it to shut down. Here\u0027s a breakdown of why this happens:\n\nSIGTERM and Exit Codes: When you use systemctl stop \u003cservice\u003e on a service managed by systemd, systemd sends a SIGTERM signal to the main process in the service (in this case, the Docker container). SIGTERM politely asks the process to terminate and allows it to perform any cleanup needed before exiting. The exit code 143 specifically corresponds to the process receiving a SIGTERM (signal 15) in most Unix-like operating systems, as the exit code is typically \"128 + N\" where N is the signal number. Since SIGTERM is signal number 15, the exit code becomes 143.\n\nDocker Behavior: When Docker receives the SIGTERM, it forwards this signal to the main process running inside the container. If this process is properly set up to handle SIGTERM, it will perform necessary shutdown procedures and exit. If the main process inside the container exits due to a SIGTERM, Docker itself exits with the same code as the process that it was running. If your application inside the Docker container does not handle SIGTERM and does not exit cleanly, or it takes too long to exit, Docker may eventually kill it with SIGKILL (signal 9), leading to a different exit code.\n\nDifferences in Handling SIGTERM: Why do some containers exit with code 0 and others with 143? This discrepancy can arise from how the main process inside the container handles the SIGTERM signal. If the process has specific signal handling that intercepts the SIGTERM and exits gracefully with a status of 0, then Docker will exit with code 0. However, if the process doesn\u0027t specifically handle the SIGTERM, it will exit with the default action for SIGTERM, which typically results in the 143 exit code.\n\nContainer Configuration: The behavior can also depend on what\u0027s specified in the Dockerfile or the command used to run the container. For instance, some base images or applications have their own signal handling mechanisms or wrappers that might intercept and handle signals differently.\n\nIn summary, receiving a 143 exit code when stopping a Docker container is normal and indicates that the container was stopped due to receiving a SIGTERM signal. To change this behavior, you\u0027d typically look into how the application inside the container handles signals and whether it can intercept and override the default action for SIGTERM.","commit_id":"a678c238ef6f9bf1fa803c574a9ce009a7b1e075"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"9287de9c02b9b718c5845cbf9857380289332081","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"00b8bbd1_e505e7ee","in_reply_to":"ab4f5f45_3c5af1e1","updated":"2024-01-05 09:49:47.000000000","message":"Please don\u0027t treat LLM output as information","commit_id":"a678c238ef6f9bf1fa803c574a9ce009a7b1e075"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"9287de9c02b9b718c5845cbf9857380289332081","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"0a1082a5_829c5891","updated":"2024-01-05 09:49:47.000000000","message":"I\u0027m fine with this as workaround, but we should actually check the services, at least those that we have control over.","commit_id":"b1fd2b40f7cd1c6c457bd42b25ca32dc1e5e0f4f"}]}