fork, exec আর wait — প্রসেস তৈরি আর শেষ

১ · প্রসেস আসে কোথা থেকে — প্রসেসের বংশবৃক্ষ

পর্ব ৮-এ দেখেছেন, একটি process হলো চলমান একটি program — তার কোড, নিজস্ব মেমরি, খোলা ফাইল আর CPU-র অবস্থা মিলিয়ে। প্রতিটির একটি পরিচয় নম্বর থাকে: PID (process ID). কিন্তু প্রশ্ন হলো, নতুন প্রসেস জন্মায় কীভাবে? আপনি টার্মিনালে ls লিখে Enter চাপলেন — ls নামের প্রসেসটি কে বানাল?

উত্তর: আরেকটি প্রসেস। Unix-ধাঁচের সিস্টেমে (Linux, macOS, BSD) প্রথম user প্রসেস init (PID 1) ছাড়া প্রতিটি প্রসেসকে অন্য কোনো প্রসেস তৈরি করেছে। যে তৈরি করে সে parent, যাকে তৈরি করা হলো সে child. প্রতিটি প্রসেস তার parent-এর PID মনে রাখে — একে বলে PPID. ফলে পুরো সিস্টেম একটি বংশবৃক্ষ, যাকে বলে process tree. Linux-এ pstree কমান্ড এটি দেখায় (উদাহরণ আউটপুট, আপনার মেশিনে ভিন্ন হবে):

$ pstree -p | head -n 6
systemd(1)─┬─sshd(812)───sshd(4090)───bash(4100)───pstree(4188)
           ├─cron(640)
           ├─nginx(901)─┬─nginx(902)
           │            └─nginx(903)
           └─systemd-journal(301)

এখানে PID 1 হলো systemd (পর্ব ৭). তার child sshd, sshd-এর child আপনার login shell bash, আর bash-এর child এইমাত্র চালানো pstree. প্রতিটি কমান্ড আপনার shell-এর একটি child হয়ে জন্মায় আর কাজ শেষে বিদায় নেয়।

তিনটি call, তিনটি কাজ

Unix এই জন্ম-মৃত্যুর কাজটি তিনটি আলাদা system call-এ ভাগ করেছে। প্রথমে একটি উপমা দিয়ে বুঝে নিই।

এই ভাগাভাগির সবচেয়ে বড় সুবিধা দেখা যায় shell-এ। fork আর exec-এর মাঝখানে child-এর হাতে কিছু সময় থাকে, যখন সে এখনো shell-এর কোড চালাচ্ছে। তখন সে নিজের stdout একটি ফাইলে ঘুরিয়ে দিতে পারে (ls > out.txt), একটি pipe-এর সাথে জুড়তে পারে (ls | wc -l), directory বা environment বদলাতে পারে — তারপর exec. নতুন প্রোগ্রামটি এসব কিছুই জানে না, শুধু দেখে তার fd 1 আগে থেকেই ঠিক জায়গায় জোড়া। একটি “সব-একসাথে” call-এ এগুলোর প্রতিটির জন্য আলাদা parameter লাগত।

২ · fork() — একবার ডাকলে দুবার ফেরে

fork-এর সবচেয়ে অদ্ভুত দিকটি দিয়েই শুরু করি। সাধারণ ফাংশন একবার ডাকলে একবার ফেরে। fork একবার ডাকা হয়, কিন্তু ফেরে দুটি প্রসেসে — parent-এ আর নতুন child-এ। দুজনেই fork-এর ঠিক পরের লাইন থেকে চলে। তাহলে কোড কীভাবে বুঝবে সে কে? ফেরত মান দেখে:

