Signal — প্রসেসকে বার্তা পাঠানো আর সামলানো

১ · Signal কী — প্রসেসের দরজায় হঠাৎ টোকা

আগের পর্বে (পর্ব ১২) দেখেছেন, প্রসেসেরা pipe, shared memory বা socket দিয়ে অনেক ডেটা আদান-প্রদান করে। কিন্তু অনেক সময় ডেটা নয়, শুধু একটি ছোট খবর পাঠানো দরকার: “থামুন”, “আপনার কাজের সময় শেষ”, “আপনার child প্রসেস মারা গেছে”, “আপনি নিষিদ্ধ মেমরিতে হাত দিয়েছেন”। এই ধরনের ছোট, হঠাৎ আসা বার্তার নাম signal.

OS-এর ভাষায়, signal হলো kernel-এর মাধ্যমে একটি প্রসেসকে পাঠানো একটি ছোট সংখ্যা (১, ২, ৯, ১৫…), প্রতিটি সংখ্যার একটি নাম আছে (SIGINT, SIGKILL, SIGTERM…). Signal-এর সাথে সাধারণত আর কোনো ডেটা যায় না — শুধু “কোন signal” এই তথ্যটুকু। দুটি বৈশিষ্ট্য একে আলাদা করে:

• Asynchronous (অসমলয়): প্রসেস যেকোনো instruction-এর মাঝখানে থাকতে পারে, আর signal ঠিক তখনই এসে তার স্বাভাবিক কাজ থামিয়ে দিতে পারে। প্রসেস একে “অপেক্ষা করে পড়ে” না, যেমন pipe থেকে read() করে।
• সংক্ষিপ্ত: signal শুধু একটি ঘটনা জানায়। কে পাঠাল, কেন — এসব বাড়তি তথ্য চাইলে বিশেষ ব্যবস্থা লাগে (অংশ ৫-এ SA_SIGINFO).

Software interrupt — হার্ডওয়্যার interrupt-এর ছোট ভাই

পর্ব ৪-এ দেখেছেন, হার্ডওয়্যার interrupt এলে CPU চলতি কাজ থামিয়ে kernel-এর একটি নির্দিষ্ট handler চালায়, তারপর আগের জায়গায় ফেরে। Signal হুবহু একই ধারণা, শুধু এক স্তর ওপরে — CPU-র বদলে প্রসেস, আর হার্ডওয়্যারের বদলে kernel. তুলনাটি পাশাপাশি দেখুন:

একটি সূক্ষ্ম পার্থক্যও আছে। কিছু signal আসলে synchronous — প্রসেসের নিজের একটি instruction-এর কারণে তৈরি, যেমন শূন্য দিয়ে ভাগ করলে SIGFPE, ভুল ঠিকানায় পড়লে SIGSEGV. CPU তখন একটি exception তোলে, kernel সেটিকে signal-এ রূপ দেয়। আর Ctrl+C বা অন্য প্রসেসের kill() থেকে আসা signal asynchronous — প্রসেসের কাজের সাথে কোনো সম্পর্ক নেই। এজন্যই অনেক বই signal-কে বলে “software interrupt”, যদিও পর্ব ৫-এর trap-কেও কখনো একই নামে ডাকা হয় — প্রসঙ্গ দেখে বুঝে নিতে হয়।

২ · Signal কোথা থেকে আসে — তিনটি উৎস

Kernel-এর তৈরি কয়েকটি signal বাস্তবে খুব চেনা। একটি C প্রোগ্রাম NULL পয়েন্টার থেকে পড়লে CPU page fault তোলে; kernel দেখে ঠিকানাটি প্রসেসের কোনো বৈধ এলাকায় নেই (পর্ব ৩৫), তাই SIGSEGV পাঠায় — আর আপনি দেখেন “Segmentation fault (core dumped)”. আবার yes | head -n 1 চালালে head একটি লাইন পড়েই বেরিয়ে যায়; এরপর yes আর লেখার জায়গা পায় না, kernel তাকে SIGPIPE দেয় আর সে চুপচাপ শেষ হয়। এজন্যই pipeline-এর শেষ অংশ থামলে পুরো pipeline নিজে থেকে গুটিয়ে যায়।

অন্য প্রসেসের signal পাঠানোর অনুমতি নিয়ে একটি কথা: আপনি শুধু নিজের প্রসেসগুলোকেই signal পাঠাতে পারেন। অন্য ব্যবহারকারীর প্রসেসকে পাঠাতে root বা Linux-এর CAP_KILL ক্ষমতা লাগে (permission নিয়ে বিস্তারিত পর্ব ৪৭-এ)। নইলে যে কেউ সার্ভারের ডেটাবেস বন্ধ করে দিতে পারত। আর kill(pid, 0) কোনো signal পাঠায় না, শুধু যাচাই করে প্রসেসটি আছে কি না আর পাঠানোর অনুমতি আছে কি না।

