6a:T45f,**Normal termination** occurs when a process finishes execution voluntarily and in a controlled manner. This contrasts with abnormal termination, where processes end due to unhandled signals, fatal errors, or external intervention. There are several ways a process can terminate normally: **1. Returning from main()** The most common form of normal termination is simply returning from the `main()` function. The return value becomes the process's exit status: ```c int main() { // ... program logic ... return 0; // Exit status 0 indicates success } ``` **2. Calling exit()** The `exit()` function can be called from anywhere in the program to immediately terminate the process: ```c #include void some_function() { if (fatal_error_detected) { exit(1); // Terminate immediately with status 1 } } ``` **3. Calling _exit() or _Exit()** These provide immediate termination without running cleanup handlers: ```c #include // for _exit() #include // for _Exit() _exit(1); // POSIX: immediate termination _Exit(1); // C99: immediate termination ```6b:T6aa,#include #include // Exit handler functions void cleanup_database() { printf("Closing database connections... "); // Close database connections, commit/rollback transactions } void cleanup_network() { printf("Closing network sockets... "); // Close open sockets, send shutdown notifications } void cleanup_files() { printf("Flushing file buffers... "); // Ensure all buffered data is written } void final_cleanup() { printf("Performing final cleanup... "); // Last-chance cleanup operations } int main() { // Register exit handlers - they execute in REVERSE order // So the order of execution will be: // final_cleanup -> cleanup_files -> cleanup_network -> cleanup_database if (atexit(cleanup_database) != 0) { fprintf(stderr, "Failed to register cleanup_database "); return 1; } if (atexit(cleanup_network) != 0) { fprintf(stderr, "Failed to register cleanup_network "); return 1; } if (atexit(cleanup_files) != 0) { fprintf(stderr, "Failed to register cleanup_files "); return 1; } if (atexit(final_cleanup) != 0) { fprintf(stderr, "Failed to register final_cleanup "); return 1; } printf("Program starting... "); printf("Doing some work... "); // When we return (or call exit()), handlers run in reverse order printf("Program ending normally. "); return 0; // This triggers exit handlers } /* Output: Program starting... Doing some work... Program ending normally. Performing final cleanup... Flushing file buffers... Closing network sockets... Closing database connections... */6c:T4de,#include #include #include #include #include void exit_handler() { printf("Exit handler called! "); } int main() { // Register an exit handler atexit(exit_handler); pid_t pid = fork(); if (pid < 0) { perror("fork failed"); exit(1); } else if (pid == 0) { // Child process printf("Child: Using _exit() to terminate "); // If we used exit() here, the handler would run twice // (once in child, once in parent) and buffered output // could be duplicated. Using _exit() prevents this. _exit(0); // <-- No handler, no buffer flush // This code is never reached printf("This will never print "); } else { // Parent process wait(NULL); // Wait for child printf("Parent: Child has terminated "); printf("Parent: Now exiting normally "); // exit() is called implicitly by returning from main() return 0; // Handler runs here } return 0; } /* Output: Child: Using _exit() to terminate Parent: Child has terminated Parent: Now exiting normally Exit handler called! */6d:T5b6,// Simplified conceptual representation of Linux do_exit() // (Actual kernel code is significantly more complex) void do_exit(long exit_code) { struct task_struct *current = get_current_task(); // 1. Mark process as exiting - prevents new work being assigned current->flags |= PF_EXITING; // 2. Delete any pending timers del_timer_sync(¤t->real_timer); del_timer_sync(¤t->signal->real_timer); // 3. Release memory management structures exit_mm(current); // Handles all VM cleanup // 4. Close all file descriptors exit_files(current); // 5. Release filesystem references (cwd, root) exit_fs(current); // 6. Release namespaces exit_namespace(current); // 7. Release semaphores (SysV IPC) exit_sem(current); // 8. Handle process groups and sessions exit_signals(current); // 9. Set exit code for parent to retrieve current->exit_code = exit_code; // 10. Notify parent and handle orphaned children exit_notify(current); // Sends SIGCHLD, reparents children // 11. Transition to zombie state current->state = TASK_DEAD; current->exit_state = EXIT_ZOMBIE; // 12. Update process accounting acct_update_integrals(current); // 13. Schedule away - we never return from this schedule(); // Context switch to another process // This point is never reached BUG(); }6e:T4a2,#include #include class Resource { const char* name_; public: Resource(const char* name) : name_(name) { std::cout << "Constructing: " << name_ << std::endl; } ~Resource() { std::cout << "Destroying: " << name_ << std::endl; } }; // Static object - destroyed by exit() but not _exit() static Resource staticResource("static_resource"); void demonstrate_exit() { // Local object - NOT destroyed by exit()! Resource localResource("local_resource"); std::cout << "About to call exit()..." << std::endl; // exit() will: // - Run atexit handlers // - Destroy static objects // - NOT destroy local objects! exit(0); // Never reached std::cout << "After exit()" << std::endl; } int main() { std::cout << "Starting main()" << std::endl; demonstrate_exit(); return 0; } /* * Output: * Constructing: static_resource * Starting main() * Constructing: local_resource * About to call exit()... * Destroying: static_resource * * Notice: local_resource destructor was NEVER called! * This is a resource leak if the destructor had important cleanup. */6f:T54e,#include #include #include class DatabaseConnection { public: DatabaseConnection() { std::cout << "DB: Connected "; } ~DatabaseConnection() { std::cout << "DB: Disconnected "; } void execute(const std::string& query) { // Simulate work if (query == "FAIL") { throw std::runtime_error("Query failed"); } std::cout << "DB: Executed: " << query << " "; } }; // Instead of calling exit(), return error codes or throw exceptions int run_application() { auto db = std::make_unique(); try { db->execute("SELECT * FROM users"); db->execute("UPDATE users SET active = 1"); return 0; // Success } catch (const std::exception& e) { std::cerr << "Error: " << e.what() << std::endl; return 1; // Failure - but destructor still runs! } // Destructor called here when db goes out of scope } int main() { int result = run_application(); std::cout << "Application finished with code: " << result << " "; return result; // Proper termination through main() } /* * Output: * DB: Connected * DB: Executed: SELECT * FROM users * DB: Executed: UPDATE users SET active = 1 * DB: Disconnected <-- Destructor called! * Application finished with code: 0 */70:T77a,#include #include #include #include // Application-specific exit codes #define EXIT_CONFIG_ERROR 2 #define EXIT_FILE_NOT_FOUND 3 #define EXIT_PERMISSION_DENIED 4 #define EXIT_NETWORK_ERROR 5 typedef struct { int code; const char* description; } ExitCode; static const ExitCode exit_codes[] = { {EXIT_SUCCESS, "Success"}, {EXIT_FAILURE, "General error"}, {EXIT_CONFIG_ERROR, "Configuration error"}, {EXIT_FILE_NOT_FOUND, "File not found"}, {EXIT_PERMISSION_DENIED, "Permission denied"}, {EXIT_NETWORK_ERROR, "Network error"}, }; void print_usage(const char* program_name) { fprintf(stderr, "Usage: %s ", program_name); } int load_config(const char* filename) { FILE* f = fopen(filename, "r"); if (!f) { fprintf(stderr, "Error opening %s: %s ", filename, strerror(errno)); if (errno == ENOENT) { return EXIT_FILE_NOT_FOUND; } else if (errno == EACCES) { return EXIT_PERMISSION_DENIED; } return EXIT_FAILURE; } // Parse configuration... fclose(f); return EXIT_SUCCESS; } int main(int argc, char* argv[]) { if (argc != 2) { print_usage(argv[0]); return EXIT_CONFIG_ERROR; // Incorrect usage } int result = load_config(argv[1]); if (result != EXIT_SUCCESS) { // Error already printed by load_config return result; } printf("Configuration loaded successfully "); // ... application logic ... return EXIT_SUCCESS; } /* * Usage in shell scripts: * * ./myprogram config.txt * case $? in * 0) echo "Success" ;; * 2) echo "Configuration error" ;; * 3) echo "File not found" ;; * 4) echo "Permission denied" ;; * *) echo "Unknown error: $?" ;; * esac */63:{"json":{"id":"seed_1e3955af4eebd100eb195efa16de9713","slug":"process-termination","category":"Operating Systems","topic":"Process Termination","title":"Process Termination","description":"Master the mechanisms by which processes end their execution. Explore normal and abnormal termination, exit status semantics, resource cleanup procedures, and cascading termination in process hierarchies. Understand how operating systems ensure clean process shutdown while maintaining system integrity.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_b16171af2c587e3ff60693ebc9293f71","title":"Normal Termination (exit)","order":0,"content":[{"id":"opening-hook","title":"The End of a Process's Journey","content":[{"data":{"content":"Every process that begins must eventually end. While we often focus on how processes are created and how they execute, understanding **how processes terminate** is equally crucial for building robust, reliable systems. Normal termination—the graceful, intentional conclusion of a process's execution—is far more sophisticated than simply reaching the end of a `main()` function.\n\nWhen a process terminates normally, a carefully orchestrated sequence of events unfolds: resources are released, file descriptors are closed, memory is reclaimed, parent processes are notified, and the kernel updates its internal data structures. This isn't just cleanup—it's the foundation of system stability. A process that terminates incorrectly can leak resources, leave files in corrupted states, or cause other processes to hang indefinitely waiting for signals that will never arrive."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will deeply understand: the semantics of the exit() system call and its variants, how exit handlers execute during termination, the role of the C runtime in process shutdown, how the kernel handles process termination internally, and the critical relationship between terminating children and their parent processes.","variant":"info"},"type":"callout"}]},{"id":"understanding-normal-termination","title":"Understanding Normal Termination","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Critical Distinction","content":"The difference between exit() and _exit() is subtle but critical. exit() performs cleanup (flushing buffers, running atexit handlers), while _exit() terminates immediately. Using _exit() incorrectly can leave buffered data unwritten to files or network sockets. We'll explore this distinction in depth shortly.","variant":"warning"},"type":"callout"},{"data":{"rows":[["return from main()","Yes","Yes","Yes","Standard program completion"],["exit(status)","Yes","Yes","Yes","Terminate from any function"],["_exit(status)","No","No","No","After fork() in child, signal handlers"],["_Exit(status)","No","No","No","C99 equivalent of _exit()"]],"caption":"Normal Termination Methods Comparison","headers":["Method","Runs atexit Handlers","Flushes stdio Buffers","Calls Destructors (C++)","Use Case"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"exit-system-call-depth","title":"The exit() System Call In Depth","content":[{"data":{"content":"The `exit()` function is not actually a direct system call—it's a C library function that performs significant work before invoking the underlying kernel system call. Understanding this distinction is essential for mastering process termination.\n\n**The Anatomy of exit()**\n\nWhen you call `exit(status)`, the following sequence occurs:\n\n1. **Exit handlers registered via `atexit()` are called** in reverse order of registration\n2. **Exit handlers registered via `on_exit()` are called** (GNU extension, also LIFO order)\n3. **All open stdio streams are flushed and closed**\n4. **Temporary files created by `tmpfile()` are removed**\n5. **The `_exit()` system call is invoked** to actually terminate the process\n\nThis two-phase approach—library cleanup followed by kernel termination—allows programs to perform necessary finalization without explicitly coding cleanup in every execution path."},"type":"text"},{"data":{"code":"$6b","fileName":"exit_handlers_demo.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Exit Handler Best Practices","content":"Register the most critical cleanup handlers last, so they execute first (LIFO order). Keep handlers simple and fast—they run on the termination path and shouldn't block indefinitely. Never call exit() from within an exit handler, as this leads to undefined behavior.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"low-level-exit","title":"The _exit() System Call: Low-Level Termination","content":[{"data":{"content":"While `exit()` is the standard way to terminate a process, `_exit()` (and its C99 equivalent `_Exit()`) provide **immediate kernel-level termination** without any library-level cleanup. This is a direct system call that bypasses the C runtime entirely.\n\n**When the Kernel Receives _exit():**\n\nThe kernel performs several critical operations:\n\n1. **Close all file descriptors** owned by the process\n2. **Release all memory** (heap, stack, code segments)\n3. **Release all locks** held by the process (file locks, semaphores)\n4. **Decrement reference counts** on shared resources\n5. **Notify the parent process** via SIGCHLD signal\n6. **Reparent orphaned children** to init (PID 1)\n7. **Transition the process to zombie state** until parent calls wait()\n8. **Update accounting information** for process statistics"},"type":"text"},{"data":{"code":"$6c","fileName":"exit_vs_exit_demo.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Essential Pattern: _exit() After fork()","content":"Always use _exit() (not exit()) when terminating a child process that was created with fork() but didn't exec(). Using exit() would run the parent's exit handlers in the child, potentially causing duplicated output, double-freeing resources, or corrupting shared state. This is one of the most common process management bugs.","variant":"warning"},"type":"callout"},{"data":{"items":["**Use exit()** for normal program termination from application code","**Use _exit()** in child processes after fork() when not calling exec()","**Use _exit()** in signal handlers to avoid calling non-async-signal-safe functions","**Use _exit()** when you must terminate immediately without any cleanup","**Use exit()** from library code only with extreme caution—libraries shouldn't normally terminate the program"],"title":{"icon":"Target","text":"When to Use _exit() vs exit()","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"kernel-termination-mechanics","title":"Kernel-Level Termination Mechanics","content":[{"data":{"content":"When the kernel receives an `_exit()` or `exit_group()` system call, it initiates a sophisticated cleanup sequence. Understanding this process reveals how the operating system maintains integrity even as processes die.\n\n**The Linux do_exit() Function**\n\nIn Linux, the core termination logic resides in `do_exit()` within `kernel/exit.c`. Here's the conceptual flow:"},"type":"text"},{"data":{"height":"600px","mermaidSyntax":"flowchart TD\n A[Process calls _exit] --> B[Kernel: do_exit]\n B --> C[Set PF_EXITING flag]\n C --> D[Cancel timers and alarms]\n D --> E[Release memory mappings]\n E --> F[Close file descriptors]\n F --> G[Release semaphores and locks]\n G --> H[Exit from task groups]\n H --> I[Notify parent: SIGCHLD]\n I --> J[Reparent orphaned children]\n J --> K[Update accounting]\n K --> L[Set state: TASK_DEAD]\n L --> M[Call schedule - never returns]\n M --> N[Process becomes zombie]\n N --> O{Parent calls wait?}\n O -->|Yes| P[Release task_struct]\n O -->|No| Q[Remain zombie]"},"type":"mermaid-excalidraw"},{"data":{"content":"**Key Kernel Data Structure Changes**\n\nDuring termination, the kernel modifies several critical data structures:\n\n**task_struct Updates:**\n- `exit_state` is set to `EXIT_ZOMBIE` or `EXIT_DEAD`\n- `exit_code` stores the termination status\n- `exit_signal` indicates which signal to send to parent\n\n**Memory Management:**\n- `mm_struct` is decremented and potentially freed\n- Virtual memory areas (VMAs) are unmapped\n- Page table entries are invalidated\n- Physical pages are returned to the page allocator\n\n**File System:**\n- File descriptor table entries are closed\n- Reference counts on inodes are decremented\n- File locks are released\n- Current working directory reference is dropped"},"type":"text"},{"data":{"code":"$6d","fileName":"simplified_do_exit.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"The Point of No Return","content":"Once do_exit() is called, the process can never execute again. The final schedule() call switches context to another runnable process. The terminating process's task_struct remains allocated (in zombie state) only to hold exit status information for the parent. Once the parent retrieves this via wait(), even that final structure is freed.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"stdio-buffer-flushing","title":"stdio Buffer Flushing and Data Integrity","content":[{"data":{"content":"One of the most critical differences between `exit()` and `_exit()` is **buffer flushing**. The C standard library maintains internal buffers for stdio streams, and calling `exit()` ensures all pending data is written to the underlying file descriptors.\n\n**Understanding stdio Buffering**\n\nThe C library implements three buffering modes:\n\n1. **Unbuffered** (`_IONBF`): Data is written immediately. Used by default for `stderr`.\n\n2. **Line-buffered** (`_IOLBF`): Data is written when a newline is encountered or the buffer is full. Used by default for `stdout` when connected to a terminal.\n\n3. **Fully buffered** (`_IOFBF`): Data is written only when the buffer is full. Used by default for `stdout` when redirected to a file, and for all file streams opened with `fopen()`."},"type":"text"},{"data":{"code":"#include \n#include \n#include \n\nint main() {\n printf(\"This message has no newline...\");\n \n // stdout is likely line-buffered when connected to terminal,\n // or fully-buffered when redirected to a file.\n \n // If we call _exit() now, the message might be lost!\n // Try: ./program (may show message - line buffered)\n // Try: ./program > file (likely loses message - fully buffered)\n \n // Uncommenting either of these will lose the buffered data:\n // _exit(0);\n // _Exit(0);\n \n // This is safe - exit() flushes all stdio buffers:\n exit(0);\n \n return 0;\n}\n\n/*\n * Demonstration:\n * \n * $ ./buffering_danger\n * This message has no newline...\n * \n * But with _exit():\n * $ ./buffering_danger > output.txt\n * $ cat output.txt\n * (file may be empty!)\n */","fileName":"buffering_danger.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**The fork() Buffering Pitfall**\n\nThis buffering behavior creates a notorious pitfall with `fork()`. When you fork a process, the child inherits copies of all stdio buffers. If both parent and child then call `exit()`, the buffered data can be **written twice**:"},"type":"text"},{"data":{"code":"#include \n#include \n#include \n#include \n\nint main() {\n printf(\"Message before fork...\");\n // No newline! This sits in stdout's buffer.\n \n pid_t pid = fork();\n \n if (pid == 0) {\n // Child: The buffer contains \"Message before fork...\"\n printf(\"(from child)\n\");\n exit(0); // Flushes: \"Message before fork...(from child)\"\n } else {\n wait(NULL);\n printf(\"(from parent)\n\");\n exit(0); // Flushes: \"Message before fork...(from parent)\"\n }\n \n return 0;\n}\n\n/*\n * BUGGY OUTPUT (using exit() in both):\n * Message before fork...(from child)\n * Message before fork...(from parent)\n * \n * The message appears twice!\n * \n * CORRECT APPROACH: Use _exit() in child, or fflush(NULL) before fork()\n */","fileName":"fork_buffer_duplicate.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Always fflush() Before fork()","content":"To avoid duplicated output, either call fflush(NULL) before fork() to clear all buffers, or use _exit() in the child process. Professional code typically does both: fflush() before fork() for predictable buffering, and _exit() in children that don't exec() as a safety measure.","variant":"warning"},"type":"callout"},{"data":{"code":"#include \n#include \n#include \n#include \n\nint main() {\n printf(\"Message before fork...\");\n \n // CORRECT: Flush all buffers before forking\n fflush(NULL);\n \n pid_t pid = fork();\n \n if (pid == 0) {\n // Child process - buffers are now empty\n printf(\"Hello from child\n\");\n \n // CORRECT: Use _exit() in child that doesn't exec()\n _exit(0);\n } else {\n wait(NULL);\n printf(\"Hello from parent\n\");\n return 0; // exit() is fine in parent\n }\n}\n\n/*\n * CORRECT OUTPUT:\n * Message before fork...Hello from child\n * Hello from parent\n */","fileName":"correct_fork_pattern.c","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":5},{"id":"cpp-considerations","title":"C++ Considerations: Destructors and RAII","content":[{"data":{"content":"In C++, process termination has additional complexity due to **destructors** and the **RAII (Resource Acquisition Is Initialization)** pattern. The relationship between exit functions and object destruction is nuanced and critical for resource management.\n\n**Destruction Behavior With Different Exit Methods:**"},"type":"text"},{"data":{"rows":[["`return` from `main()`","Yes","Yes"],["`exit()`","No","Yes"],["`_exit()` / `_Exit()`","No","No"],["`std::exit()`","No","Yes"],["`std::quick_exit()`","No","No (runs at_quick_exit handlers)"],["`std::abort()`","No","No"]],"headers":["Exit Method","Local Object Destructors","Static Object Destructors"]},"type":"table"},{"data":{"code":"$6e","fileName":"cpp_exit_destructors.cpp","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Critical C++ Pitfall","content":"Calling exit() from a C++ program bypasses destructors for all local objects on the call stack. If these objects manage resources (file handles, database connections, mutexes), those resources will be leaked. In C++, prefer to propagate errors back to main() and return normally, or use exceptions to unwind the stack properly.","variant":"error"},"type":"callout"},{"data":{"content":"**Recommended C++ Exit Pattern:**\n\nTo ensure proper cleanup in C++, structure your program so that termination flows through `main()`:"},"type":"text"},{"data":{"code":"$6f","fileName":"cpp_proper_exit.cpp","showLineNumbers":true},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"exit-status-conventions","title":"Exit Status Conventions","content":[{"data":{"content":"The exit status is the integer value passed to `exit()` or returned from `main()`. This value communicates the outcome of the process to its parent and is essential for shell scripting, process orchestration, and error handling.\n\n**Standard Conventions:**\n\n- **0**: Success (the only portable success value)\n- **1**: General errors\n- **2**: Misuse of shell commands (per Bash convention)\n- **126**: Command cannot execute (permission denied)\n- **127**: Command not found\n- **128**: Invalid exit argument\n- **128+N**: Fatal signal N (e.g., 130 = 128 + 2 for SIGINT)\n- **255**: Exit status out of range\n\n**POSIX Definitions:**\n\nPOSIX defines two symbolic constants in ``:\n- `EXIT_SUCCESS` (0)\n- `EXIT_FAILURE` (typically 1, but implementation-defined)\n\nUsing these symbols makes code more portable and self-documenting."},"type":"text"},{"data":{"code":"$70","fileName":"exit_status_usage.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Exit Code Best Practices","content":"Document your exit codes in man pages or --help output. Use symbolic constants rather than magic numbers. Avoid codes above 125, as they may conflict with shell conventions. For daemons, follow sysexits.h conventions (EX_OK, EX_USAGE, EX_DATAERR, etc.) when possible.","variant":"tip"},"type":"callout"},{"data":{"content":"**The sysexits.h Standard:**\n\nBSD systems (and many Linux installations) provide `` with standardized exit codes:"},"type":"text"},{"data":{"rows":[["64","EX_USAGE","Command line usage error"],["65","EX_DATAERR","Data format error"],["66","EX_NOINPUT","Cannot open input"],["67","EX_NOUSER","Addressee unknown"],["68","EX_NOHOST","Host name unknown"],["69","EX_UNAVAILABLE","Service unavailable"],["70","EX_SOFTWARE","Internal software error"],["71","EX_OSERR","System error"],["72","EX_OSFILE","Critical OS file missing"],["73","EX_CANTCREAT","Cannot create output file"],["74","EX_IOERR","Input/output error"],["75","EX_TEMPFAIL","Temporary failure"],["76","EX_PROTOCOL","Protocol error"],["77","EX_NOPERM","Permission denied"],["78","EX_CONFIG","Configuration error"]],"headers":["Code","Constant","Meaning"]},"type":"table"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Normal Termination Mastery","content":[{"data":{"content":"We've explored the complete landscape of normal process termination—from the high-level `exit()` function to low-level kernel mechanics. Let's consolidate the essential knowledge:"},"type":"text"},{"data":{"type":"ordered","items":["**exit() is a library function** that performs cleanup (atexit handlers, buffer flushing) before calling the kernel's _exit()","**_exit() is the kernel system call** that performs immediate termination without library cleanup","**Always use _exit() in forked children** that don't exec() to avoid duplicated cleanup and output","**fflush(NULL) before fork()** prevents buffered data from being inherited and potentially duplicated","**In C++, exit() doesn't call local destructors** — flow control back to main() ensures RAII cleanup","**Exit status conventions exist** — use EXIT_SUCCESS, EXIT_FAILURE, and document application-specific codes","**The kernel performs comprehensive cleanup** — file descriptors, memory, locks, and process relationships are all handled","**Zombie state holds exit status** until the parent retrieves it via wait()"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNormal termination represents the ideal case—processes that complete their work successfully and exit gracefully. However, not all processes are so fortunate. In the next page, we'll explore **abnormal termination**: what happens when processes are killed by signals, crash due to bugs, or are forcibly terminated by the operating system. Understanding both sides of termination gives you the complete picture of process lifecycle management."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a deep understanding of normal process termination in Unix-like systems. You understand the difference between exit() and _exit(), how exit handlers work, the critical relationship with fork(), and how the kernel manages the final cleanup. This knowledge is essential for writing robust, resource-safe systems software.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_8eb1f11798c1fb65827e6bdfd3097574","title":"Abnormal Termination","order":1,"content":null,"isLocked":true},{"id":"seed_528b0288426dbbee035a83cf48f03f91","title":"Return Status","order":2,"content":null,"isLocked":true},{"id":"seed_8524441c7242194002d565463e30970c","title":"Resource Cleanup","order":3,"content":null,"isLocked":true},{"id":"seed_2cfe768cd822fb15de0fc98a2d290d3e","title":"Cascading Termination","order":4,"content":null,"isLocked":true}]}}