তাই fork-এর পরের কোড প্রায় সবসময় এরকম দেখায়: if (pid == 0) { child-এর কাজ } else if (pid > 0) { parent-এর কাজ } else { ত্রুটি }. একটি আসল উদাহরণ দেখি। এখানে child নিজের কাজ করে exit(3) দিয়ে শেষ হয়, আর parent আগে waitpid দিয়ে অপেক্ষা করে, তারপর ছাপে — ফলে আউটপুটের ক্রম প্রতিবার একই থাকে।

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    int x = 100;
    pid_t me = getpid();
    printf("before fork: one process, x = %d\n", x);
    fflush(stdout);                   /* empty the buffer before fork */

    pid_t pid = fork();
    if (pid < 0) { perror("fork"); return 1; }

    if (pid == 0) {                   /* ---- child ---- */
        x += 1;
        printf("[child ] fork() returned 0\n");
        printf("[child ] my parent is the original? %s\n",
               getppid() == me ? "yes" : "no");
        printf("[child ] x = %d (my own copy)\n", x);
        exit(3);
    }
    /* ---- parent ---- */
    int status;
    pid_t done = waitpid(pid, &status, 0);   /* child finishes first */
    printf("[parent] fork() returned the child's pid (> 0)? %s\n",
           pid > 0 ? "yes" : "no");
    printf("[parent] waitpid returned that same pid? %s\n",
           done == pid ? "yes" : "no");
    printf("[parent] x = %d (unchanged)\n", x);
    printf("[parent] child exit status = %d\n", WEXITSTATUS(status));
    return 0;
}

before fork: one process, x = 100
[child ] fork() returned 0
[child ] my parent is the original? yes
[child ] x = 101 (my own copy)
[parent] fork() returned the child's pid (> 0)? yes
[parent] waitpid returned that same pid? yes
[parent] x = 100 (unchanged)
[parent] child exit status = 3

কী কপি হয়, কী হয় না

“হুবহু কপি” কথাটি পুরোপুরি সত্য নয়। POSIX মানদণ্ড আর Linux-এর man page নির্দিষ্ট করে দেয় কোনটি child পায় আর কোনটি পায় না। পরীক্ষায় এই তালিকা প্রায়ই আসে:

File descriptor কপি হয়, কিন্তু offset ভাগ হয়

এই সূক্ষ্ম বিষয়টি ভালো করে বুঝুন। Kernel-এ একটি খোলা ফাইলের তিনটি স্তর থাকে: প্রসেসের fd টেবিল (ছোট সংখ্যা 0, 1, 2, 3…), তার পেছনে open file description (ফাইলটি কোন মোডে খোলা আর এখন কোন বাইটে আছি — offset), আর তার পেছনে আসল ফাইল। fork fd টেবিল কপি করে, কিন্তু দুই টেবিলের এন্ট্রি একই open file description-এর দিকে নির্দেশ করে। তাই parent ১০ বাইট পড়লে child-এর জন্যও offset ১০ বাইট এগিয়ে যায়। দুজনে একই লগ ফাইলে লিখলে একে অপরের লেখা মুছে ফেলে না, বরং পরপর যোগ হয় — এজন্যই parent আর child-এর আউটপুট একই টার্মিনাল বা pipe-এ সুন্দরভাবে আসে। আর আলাদা আলাদা open() করলে প্রত্যেকে নিজস্ব offset পেত।

Copy-on-write — কপি না করেই কপি

একটি প্রসেস ২ GB মেমরি ব্যবহার করলে fork কি ২ GB কপি করে? করলে প্রতিটি কমান্ড চালাতে কয়েক সেকেন্ড লাগত। আধুনিক OS একটি চালাকি করে: fork-এর সময় kernel মেমরির পাতাগুলো (page) কপি করে না, শুধু দুই প্রসেসের page table-এ একই physical পাতা বসিয়ে দেয়, আর সেগুলোকে “শুধু পড়া যাবে” চিহ্নিত করে। যতক্ষণ দুজনে শুধু পড়ে, একটি পাতাই দুজনের কাজে লাগে। কেউ লিখতে গেলেই হার্ডওয়্যার একটি page fault তোলে, kernel তখন শুধু সেই একটি পাতা কপি করে লেখকের নিজের করে দেয়। একেই বলে copy-on-write (COW). উপরের কোডে child x += 1 লিখতেই x-এর পাতাটি কপি হয়েছে; বাকি পাতাগুলো হয়তো কখনো কপিই হয়নি। এর পেছনের page fault আর virtual memory-র কলকবজা পর্ব ৩৫-এ বিস্তারিত দেখবেন।

৩ · fork গোনার ধাঁধা — কতটি প্রসেস, কতবার ছাপা

বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষায় fork নিয়ে সবচেয়ে বেশি আসে এই ধাঁধা: “নিচের কোড চালালে কতবার hi ছাপা হবে?” মূল নিয়ম একটাই — fork চলার মুহূর্তে যতগুলো প্রসেস ওই লাইনে পৌঁছায়, প্রত্যেকে একটি করে নতুন প্রসেস বানায়. তাই প্রতিটি fork লাইন প্রসেসের সংখ্যা দ্বিগুণ করে। পরপর তিনটি fork ধাপে ধাপে দেখি। নাম রাখার নিয়ম: k-তম fork-এ প্রতিটি Pi নতুন child বানায় P(i + 2^k−1).

1int main(void) {   // P0 starts2    fork();         // fork #13    fork();         // fork #24    fork();         // fork #35    printf("hi\n");6}

P0

P0
└─ P1

P0
├─ P1
│  └─ P3
└─ P2

P0
├─ P1
│  ├─ P3
│  │  └─ P7
│  └─ P5
├─ P2
│  └─ P6
└─ P4

যখন fork একটি শর্তের ভেতরে — && আর ||

পরীক্ষকেরা ধাঁধা কঠিন করেন C-র short-circuit নিয়ম দিয়ে: A && B-এ A মিথ্যা (0) হলে B চালানোই হয় না; A || B-এ A সত্য (শূন্য নয়) হলে B চালানো হয় না। fork-এর ক্ষেত্রে parent পায় ধনাত্মক PID (সত্য), child পায় 0 (মিথ্যা)। তাই একই এক্সপ্রেশন একেক প্রসেসে একেক পথে চলে। বিখ্যাত উদাহরণ (fork() && fork()) || fork() — তিনটি fork-কে নাম দিই A, B, C. নিচের টেবিলে “+” মানে ধনাত্মক PID, “0” মানে শূন্য:

1int main(void) {2    (fork() && fork()) || fork();3    //  A           B         C4    printf("hi\n");5}

এই উত্তর আমরা নিজেরা চালিয়েও যাচাই করেছি: এক্সপ্রেশনের পর printf("hi\n") আর fflush দিয়ে Linux-এ চালালে ঠিক ৫ লাইন আসে। (gcc -Wall-এ বন্ধনী ছাড়া fork() && fork() || fork() লিখলে “suggest parentheses” warning দেয়; অর্থ একই, কারণ &&-এর অগ্রাধিকার ||-এর চেয়ে বেশি।)

৪ · fork আর stdio buffer — printf দুবার আসে কেন

পর্ব ৫-এ দেখেছেন, printf সরাসরি kernel-এ লেখে না; লেখা জমায় user-space-এর একটি buffer-এ (buffering). stdout টার্মিনাল হলে প্রতিটি newline-এ buffer খালি হয়, কিন্তু pipe বা ফাইল হলে buffer ভরা পর্যন্ত বা প্রোগ্রাম শেষ হওয়া পর্যন্ত লেখা বসে থাকে। এখন fork-এর তালিকাটি আবার দেখুন: child পায় parent-এর পুরো মেমরির কপি। stdio buffer-ও মেমরি। তাই fork-এর আগে buffer-এ যা বসে ছিল, তা দুই প্রসেসেই থাকে, আর দুজনে শেষে নিজের নিজের কপি flush করলে লেখাটি দুবার আসে।

নিচের প্রোগ্রাম তিনভাবে একই কাজ করে: (০) flush ছাড়া fork, child শেষ হয় exit() দিয়ে; (১) fork-এর আগে fflush; (২) flush ছাড়া fork, কিন্তু child শেষ হয় _exit() দিয়ে। এই পাতার রানারে stdout একটি pipe — প্রথম লাইনেই তা দেখা যাবে।

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

/* mode 0: no fflush, child calls exit()
   mode 1: fflush before fork, child calls exit()
   mode 2: no fflush, child calls _exit()          */
static void demo(int mode) {
    printf("hello from mode %d\n", mode);   /* sits in the stdio buffer */
    if (mode == 1) fflush(stdout);
    pid_t pid = fork();
    if (pid == 0) {
        if (mode == 2) _exit(0);   /* no stdio flush at all */
        exit(0);                   /* flushes the child's copy */
    }
    waitpid(pid, NULL, 0);
    fflush(stdout);                /* parent flushes its own copy */
}

int main(void) {
    printf("stdout is a terminal? %s\n", isatty(STDOUT_FILENO) ? "yes" : "no");
    fflush(stdout);
    demo(0);
    demo(1);
    demo(2);
    return 0;
}

stdout is a terminal? no
hello from mode 0
hello from mode 0
hello from mode 1
hello from mode 2

exit() বনাম _exit()

দুটোই প্রসেস শেষ করে, কিন্তু স্তর আলাদা। exit() C library-র ফাংশন: আগে atexit() দিয়ে নিবন্ধিত ফাংশনগুলো উল্টো ক্রমে চালায়, সব stdio stream flush ও বন্ধ করে, তারপর ভেতরে _exit() ডাকে। _exit() (আর C99-এর _Exit()) সরাসরি kernel-এর কাছে যায় — Linux-এ exit_group system call. Kernel তখন সব fd বন্ধ করে, মেমরি ফেরত নেয়, parent-কে খবর দেয়। main থেকে return n করা মানে exit(n) ডাকা।

৫ · exec পরিবার — একই প্রসেসে নতুন প্রোগ্রাম

fork দিয়ে পাওয়া কপি এখনো parent-এর প্রোগ্রামই চালাচ্ছে। অন্য প্রোগ্রাম চালাতে লাগে exec. Kernel-এ এর মূল system call একটিই — execve(path, argv, envp) (Linux-এ তার একটি নতুন রূপ execveat-ও আছে)। বাকিগুলো C library-র সুবিধাজনক রূপ, যাদের নামের শেষের অক্ষরগুলোই বলে দেয় কী কাজ করে:

খেয়াল করুন, argv[0] সাধারণত প্রোগ্রামের নাম — রীতি অনুযায়ী। exec-এর প্রথম argument (যেমন "/bin/ls") লাগে প্রোগ্রামের ফাইলটি খুঁজে পেতে, আর argv[0]-এর "ls" লাগে চালু হওয়া প্রোগ্রামের নিজের নাম জানতে; দুটো আলাদা জিনিস।

exec-এর পরে কী থাকে, কী যায়

exec সফল হলে কখনো ফেরে না — যে কোডে ফিরবে, সেটিই তো আর নেই। তাই exec-এর পরের লাইন চলে শুধু ব্যর্থ হলে, আর তখন সেখানে ত্রুটি ছাপিয়ে _exit করাই রীতি। অন্যদিকে fd থেকে যাওয়া একটি দারুণ সুবিধা (shell-এর redirection এভাবেই কাজ করে), কিন্তু নিরাপত্তার ঝুঁকিও: একটি সার্ভার যদি একটি গোপন ফাইল খুলে রেখে কোনো সাহায্যকারী প্রোগ্রাম exec করে, প্রোগ্রামটি সেই fd পেয়ে যায়। সমাধান হলো fd-তে FD_CLOEXEC চিহ্ন দেওয়া — open(path, O_RDONLY | O_CLOEXEC) বা fcntl(fd, F_SETFD, FD_CLOEXEC); তখন exec-এর মুহূর্তে kernel নিজেই fd-টি বন্ধ করে দেয়। এজন্য আধুনিক সফটওয়্যার শুরু থেকেই close-on-exec ব্যবহার করে — যেমন glibc নিজের ভেতরে যে ফাইলগুলো খোলে, আর Python ৩.৪ থেকে নিজের খোলা সব fd.

fork + exec + waitpid — একটি ছোট shell-এর হৃদয়

নিচের run() ফাংশনটি আসলে একটি shell-এর মূল কাজ: fork, child-এ execvp, parent-এ waitpid, তারপর ফলাফল পড়া। চারটি পরিস্থিতি চালানো হয়েছে — সফল কমান্ড, নিজে ব্যর্থ হওয়া কমান্ড, না-থাকা প্রোগ্রাম, আর signal-এ মারা যাওয়া প্রোগ্রাম।

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

static void run(char *argv[]) {
    fflush(stdout);
    pid_t pid = fork();
    if (pid == 0) {                       /* child: become another program */
        execvp(argv[0], argv);
        perror("execvp");                 /* reached ONLY if exec failed */
        _exit(127);
    }
    int st;
    waitpid(pid, &st, 0);                 /* parent: wait and decode */
    if (WIFEXITED(st))
        printf("   -> %s: exited, status %d\n", argv[0], WEXITSTATUS(st));
    else if (WIFSIGNALED(st))
        printf("   -> %s: killed by signal %d\n", argv[0], WTERMSIG(st));
}

int main(void) {
    dup2(STDOUT_FILENO, STDERR_FILENO);   /* like 2>&1 */
    char *a[] = {"ls", "-d", "/etc", "/proc", NULL};
    char *b[] = {"ls", "/no/such/dir", NULL};
    char *c[] = {"no-such-program", NULL};
    char *d[] = {"sh", "-c", "kill -TERM $$", NULL};
    run(a);
    run(b);
    run(c);
    run(d);
    return 0;
}

/etc
/proc
   -> ls: exited, status 0
ls: cannot access '/no/such/dir': No such file or directory
   -> ls: exited, status 2
execvp: No such file or directory
   -> no-such-program: exited, status 127
   -> sh: killed by signal 15

এবার আপনার shell যখন ls চালায়, তখন সময়ের সাথে দুই প্রসেসে কী ঘটে, ধাপে ধাপে দেখি। PID-গুলো উদাহরণ মাত্র।

1line = read_line();       // "ls"2pid = fork();3if (pid == 0) {           // child4    execvp("ls", argv);5    _exit(127);6}7waitpid(pid, &st, 0);    // parent8last = WEXITSTATUS(st);   // $?9print_prompt();

৬ · wait, waitpid আর exit status — প্রসেস কীভাবে শেষ হলো

wait(&st) যেকোনো একটি child শেষ হওয়া পর্যন্ত অপেক্ষা করে। waitpid(pid, &st, options) আরও নিয়ন্ত্রণ দেয়: pid > 0 হলে ঠিক সেই child; −1 হলে যেকোনো child (wait-এর মতো); 0 হলে নিজের process group-এর যেকোনো child. আর options-এ WNOHANG দিলে অপেক্ষা করে না — কোনো child শেষ না হয়ে থাকলে সঙ্গে সঙ্গে 0 ফেরত দেয়; সার্ভার আর event loop এভাবে কাজ থামিয়ে না রেখে মৃত child-দের তুলে নেয়। কোনো child-ই না থাকলে ফেরত −1, errno = ECHILD.

st-এ kernel একটি পূর্ণসংখ্যায় কয়েকটি তথ্য গুঁজে দেয়। এর বিট-বিন্যাস OS-ভেদে আলাদা হতে পারে, তাই সরাসরি বিট না পড়ে POSIX-এর macro ব্যবহার করতে হয়:

দুটি বাস্তব কথা। প্রথমত, exit-এর সংখ্যার শুধু নিচের ৮ বিট যায় — exit(256) parent-এর কাছে 0 হয়ে পৌঁছায়, অর্থাৎ “সফল”! তাই ত্রুটির কোড ১ থেকে ১২৫-এর মধ্যে রাখাই নিরাপদ। দ্বিতীয়ত, shell signal-এ মরা প্রসেসের $? দেখায় ১২৮ + signal নম্বর — যেমন Ctrl+C (SIGINT, 2) চাপলে echo $? দেখায় 130.

প্রসেস শেষ হওয়ার কারণগুলো

• স্বাভাবিক, নিজের ইচ্ছায়: main থেকে return, exit(), _exit(); বা multi-thread প্রোগ্রামে শেষ থ্রেডটিও শেষ হলে। কাজ সফল হোক বা ব্যর্থ — exit status বলে দেয়।
• নিজের ভুলে, signal-এ: অবৈধ মেমরি ছোঁয়া (SIGSEGV), শূন্য দিয়ে পূর্ণসংখ্যা ভাগ (SIGFPE), abort() (SIGABRT, প্রায়ই assert ব্যর্থ হলে)। Kernel বা library signal পাঠায়, ডিফল্ট কাজ হলো প্রসেস শেষ করা।
• অন্যের হাতে: অন্য প্রসেস kill() দিয়ে SIGTERM বা SIGKILL পাঠালে (অনুমতি থাকলে), টার্মিনাল বন্ধ হলে SIGHUP, Ctrl+C-তে SIGINT. মেমরি একেবারে ফুরিয়ে গেলে Linux-এর OOM killer একটি প্রসেস বেছে SIGKILL পাঠায় (পর্ব ৩৮)।
• সীমা পেরোলে: CPU সময়ের সীমা (RLIMIT_CPU) পেরোলে SIGXCPU, ফাইলের আকারের সীমায় SIGXFSZ.

Signal কীভাবে পাঠানো, ধরা বা উপেক্ষা করা যায়, তা পর্ব ১৩-এর বিষয়। এখানে শুধু মনে রাখুন: কারণ যা-ই হোক, kernel প্রতিবার parent-এর জন্য একটি status রেখে যায় — আর সেটি না নেওয়া পর্যন্ত একটি ছোট দাগ রয়ে যায়।

৭ · Zombie আর orphan — শেষ হয়েও শেষ নয়

Child শেষ হলে kernel তার প্রায় সবকিছু ফেরত নেয় — মেমরি, খোলা ফাইল, থ্রেড। কিন্তু একটি ছোট রেকর্ড রেখে দেয়: PID, exit status আর CPU সময়ের হিসাব, যাতে parent পরে জানতে পারে কী হয়েছিল। যতক্ষণ parent wait করে status না নেয়, প্রসেসটি এই আধা-মৃত অবস্থায় থাকে — একেই বলে zombie (ps-এ অবস্থা Z, নামের পাশে <defunct>). আর যে child-এর parent আগেই মারা গেছে, সে orphan.

1pid = fork();                   // P=200, C=2012if (pid == 0) { work(); exit(7); }3do_something_else();            // parent busy4waitpid(pid, &st, 0);          // reaps 2015c2 = fork();                    // C2=2026exit(0);                        // P exits first!7// in 202: work(); exit(0);

এবার আসল মেশিনে একটি zombie বানিয়ে দেখি। কৌশলটি হলো এমন একটি parent তৈরি করা যে কখনো wait করবে না: একটি subshell প্রথমে ছোট একটি child (sleep 0.1) চালায়, তারপর exec দিয়ে নিজেই sleep 0.6-এ পরিণত হয়। sleep প্রোগ্রাম wait করতে জানে না, তাই child শেষ হলে zombie হয়ে থাকে:

# A parent that never calls wait():
# the subshell starts a short child, then exec's into "sleep 0.6",
# so the new parent (sleep 0.6) never reaps that child.
( sleep 0.1 & exec sleep 0.6 ) &
outer=$!
sleep 0.3
echo "== 0.3 s later: the child has exited, nobody has reaped it =="
ps -o pid,ppid,stat,args -p "$outer" --ppid "$outer"
echo
wait "$outer"          # the shell reaps "sleep 0.6" (its own child)
echo "== after its parent exits: adopted and reaped =="
ps -e -o pid,ppid,stat,args | awk 'NR==1 || $3 ~ /^Z/'
echo "zombies left: $(ps -e -o stat= | grep -c '^Z')"
echo "PID 1 here is: $(ps -o comm= -p 1)"

== 0.3 s later: the child has exited, nobody has reaped it ==
    PID    PPID STAT COMMAND
      3       2 SN   sleep 0.6
      4       3 ZN   [sleep] <defunct>

== after its parent exits: adopted and reaped ==
    PID    PPID STAT COMMAND
zombies left: 0
PID 1 here is: podman-init

Zombie ঠেকানোর উপায়

• প্রতিটি child-এর জন্য wait: সবচেয়ে সরল। অনেক child থাকলে SIGCHLD handler-এ while (waitpid(-1, &st, WNOHANG) > 0) ; — লুপ দরকার, কারণ একসাথে কয়েকটি child মরলে signal একবারই আসতে পারে।
• SIGCHLD উপেক্ষা: POSIX অনুযায়ী parent SIGCHLD-কে স্পষ্টভাবে SIG_IGN করলে (বা SA_NOCLDWAIT) kernel child-দের zombie না বানিয়েই মুছে দেয় — তবে তখন exit status আর জানা যায় না।
• Double fork: পুরোনো daemon-এর কৌশল — child আরেকটি child বানিয়ে নিজে সঙ্গে সঙ্গে শেষ হয়; parent সেই মাঝের child-কে wait করে, আর নাতি orphan হয়ে init-এর দায়িত্বে চলে যায়।
• Subreaper: Linux 3.4 থেকে একটি প্রসেস prctl(PR_SET_CHILD_SUBREAPER, 1) দিয়ে নিজেকে “ছোট init” ঘোষণা করতে পারে; তার বংশের orphan-রা PID 1-এর বদলে তার কাছে আসে। systemd-এর user সেশন আর অনেক container runtime এটি ব্যবহার করে।

৮ · fork-এর বিকল্প — vfork, posix_spawn, clone আর Windows-এর CreateProcess

fork + exec সুন্দর নকশা, কিন্তু অপচয়ও আছে: যে কপি পরের মুহূর্তেই exec দিয়ে ফেলে দেওয়া হবে, তার জন্য page table কপি করা, সব পাতা read-only চিহ্নিত করা — বড় প্রসেসে এটিই মিলিসেকেন্ড খরচ করে। তাই কয়েকটি বিকল্প আছে।

Linux kernel-এর ভেতরে fork, vfork, clone আর নতুন clone3 — সবাই শেষে একই ফাংশনে পৌঁছায়। সরলীকৃত রূপে:

kernel_clone(args)                 // fork, vfork, clone, clone3 all end here
    p = copy_process(args)
        dup_task_struct()          // new task_struct (the PCB) + kernel stack
        copy_files()               // CLONE_FILES ? share : copy the fd table
        copy_fs(), copy_sighand()  // share or copy cwd, signal handlers
        copy_mm()                  // CLONE_VM ? share mm : dup_mmap() + mark COW
        alloc_pid()                // a fresh PID
    wake_up_new_task(p)            // child goes onto a run queue
    if (CLONE_VFORK) wait_for_vfork_done()
    return pid of p                // the parent's return value
// the child returns to user mode with rax = 0

Windows-এর পথ: CreateProcess

Windows (NT পরিবার) fork-exec মডেল নেয়নি। সেখানে একটি call — CreateProcess — নতুন প্রসেস তৈরি করে, প্রোগ্রাম লোড করে, প্রথম থ্রেড চালু করে, সব একসাথে। Child কী কী উত্তরাধিকার পাবে (handle, environment, working directory, window), তা প্রায় দশটি parameter আর STARTUPINFO কাঠামো দিয়ে বলে দিতে হয়। নিচের কোড শুধু Windows-এ compile হয়, এই পাতায় চালানো যাবে না:

#include <windows.h>
#include <stdio.h>

int main(void) {
    STARTUPINFOW si = { sizeof si };
    PROCESS_INFORMATION pi;
    wchar_t cmd[] = L"cmd.exe /c dir";        /* must be writable */
    if (!CreateProcessW(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) {
        printf("CreateProcess failed: %lu\n", GetLastError());
        return 1;
    }
    WaitForSingleObject(pi.hProcess, INFINITE);  /* like waitpid */
    DWORD code;
    GetExitCodeProcess(pi.hProcess, &code);      /* like WEXITSTATUS */
    printf("exit code = %lu\n", code);
    CloseHandle(pi.hThread);                     /* release the process object */
    CloseHandle(pi.hProcess);
    return 0;
}

৯ · AI-এর যুগে fork, exec আর wait

“C-তে একটি mini shell লিখে দিন” — AI কয়েক সেকেন্ডে কোড দেবে, আর একটি-দুটি কমান্ডে তা চলবেও। প্রসেস API-র বাগ লুকিয়ে থাকে কিনারায়: বেশি কমান্ড চালালে zombie জমে, আউটপুট ফাইলে redirect করলে লাইন দুবার আসে, exec ব্যর্থ হলে দুটো shell একসাথে চলে। এই পর্বের জ্ঞান দিয়েই এগুলো ধরা যায়।

AI-এর লেখা প্রসেস-কোড চালানোর আগে — চেকলিস্ট

• AI-কে OS (Linux / macOS / Windows), compiler আর C library-র নাম বলেছি; উত্তরের API সেই OS-এরই কি না মিলিয়েছি
• fork, exec, waitpid — প্রতিটির ফেরত মান যাচাই আছে; exec-এর পরের লাইনে _exit আছে
• আউটপুট টার্মিনালে, pipe-এ (| cat) আর ফাইলে — তিনভাবেই চালিয়ে লাইনের সংখ্যা মিলিয়েছি
• একটানা অনেকবার চালিয়ে ps দিয়ে zombie (Z) গুনেছি; শূন্য থাকছে
• fork গোনার উত্তর AI দিলে নিজে fork tree এঁকে আর আসল রান দিয়ে (| wc -l) মিলিয়েছি
• অনেক প্রসেস তৈরির কোড পরীক্ষা করার আগে প্রসেস-সংখ্যার সীমা (ulimit -u বা cgroup-এর pids.max) দিয়ে নিজের সিস্টেম সুরক্ষিত রেখেছি