Ctrl+C চাপলে আসলে কী ঘটে

টার্মিনালে একটি লম্বা কাজ চলছে: sort big.txt | uniq. আপনি Ctrl+C চাপলেন, দুটো প্রোগ্রামই থেমে গেল, shell আবার prompt দেখাল। এর পেছনে কয়েকটি স্তর কাজ করে — আর সবচেয়ে গুরুত্বপূর্ণ খেলোয়াড় হলো tty driver-এর line discipline আর process group. ধাপে ধাপে দেখুন:

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; susp = ^Z;
... isig icanon echo ...

  PID  PGID TPGID STAT COMMAND
 4012  4012  4100 Ss   bash
 4100  4100  4100 R+   sort
 4101  4100  4100 S+   uniq

sort (4100): SIGINT, no handler -> terminate
uniq (4101): SIGINT, no handler -> terminate

$ sort big.txt | uniq
^C
$ echo $?
130

Ctrl+Z-এর পথ একই, শুধু signal আলাদা: SIGTSTP (Terminal SToP). এর default action প্রসেসকে থামিয়ে রাখা, শেষ করা নয়। পরে fg বা bg দিলে shell সেই group-কে SIGCONT পাঠায়, আর কাজ যেখানে থেমেছিল সেখান থেকে চলে। Ctrl+\ দেয় SIGQUIT, যা প্রসেস শেষ করার সাথে একটি core dump-ও তৈরি করতে পারে — debugging-এর জন্য মেমরির ছবি।

৩ · সাধারণ signal-এর তালিকা আর default action

প্রতিটি signal-এর একটি default action আছে — প্রসেস নিজে কিছু না বললে kernel যা করে। পাঁচ রকম default action:

• Term: প্রসেস শেষ।
• Core: প্রসেস শেষ, সাথে core dump (চালু থাকলে)।
• Ign: কিছুই না, signal ফেলে দেওয়া হয়।
• Stop: প্রসেস থেমে থাকে (মারা যায় না)।
• Cont: থেমে থাকা প্রসেস আবার চলে।

নিচের টেবিলের নম্বরগুলো Linux x86-64-এর (ARM64 Linux-এও এগুলো একই)। macOS আর BSD-তে ১, ২, ৩, ৬, ৯, ১৪, ১৫-এর মতো পুরোনো নম্বর মেলে, কিন্তু অনেকগুলো আলাদা — যেমন macOS-এ SIGUSR1 = 30, SIGCHLD = 20. তাই কোডে সবসময় নাম লিখুন, নম্বর নয়।

Linux kernel-এ real-time signal শুরু ৩২ থেকে; কিন্তু glibc ৩২ আর ৩৩ নিজের থ্রেড-লাইব্রেরির জন্য রেখে দেয়, তাই প্রোগ্রাম SIGRTMIN দেখে ৩৪ — অংশ ৪-এর প্রোগ্রামের আউটপুটেই এটি দেখবেন। এজন্যই SIGRTMIN একটি ধ্রুবক নয়, glibc-তে একটি ফাংশন-কল।

SIGKILL আর SIGSTOP কেন ধরা যায় না

বাকি প্রায় সব signal-এর জন্য প্রসেস নিজের handler বসাতে পারে, বা উপেক্ষা করতে পারে। শুধু দুটি ব্যতিক্রম: SIGKILL (৯) আর SIGSTOP (১৯). এদের জন্য sigaction() ডাকলে kernel EINVAL দিয়ে প্রত্যাখ্যান করে, mask-এ রাখলেও কাজ হয় না। কারণটি নকশাগত:

তাই SIGKILL পুরো কাজটি kernel-এর ভেতরেই সারে: প্রসেসের কোনো কোড আর চলে না, handler নেই, cleanup নেই। এর মানে ঝুঁকিও আছে — অর্ধেক লেখা ফাইল, মুছে না-ফেলা temp ফাইল, ছেড়ে না-দেওয়া lock ফাইল রয়ে যায়। তবে kernel প্রসেসের সব মেমরি আর খোলা file descriptor ঠিকই ফেরত নেয়। একইভাবে SIGSTOP প্রশাসককে যেকোনো প্রসেস নিশ্চিতভাবে থামিয়ে রাখার ক্ষমতা দেয় — debugger-ও এটি ব্যবহার করে।

৪ · Signal-এর জীবনচক্র — তৈরি, অপেক্ষা আর পৌঁছানো

একটি signal-এর জীবনের তিনটি অবস্থা আলাদা করে চেনা জরুরি, কারণ পরীক্ষা আর বাস্তব বাগ — দুই জায়গাতেই প্রশ্ন আসে এই ফাঁক নিয়ে:

1. Generation (তৈরি): কোনো ঘটনা ঘটল — kill() ডাকা হলো, Ctrl+C চাপা হলো, child শেষ হলো। Kernel লক্ষ্য-প্রসেসের রেকর্ডে (PCB, পর্ব ৮) signal-টি লিখে রাখে।
2. Pending (অপেক্ষমাণ): signal তৈরি হয়েছে কিন্তু এখনো প্রসেসের হাতে পৌঁছায়নি। প্রতিটি প্রসেসের একটি pending set থাকে — সাধারণ signal-এর জন্য প্রতি signal-এ মাত্র এক বিট.
3. Delivery (পৌঁছানো): kernel signal-টির ব্যবস্থা নেয় — handler চালায়, উপেক্ষা করে, বা default action করে। সাধারণত এটি ঘটে যখন প্রসেস kernel থেকে user mode-এ ফেরে (system call শেষে, interrupt শেষে, বা CPU পেয়ে)।

এর সাথে আছে signal mask (blocked set): প্রসেস যে signal-গুলো আপাতত নিতে চায় না, তার তালিকা। Mask-এ থাকা signal তৈরি হতে পারে, pending-ও হয়, কিন্তু যতক্ষণ block থাকে ততক্ষণ পৌঁছায় না। মনে রাখুন, block মানে ignore নয়: ignore করা signal ফেলে দেওয়া হয়, block করা signal অপেক্ষা করে আর unblock হলেই পৌঁছায়। Mask বদলানোর system call sigprocmask() (থ্রেডের জন্য pthread_sigmask()).

নিচের ডায়াগ্রামে একটি প্রসেস SIGUSR1 block করে, তারপর দুবার SIGUSR1 আর একবার SIGINT পায়। প্রতিটি ধাপে mask আর pending set কীভাবে বদলায়, আর কোন handler কতবার চলে, খেয়াল করুন।

1main(): handlers set for USR1, INT2sigprocmask(SIG_BLOCK, {USR1})3kill(getpid(), SIGUSR1);  // #14kill(getpid(), SIGUSR1);  // #25kill(getpid(), SIGINT);6kernel -> user: deliver INT7on_int() returns (sigreturn)8sigprocmask(SIG_UNBLOCK, {USR1})9back in main()

Real-time signal — যেগুলো সারি বেঁধে থাকে

“Signal হারিয়ে যায়” সমস্যার সমাধান হিসেবে ১৯৯০-এর দশকে POSIX real-time extension-এ আসে real-time signal (SIGRTMIN থেকে SIGRTMAX). এদের তিনটি বাড়তি গুণ: প্রতিটি পাঠানো signal আলাদাভাবে সারিতে জমা থাকে (একটি সীমা পর্যন্ত), sigqueue() দিয়ে signal-এর সাথে একটি ছোট সংখ্যা বা পয়েন্টারও পাঠানো যায়, আর একাধিক real-time signal pending থাকলে ছোট নম্বরেরটি আগে পৌঁছায়। এবার আসল মেশিনে দেখি — একটি সাধারণ আর একটি real-time signal, দুটোই block করে তিনবার করে পাঠানো:

#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static volatile sig_atomic_t n_usr1 = 0, n_rt = 0;
static int RT;                                   /* SIGRTMIN, set in main */

static void on_sig(int sig) { if (sig == SIGUSR1) n_usr1++; else n_rt++; }

static void show(const char *when) {
    sigset_t p;
    sigpending(&p);
    printf("%-22s pending: USR1=%s RT=%s | handler ran: USR1 %d, RT %d\n", when,
           sigismember(&p, SIGUSR1) ? "yes" : "no ", sigismember(&p, RT) ? "yes" : "no ",
           (int)n_usr1, (int)n_rt);
}

int main(void) {
    RT = SIGRTMIN;
    struct sigaction sa;
    memset(&sa, 0, sizeof sa);
    sa.sa_handler = on_sig;
    sigemptyset(&sa.sa_mask);
    sigaction(SIGUSR1, &sa, NULL);  sigaction(RT, &sa, NULL);

    sigset_t block, old;
    sigemptyset(&block);  sigaddset(&block, SIGUSR1);  sigaddset(&block, RT);
    sigprocmask(SIG_BLOCK, &block, &old);       /* put both in the mask */
    show("blocked, nothing sent");

    for (int i = 0; i < 3; i++) { kill(getpid(), SIGUSR1); kill(getpid(), RT); }
    show("sent each 3 times");
    sigprocmask(SIG_SETMASK, &old, NULL);       /* unblock: delivery now */
    show("after unblocking");
    printf("SIGUSR1 = %d, SIGRTMIN = %d, SIGRTMAX = %d\n", SIGUSR1, RT, SIGRTMAX);
    return 0;
}

blocked, nothing sent  pending: USR1=no  RT=no  | handler ran: USR1 0, RT 0
sent each 3 times      pending: USR1=yes RT=yes | handler ran: USR1 0, RT 0
after unblocking       pending: USR1=no  RT=no  | handler ran: USR1 1, RT 3
SIGUSR1 = 10, SIGRTMIN = 34, SIGRTMAX = 64

এই “জমা না হওয়া”র সবচেয়ে চেনা ফল দেখা যায় SIGCHLD-এ। একটি সার্ভারের দুটি child প্রায় একসাথে শেষ হলে parent একটিমাত্র SIGCHLD পেতে পারে। Handler যদি ধরে নেয় “একটি signal = একটি child” আর একবারই wait করে, দ্বিতীয় child zombie হয়ে পড়ে থাকবে। সমাধান অংশ ৬-এ।

৫ · Signal ধরা — signal() বনাম sigaction()

প্রতিটি signal-এর জন্য প্রসেস তিনটি “disposition”-এর একটি বেছে নিতে পারে: SIG_DFL (default action), SIG_IGN (উপেক্ষা), অথবা নিজের একটি ফাংশন — signal handler. এটি বসানোর দুটি API আছে।

গুরুত্বপূর্ণ কয়েকটি flag:

• SA_RESTART: handler চলার সময় প্রসেস যদি কোনো “ধীর” system call-এ (টার্মিনাল বা pipe থেকে read, wait) আটকে থাকে, handler শেষে kernel সেই call নিজে থেকে আবার শুরু করে। না দিলে call ফেরে −1, errno = EINTR (অংশ ৬)।
• SA_SIGINFO: তিন-argument-এর handler void h(int sig, siginfo_t *info, void *ctx) চলে। info-তে থাকে কে পাঠাল (si_pid, si_uid), কেন (si_code), আর SIGSEGV-এর ক্ষেত্রে কোন ঠিকানায় ভুল হয়েছিল (si_addr).
• SA_NOCLDSTOP, SA_NOCLDWAIT: SIGCHLD-এর জন্য — child থামলে signal নয়, শুধু শেষ হলে; অথবা child-কে zombie-ই না হতে দেওয়া।
• SA_RESETHAND, SA_NODEFER: পুরোনো unreliable আচরণ ইচ্ছে করে চাইলে — সাধারণত দরকার হয় না।

এবার একটি সম্পূর্ণ উদাহরণ। প্রোগ্রামটি একটি লুপে “কাজ” করে, আর তৃতীয় কাজের পর নিজেকেই SIGINT পাঠায় — যেন কেউ Ctrl+C চেপেছে। Handler শুধু একটি flag বসায়; লুপ সেই flag দেখে ভদ্রভাবে থামে। শেষে SIG_IGN বসিয়ে দেখায়, উপেক্ষিত signal কিছুই করে না।

#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static volatile sig_atomic_t stop = 0;      /* the only thing we share */

static void on_sigint(int sig) {
    (void)sig;
    static const char msg[] = "  [handler] SIGINT arrived, setting stop = 1\n";
    write(STDOUT_FILENO, msg, sizeof msg - 1);  /* write() is async-signal-safe */
    stop = 1;
}

int main(void) {
    struct sigaction sa;
    memset(&sa, 0, sizeof sa);
    sa.sa_handler = on_sigint;
    sigemptyset(&sa.sa_mask);           /* block nothing extra in the handler */
    sa.sa_flags = SA_RESTART;           /* restart slow syscalls after it */
    if (sigaction(SIGINT, &sa, NULL) == -1) { perror("sigaction"); return 1; }

    printf("SIGINT is signal number %d\n", SIGINT);
    for (int job = 1; !stop; job++) {   /* main loop checks the flag */
        printf("working on job %d\n", job);
        fflush(stdout);
        if (job == 3) kill(getpid(), SIGINT);   /* as if Ctrl+C was pressed */
    }
    printf("main: flag seen, saving state and exiting cleanly\n");

    signal(SIGINT, SIG_IGN);            /* now ignore it completely */
    raise(SIGINT);
    printf("main: raise(SIGINT) while ignored -> nothing happened\n");
    return 0;
}

SIGINT is signal number 2
working on job 1
working on job 2
working on job 3
  [handler] SIGINT arrived, setting stop = 1
main: flag seen, saving state and exiting cleanly
main: raise(SIGINT) while ignored -> nothing happened

৬ · Handler-এর ভেতরে কী করা নিরাপদ

Signal handler সাধারণ ফাংশনের মতো দেখতে, কিন্তু সে চলে একটি অদ্ভুত মুহূর্তে — main-এর যেকোনো instruction-এর মাঝখানে. main হয়তো তখন printf-এর ভেতরে, stdout-এর buffer অর্ধেক বদলেছে আর buffer-এর lock ধরে রেখেছে। বা malloc-এর ভেতরে heap-এর তালিকা অর্ধেক জোড়া। এখন handler-ও যদি printf বা malloc ডাকে?

বাস্তবে যা হতে পারে: (১) Deadlock — glibc-র printf stdout-এর একটি lock নেয়; main সেই lock ধরে থাকা অবস্থায় handler আবার একই lock চাইলে প্রসেস চিরকাল আটকে থাকে। (২) নষ্ট ডেটা — lock না থাকলেও buffer-এর অর্ধেক-বদলানো অবস্থা handler আরও এলোমেলো করে দেয়, লেখা দুবার আসে বা হারায়। malloc-এর ক্ষেত্রে heap-এর কাঠামো নষ্ট হয়ে পরে অদ্ভুত crash. সমস্যাটি সবচেয়ে বিপজ্জনক কারণ এটি কদাচিৎ ঘটে: হাজারবার ঠিক চলে, একবার — signal ঠিক ভুল মুহূর্তে এলে — সার্ভার আটকে যায়।

Flag-এর ধরন: volatile sig_atomic_t

Flag-টি সাধারণ int নয়, volatile sig_atomic_t — দুটি শব্দেরই কাজ আছে। sig_atomic_t এমন একটি পূর্ণসংখ্যার ধরন, যা একটি instruction-এই পড়া বা লেখা হয়; signal এসে অর্ধেক-লেখা মান দেখতে পায় না। volatile compiler-কে বলে, “এই ভ্যারিয়েবল বাইরে থেকে যেকোনো মুহূর্তে বদলাতে পারে, তাই প্রতিবার মেমরি থেকেই পড়তে হবে”। না দিলে optimizer দেখে লুপের ভেতরে stop কেউ বদলায় না, তাই মানটি একবার register-এ তুলে চিরকাল সেটিই দেখে — লুপ কখনো থামে না। -O0-এ ঠিক চলে, -O2-এ আটকে যায় — এমন বাগ প্রায়ই এভাবেই জন্মায়। (মনে রাখুন, থ্রেডের মধ্যে ভাগ করা ডেটার জন্য volatile যথেষ্ট নয়; সেখানে atomic আর lock লাগে — পর্ব ২৩।)

EINTR — handler-এর পর বাধা পাওয়া system call

প্রসেস ধরুন read(0, buf, 100)-এ ব্যবহারকারীর ইনপুটের অপেক্ষায় ঘুমিয়ে আছে। এমন সময় একটি signal এল আর handler চলল। Handler ফেরার পর read-এর কী হবে? দুটি সম্ভাবনা:

• SA_RESTART ছাড়া: read ফেরে −1, errno = EINTR (“Interrupted system call”). প্রোগ্রামকে নিজে আবার ডাকতে হয়, নইলে সে ভাববে আসল ত্রুটি ঘটেছে।
• SA_RESTART দিলে: kernel নিজে থেকে read আবার শুরু করে, প্রোগ্রাম কিছুই টের পায় না। তবে কিছু call — যেমন poll, select, epoll_wait আর nanosleep-এর মতো ঘুমের call — Linux-এ SA_RESTART থাকলেও আবার শুরু হয় না, EINTR দেয়।

এজন্য নির্ভরযোগ্য systems কোডে এই ধাঁচ খুব চেনা: while ((n = read(fd, buf, len)) == -1 && errno == EINTR) ;. আর মাঝে মাঝে EINTR-ই কাম্য: একটি সার্ভার SA_RESTART ছাড়া SIGTERM ধরলে তার accept() বা poll() EINTR দিয়ে ফেরে, তখন লুপ flag দেখে বন্ধের প্রস্তুতি নিতে পারে।

SIGCHLD দিয়ে zombie পরিষ্কার

পর্ব ১০-এ দেখেছেন, child শেষ হলে parent wait না করা পর্যন্ত সে zombie হয়ে থাকে। একটি সার্ভার, যে অনেক child চালায়, প্রতিবার আটকে থেকে wait করতে পারে না। তাই সে SIGCHLD-এর handler বসায়, আর handler-এর ভেতরে যতগুলো child শেষ হয়েছে সবাইকে তোলে। এটি হাতে-লেখা কোড (চালানো যায় না, তবে বাস্তবে এভাবেই লেখা হয়):

#include <errno.h>
#include <signal.h>
#include <sys/wait.h>

static void on_sigchld(int sig) {
    (void)sig;
    int saved = errno;                 /* waitpid may change errno: save it */
    while (waitpid(-1, NULL, WNOHANG) > 0)
        ;                              /* reap EVERY finished child, not one */
    errno = saved;                     /* main must not see a changed errno */
}

/* in main():
   struct sigaction sa = {0};
   sa.sa_handler = on_sigchld;
   sigemptyset(&sa.sa_mask);
   sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
   sigaction(SIGCHLD, &sa, NULL);                                   */

তিনটি বিষয় খেয়াল করুন। লুপ: দুটি child প্রায় একসাথে শেষ হলে SIGCHLD একবারই আসতে পারে (অংশ ৪), তাই একবার নয়, যতক্ষণ পাওয়া যায় ততক্ষণ waitpid. WNOHANG: আর কোনো শেষ-হওয়া child না থাকলে আটকে না থেকে 0 ফেরত দেয় — handler-এ ঘুমিয়ে পড়া চলবে না। errno সংরক্ষণ: main হয়তো ঠিক তখন একটি ব্যর্থ call-এর errno পড়তে যাচ্ছিল; handler-এর waitpid সেটি বদলে দিলে main ভুল কারণ দেখবে। আর যদি child-এর exit status একেবারেই দরকার না হয়, POSIX-এ আরও সহজ পথ আছে: SIGCHLD-কে স্পষ্টভাবে SIG_IGN করলে বা SA_NOCLDWAIT দিলে child-রা zombie-ই হয় না।

৭ · প্রসেস থামানো — kill, SIGTERM বনাম SIGKILL, আর exit status

Shell-এর kill কমান্ড শুধু kill() system call-এর একটি সহজ রূপ। কয়েকটি ব্যবহার:

kill 4100            # default: SIGTERM (15), a polite request
kill -TERM 4100      # same thing, written out
kill -INT 4100       # like Ctrl+C for that process
kill -9 4100         # SIGKILL: last resort, no cleanup possible
kill -STOP 4100      # freeze it; kill -CONT 4100 to continue
kill -TERM -- -4100  # negative number: the whole process group 4100
kill -l              # list all signal names and numbers
pkill -TERM nginx    # by name (procps); killall does the same

প্রথম নিয়মটি পেশাদার সিস্টেম প্রশাসকেরা মুখস্থ রাখেন: আগে SIGTERM, অপেক্ষা, তারপরই কেবল SIGKILL. SIGTERM প্রোগ্রামকে সুযোগ দেয় — অর্ধেক লেখা ফাইল শেষ করা, ডেটাবেসের লেনদেন (transaction) গুছিয়ে নেওয়া, temp ফাইল মোছা, client-কে “বন্ধ হচ্ছি” জানানো। সরাসরি kill -9 সেই সুযোগ কেড়ে নেয়।

১২৮ + n — signal-এ মৃত্যুর চিহ্ন

পর্ব ১০-এ দেখেছেন, parent waitpid() দিয়ে child-এর শেষ হওয়ার খবর পায়, আর WIFEXITED / WEXITSTATUS দিয়ে স্বাভাবিক exit status পড়ে। Child signal-এ মারা গেলে WIFSIGNALED সত্য হয়, আর WTERMSIG বলে কোন signal. Shell সেই তথ্য একটি সংখ্যায় বসায়: $? = ১২৮ + signal নম্বর.

এবার নিজের চোখে দেখি। প্রোগ্রামটি SIGTERM-এর একটি handler বসিয়ে দুটি child তৈরি করে (fork-এর পর child handler উত্তরাধিকারসূত্রে পায়)। প্রথম child-কে SIGTERM, দ্বিতীয়টিকে SIGKILL পাঠায়, আর waitpid দিয়ে দুজনের পরিণতি পড়ে। শুরুতেই চেষ্টা করে SIGKILL-এর handler বসাতে:

#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/wait.h>
#include <unistd.h>
static void on_term(int sig) {
    (void)sig;
    static const char m[] = "  child: got SIGTERM, closing files, exit(3)\n";
    write(STDOUT_FILENO, m, sizeof m - 1);
    _exit(3);                              /* _exit is async-signal-safe */
}

static void run_child(const char *name, int sig) {
    fflush(stdout);                        /* empty the buffer before fork */
    pid_t pid = fork();
    if (pid == 0) for (;;) pause();        /* child: just wait for signals */
    int st;
    kill(pid, sig);  waitpid(pid, &st, 0);
    if (WIFEXITED(st))
        printf("%s: exited normally, status %d\n", name, WEXITSTATUS(st));
    else if (WIFSIGNALED(st))
        printf("%s: killed by signal %d (%s); a shell shows $? = %d\n",
               name, WTERMSIG(st), strsignal(WTERMSIG(st)), 128 + WTERMSIG(st));
}

int main(void) {
    struct sigaction sa;
    memset(&sa, 0, sizeof sa);
    sa.sa_handler = on_term;  sigemptyset(&sa.sa_mask);
    sigaction(SIGTERM, &sa, NULL);         /* children inherit the handler */
    if (sigaction(SIGKILL, &sa, NULL) == -1)
        printf("sigaction(SIGKILL) refused: %s\n", strerror(errno));
    run_child("child A (SIGTERM)", SIGTERM);   /* polite request */
    run_child("child B (SIGKILL)", SIGKILL);   /* cannot be caught */
    return 0;
}

sigaction(SIGKILL) refused: Invalid argument
  child: got SIGTERM, closing files, exit(3)
child A (SIGTERM): exited normally, status 3
child B (SIGKILL): killed by signal 9 (Killed); a shell shows $? = 137

Shell script-এ signal — trap

Bash script-ও signal ধরতে পারে trap দিয়ে। trap 'কমান্ড' TERM মানে “SIGTERM এলে এই কমান্ড চালানো হবে”; আর EXIT একটি ছদ্ম-signal, যা script যেভাবেই শেষ হোক (SIGKILL ছাড়া) একবার চলে — temp ফাইল মোছার আদর্শ জায়গা। নিচের script-এ একটি “worker” trap বসিয়ে চলে, আর মূল script তাকে SIGTERM পাঠায়; তারপর trap ছাড়া প্রসেসের exit code দেখায়:

echo "== names and numbers =="
echo "INT=$(kill -l INT) TERM=$(kill -l TERM) KILL=$(kill -l KILL) CHLD=$(kill -l CHLD)"
echo "exit code 143 means: SIG$(kill -l 143), 137 means: SIG$(kill -l 137)"

echo "== a worker that traps TERM and EXIT =="
bash -c '
  trap "echo \"  worker: SIGTERM received, saving progress\"; exit 0" TERM
  trap "echo \"  worker: EXIT trap, temp files removed\"" EXIT
  echo "  worker: started"
  while true; do sleep 0.1; done
' &
w=$!
sleep 0.3
kill -TERM "$w"                 # same as plain: kill $w
s=0; wait "$w" || s=$?
echo "worker exit status: $s (handled, so it chose 0)"

echo "== processes with no trap =="
( sleep 5 & p=$!; kill -TERM "$p"; s=0; wait "$p" || s=$?
  echo "sleep + SIGTERM -> exit status $s"
  sleep 5 & p=$!; kill -KILL "$p"; s=0; wait "$p" || s=$?
  echo "sleep + SIGKILL -> exit status $s" ) 2>/dev/null

== names and numbers ==
INT=2 TERM=15 KILL=9 CHLD=17
exit code 143 means: SIGTERM, 137 means: SIGKILL
== a worker that traps TERM and EXIT ==
  worker: started
  worker: SIGTERM received, saving progress
  worker: EXIT trap, temp files removed
worker exit status: 0 (handled, so it chose 0)
== processes with no trap ==
sleep + SIGTERM -> exit status 143
sleep + SIGKILL -> exit status 137

৮ · Graceful shutdown — docker stop আর systemctl stop-এর ভেতরে

বাস্তব সার্ভারে প্রসেস বন্ধ করতে প্রায় কেউ হাতে kill দেন না; দেন service manager বা container runtime. সবার পদ্ধতি মূলত এক: SIGTERM → নির্দিষ্ট সময় অপেক্ষা → তখনও বেঁচে থাকলে SIGKILL. একে বলে graceful shutdown.

একটি ভালো আচরণের সার্ভার SIGTERM পেলে সাধারণত এই কাজগুলো করে: নতুন সংযোগ নেওয়া বন্ধ (listening socket বন্ধ, বা load balancer-কে “আমি আর প্রস্তুত নই” জানানো), চলমান অনুরোধগুলো শেষ করা, লগ আর ডেটা flush, ডেটাবেসের সংযোগ বন্ধ, তারপর exit 0. Kubernetes-এর মতো পরিবেশে এটি না করলে প্রতিটি deploy-এর সময় কিছু ব্যবহারকারী ভাঙা অনুরোধ পান।

নিচের ডায়াগ্রামে দুটি container বন্ধ করা দেখুন — একটি ঠিকভাবে বানানো, আরেকটি একটি পরিচিত ভুলসহ:

1$ docker stop web        # PID 1 = node server.js2dockerd -> PID 1: SIGTERM3handler: stopping = 1; close listener4finish 12 requests, flush logs, close DB5exit(0)  -> container exited (0)6$ docker stop old-web    # PID 1 = /bin/sh -c "node ..."7sh (PID 1): no handler -> SIGTERM dropped810 s timeout -> SIGKILL9container exited (137)

systemd-এও একই গল্প, শুধু শব্দ আলাদা। systemctl stop ডিফল্টে service-এর cgroup-এর সব প্রসেসকে SIGTERM দেয় (পরে SIGCONT-ও, যাতে থেমে থাকা প্রসেস signal-টি সামলাতে পারে), TimeoutStopSec পর্যন্ত অপেক্ষা করে, তারপর SIGKILL. সময় পেরোলে journal-এ এমন লাইন দেখা যায় (উদাহরণ; সংস্করণভেদে ভাষা সামান্য আলাদা):

myapp.service: State 'stop-sigterm' timed out. Killing.
myapp.service: Killing process 2311 (myapp) with signal SIGKILL.
myapp.service: Main process exited, code=killed, status=9/KILL
myapp.service: Failed with result 'timeout'.

অনেক daemon আরও কিছু signal-কে নিজস্ব অর্থ দেয়। যেমন nginx-এ SIGHUP মানে “config আবার পড়ুন” (চলমান সংযোগ না ভেঙে), আর SIGQUIT মানে graceful shutdown; nginx -s reload ভেতরে আসলে master প্রসেসকে SIGHUP-ই পাঠায়। কোন signal-এ কী হয়, তা প্রতিটি প্রোগ্রামের ডকুমেন্টেশনে দেখে নিতে হয় — সবার নিয়ম এক নয়।

৯ · Windows আর macOS-এ — সবখানে কি signal আছে?

macOS আর FreeBSD-এর মতো BSD-বংশের সিস্টেমে signal প্রায় হুবহু একই — একই নাম, একই sigaction, তবে অংশ ৩-এ যেমন বলেছি, অনেক নম্বর আলাদা। কিছু ছোট পার্থক্যও আছে, যেমন BSD-তে SIGINFO নামে একটি বাড়তি signal (টার্মিনালে Ctrl+T), যা Linux-এ নেই।

Windows-এর গল্প সম্পূর্ণ আলাদা। Windows NT kernel-এ Unix-ধাঁচের signal নেই। একই কাজগুলো সেখানে ভিন্ন ভিন্ন ব্যবস্থায় হয় (বিস্তারিত পর্ব ৫৬-এ):

Microsoft-এর C runtime একটি signal() ফাংশন দেয় (SIGINT, SIGTERM, SIGSEGV ইত্যাদি নামসহ), কারণ ISO C এটি দাবি করে; কিন্তু এটি ওপরের ব্যবস্থাগুলোর ওপর একটি পাতলা অনুকরণ, POSIX-এর পূর্ণ আচরণ নয় — যেমন Windows নিজে কখনো কোনো প্রসেসকে SIGTERM পাঠায় না। Cygwin বা পুরোনো WSL1-এর মতো স্তর Windows-এর ওপর POSIX signal অনুকরণ করেছে; WSL2-এ ভেতরে একটি আসল Linux kernel চলে, তাই সেখানে signal পুরোপুরি Linux-এর মতো। তাই cross-platform প্রোগ্রাম লিখলে “Ctrl+C-তে ভদ্রভাবে বন্ধ” কাজটি দুই OS-এ আলাদাভাবে লিখতে হয়, অথবা এমন library ব্যবহার করতে হয় যা দুটোকে এক interface-এ আনে।

১০ · AI-এর যুগে signal

“আমার C সার্ভারে Ctrl+C-তে ভদ্রভাবে বন্ধ হওয়ার কোড লিখে দিন” — AI প্রায় সবসময় একটি চলনসই উত্তর দেবে, আর আপনার ল্যাপটপে সেটি হাজারবার ঠিকঠাক চলবে। Signal-এর বাগ ঠিক এই কারণেই বিপজ্জনক: এরা সময়-নির্ভর, কদাচিৎ ঘটে, আর ছোট পরীক্ষায় ধরা পড়ে না। AI-এর লেখা কোডে যা প্রায়ই দেখা যায়:

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

• লক্ষ্য-OS (Linux, macOS না Windows) আর distro প্রম্পটে বলেছি; উত্তরের signal নাম ও নম্বর সেই OS-এর kill -l দিয়ে মিলিয়েছি
• Handler-এর প্রতিটি ফাংশন async-signal-safe তালিকায় আছে; flag volatile sig_atomic_t; handler-এ errno সংরক্ষণ করা হয়
• -O2 দিয়ে compile করে চালিয়েছি, আর লুপের মধ্যে বারবার signal পাঠিয়ে (একটি ছোট script দিয়ে শত শতবার) পরীক্ষা করেছি
• kill -TERM দিয়ে বন্ধ করে exit code আর বন্ধ হতে লাগা সময় মেপেছি; container-এ docker stop-এর সময় ১০ সেকেন্ডের অনেক কম কি না দেখেছি
• ps-এ zombie (STAT Z) জমছে না, তা লোড দিয়ে যাচাই করেছি
• kill -9, sudo বা সুরক্ষা-ব্যবস্থা বন্ধের কোনো পরামর্শ বিনা কারণে মানিনি