Shell কীভাবে কাজ করে — job control, ps, top আর /proc

১ · Shell আসলে একটি লুপ — পড়া, ভাঙা, fork, exec, অপেক্ষা

পর্ব ০৩-এ আপনি terminal-এ কমান্ড চালিয়েছেন, আর একটি pipeline-এর ভেতরে shell কীভাবে fd জোড়ে, তা দেখেছেন। পর্ব ১০-এ দেখেছেন fork, exec আর wait — process তৈরি আর শেষের তিনটি মূল system call. এই পর্বে দুটি জোড়া লাগাব: shell নিজে কীভাবে এই তিনটি দিয়ে তৈরি, আর একসাথে অনেক process চললে আপনি সেগুলো কীভাবে দেখবেন, থামাবেন, আবার চালাবেন।

যেকোনো shell — bash, zsh, dash, এমনকি পর্ব ৫৯-এর ক্যাপস্টোনে আপনার নিজের লেখা shell — মূলত একটি অন্তহীন লুপ:

1. পড়া (read): prompt দেখিয়ে stdin থেকে একটি লাইন পড়া। ইনপুট শেষ হলে (Ctrl+D, অর্থাৎ EOF) লুপ শেষ।
2. ভাঙা (parse): লাইনটিকে শব্দে ভাঙা, উদ্ধৃতিচিহ্ন, |, >, & চেনা, variable আর wildcard বদলানো।
3. Builtin কি না দেখা: কমান্ডটি shell-এর নিজের অবস্থা বদলায় এমন কিছু হলে (cd, exit, export) shell নিজেই কাজটি করে, কোনো নতুন process ছাড়া।
4. fork: না হলে নিজের একটি কপি, অর্থাৎ child process তৈরি।
5. exec (child-এ): child নিজের ভেতরে নতুন প্রোগ্রামটি বসায় — PATH-এ খুঁজে /usr/bin/ls.
6. wait (parent-এ): shell waitpid দিয়ে child শেষ হওয়ার অপেক্ষা করে, exit status নিয়ে $?-এ রাখে, তারপর আবার ধাপ ১-এ।

কোন কাজ shell-এর ভেতরেই করতে হয়

পর্ব ০৩-এ দেখেছেন, cd আলাদা প্রোগ্রাম হলে শুধু child-এর ফোল্ডার বদলাত। নিয়মটি আরও সাধারণ: যে কাজ shell process-এর নিজের অবস্থা বদলায়, অথবা যে তথ্য শুধু shell-এর মেমরিতে আছে, সেটি builtin হতেই হবে। কারণ fork-এর পর child যা-ই বদলাক, তা child-এর কপিতে; parent কখনো দেখে না।

শেষ সারির builtin exec মজার: exec ls লিখলে shell fork করে না, সরাসরি নিজের ভেতরে ls বসায়। ls শেষ হলে আর shell নেই — terminal জানালা বন্ধ হয়ে যায়। অর্থাৎ shell-এর লুপের ধাপ ৪ বাদ দিলে ঠিক এটাই ঘটে।

২ · ৩৫ লাইনে নিজের shell — C-তে mysh

তত্ত্ব যথেষ্ট; এবার লুপটি নিজে লিখে চালাই। নিচের প্রোগ্রামটি একটি সত্যিকারের, কাজের shell — pipe, redirection বা উদ্ধৃতিচিহ্ন বোঝে না, কিন্তু যেকোনো বাইরের কমান্ড চালাতে পারে, আর cd ও exit নিজে সামলায়। ব্লকটির stdin-এ আগে থেকে সাতটি লাইন দেওয়া আছে, যেন কেউ টাইপ করছেন: echo hello from mysh, uname -s, cd /tmp, pwd, false, nosuchcmd -x, exit — আর exit-এর পরে একটি অতিরিক্ত লাইন।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>
int main(void) {
    char line[256], *argv[16];
    for (;;) {
        printf("mysh> ");
        fflush(stdout);                                 /* flush BEFORE fork */
        if (!fgets(line, sizeof line, stdin)) break;    /* 1. read; EOF = Ctrl+D */
        if (!isatty(STDIN_FILENO)) { fputs(line, stdout); fflush(stdout); }
        int argc = 0;                                   /* 2. parse into words */
        for (char *t = strtok(line, " \t\n"); t && argc < 15; t = strtok(NULL, " \t\n"))
            argv[argc++] = t;
        argv[argc] = NULL;
        if (argc == 0) continue;
        if (strcmp(argv[0], "exit") == 0) break;        /* builtins run HERE */
        if (strcmp(argv[0], "cd") == 0) {
            if (chdir(argc > 1 ? argv[1] : "/") != 0) printf("cd: failed\n");
            continue;
        }
        pid_t pid = fork();                             /* 3. fork */
        if (pid == 0) {                                 /* child */
            execvp(argv[0], argv);                      /* 4. exec */
            printf("mysh: %s: command not found\n", argv[0]);
            fflush(stdout);
            _exit(127);
        }
        int status;
        waitpid(pid, &status, 0);                       /* 5. parent waits */
        if (WIFEXITED(status) && WEXITSTATUS(status) != 0)
            printf("[exit %d]\n", WEXITSTATUS(status));
    }
    return 0;
}

এই ছোট shell-এ কী নেই, তার তালিকাই আসলে এই পর্বের বাকি অংশের সূচি: & দিয়ে background (অংশ ৩), Ctrl+C চাপলে shell নিজে না মরে শুধু কমান্ডটি থামানো (অংশ ৪), job table আর fg/bg (অংশ ৪–৫)। Pipe আর redirection যোগ করার কৌশল পর্ব ০৩-এর ডায়াগ্রামে দেখেছেন — pipe(), dup2(), তারপর exec; পর্ব ৫৯-এর ক্যাপস্টোনে সবগুলো জুড়ে পূর্ণ shell লিখবেন।

৩ · Foreground আর background — &, jobs, wait আর $!

সাধারণভাবে কমান্ড চালালে shell অপেক্ষা করে — কমান্ডটি foreground-এ চলে, আর আপনার কিবোর্ড তার দখলে। লাইনের শেষে & দিলে shell fork আর exec করে, কিন্তু wait করে না; সাথে সাথে prompt ফিরিয়ে দেয়। কমান্ডটি তখন background-এ চলে। Shell প্রতিটি এমন কমান্ড (বা পুরো pipeline)-কে একটি job হিসেবে মনে রাখে — job নম্বর %1, %2… আর এই তালিকাই job control-এর ভিত্তি।

• jobs — shell-এর job table: নম্বর, অবস্থা (Running, Stopped, Done), কমান্ড। + চিহ্ন “বর্তমান” job, - তার আগেরটি; jobs -l PID-ও দেখায়।
• $! — সবচেয়ে শেষে background-এ পাঠানো process-এর PID. Script-এ পরে kill বা wait করতে কাজে লাগে।
• wait — সব background child শেষ হওয়া পর্যন্ত অপেক্ষা; wait $pid বা wait %1 নির্দিষ্ট একটির জন্য, আর তার exit status ফেরত দেয়।

নিচের ডায়াগ্রামে একই কমান্ড দুইভাবে চালানো হয়েছে — sleep 5 আর sleep 5 &. প্রতিটি ধাপে shell আর child কী করছে, আর terminal কার হাতে, পাশাপাশি তুলনা করুন। (PID-গুলো উদাহরণ)

এবার আসল Linux-এ দেখা যাক। নিচের ব্লকটি background job চালায়, job table আর process-এর group দেখায়, job control চালু-বন্ধ করে, একটি job-কে ভদ্রভাবে থামায়, আর একটির priority কমায়:

echo "this shell: PID $$"
sleep 1 &                        # & : start it, do not wait
echo "started a job, \$! = $!"
sleep 1 &
jobs -l                          # the shell's job table
ps -o pid,ppid,pgid,ni,stat,comm # job control is OFF in a script
set -m                           # turn job control ON
sleep 1 &
ps -o pid,pgid,stat,comm
wait                             # wait for ALL background children
echo "wait returned $?, jobs left: $(jobs | wc -l)"
set +m
sleep 30 &
kill $!                          # polite: SIGTERM (15)
wait $!
echo "killed sleep: status $? = 128 + $(kill -l TERM)"
nice -n 5 sleep 0.2 &
ps -o pid,ni,stat,comm -p $!
wait

৪ · Ctrl+C, Ctrl+Z, fg আর bg — কে কাকে থামায়

একটি প্রচলিত ভুল ধারণা: Ctrl+C চাপলে shell প্রোগ্রামটিকে মেরে ফেলে। আসলে shell তখন waitpid-এ ঘুমিয়ে আছে, সে কিছুই দেখে না। কাজটি করে kernel-এর terminal driver (tty-এর line discipline). আপনার চাপা অক্ষরগুলো প্রোগ্রামে পাঠানোর আগে driver দেখে নেয় কোনো বিশেষ অক্ষর এসেছে কি না; এলে সে terminal-এর foreground process group-এর প্রতিটি process-কে একটি signal পাঠায় — kernel-এর একটি ছোট সংকেত, যা process-কে জানায় “কিছু একটা ঘটেছে”। Signal ধরা, উপেক্ষা করা আর নিজের handler লেখা পর্ব ১৩-এর বিষয়; এখানে শুধু কে, কখন, কাকে পাঠায়।

কেন “পুরো group”? কারণ sort big.txt | uniq -c | head তিনটি আলাদা process, অথচ আপনার কাছে এটি একটি কাজ। Shell তিনটিকে একটি process group-এ রাখে, তাই একবার Ctrl+C-তে তিনটিই থামে। আর shell নিজে অন্য group-এ থাকে বলে সে বেঁচে যায় — এটিই আপনার mysh-এর সাথে bash-এর বড় পার্থক্য (mysh-এ সবাই এক group-এ, তাই Ctrl+C-তে mysh-ও মরে)।

থামানো, পেছনে পাঠানো, সামনে আনা

• Ctrl+Z — চলমান foreground job থামানো (Stopped). Process মেমরিতে আছে, শুধু CPU পাচ্ছে না।
• bg বা bg %1 — থেমে থাকা job-কে SIGCONT পাঠিয়ে background-এ চালু করা।
• fg বা fg %1 — job-কে foreground-এ আনা: terminal তার group-কে দেওয়া, দরকার হলে SIGCONT, তারপর অপেক্ষা।
• kill %1 — job নম্বর দিয়ে signal পাঠানো (shell %1-কে PGID-তে বদলে নেয়)।

ধরুন আপনি একটি লম্বা কাজ (sleep 100) foreground-এ শুরু করে ফেলেছেন, এখন অন্য কাজ করতে চান। নিচের ধারায় job table, process-এর STAT আর terminal-এর মালিক কীভাবে বদলায় দেখুন। (bash-এর PID/PGID 4000, sleep-এর 5001 — উদাহরণ)

/* child, fork()-এর ঠিক পরে */
setpgid(0, 0);                       /* নিজের নতুন process group */
if (foreground) tcsetpgrp(tty_fd, getpid());
execvp(argv[0], argv);

/* parent shell */
setpgid(pid, pid);                   /* একই কাজ — race এড়াতে দুদিকেই */
if (foreground) {
    tcsetpgrp(tty_fd, pid);          /* terminal দিলাম job-কে */
    waitpid(-pid, &status, WUNTRACED);  /* শেষ হলো, না থামল? */
    tcsetpgrp(tty_fd, getpgrp());    /* terminal ফেরত নিলাম */
    if (WIFSTOPPED(status)) mark_job_stopped(pid);
}
/* bg: kill(-pgid, SIGCONT);   fg: tcsetpgrp(...) + kill(-pgid, SIGCONT) + waitpid */

kill(-pgid, …) আর waitpid(-pgid, …)-এর ঋণাত্মক সংখ্যাটি লক্ষ করুন — POSIX-এ এর মানে “এই group-এর সবাই”। পুরো job control এই কয়েকটি system call দিয়েই তৈরি; বাকিটা shell-এর হিসাবরক্ষণ।

৫ · Process group, session আর controlling terminal — SSH কাটলে job কেন মরে

এ পর্যন্ত তিনটি স্তর দেখা হলো। এবার নামগুলো ঠিক করে নিই:

• Process — একটি চলমান প্রোগ্রাম, PID দিয়ে চেনা; তার parent-এর PID হলো PPID.
• Process group — একসাথে signal পাওয়া process-দের দল, সাধারণত একটি job বা pipeline; PGID = দলনেতার PID.
• Session — একটি login-এর অধীনের সব process group; SID = session leader-এর PID, সাধারণত login shell. Session leader setsid() দিয়ে নতুন session খোলে।
• Controlling terminal — একটি session-এর সাথে যুক্ত একটিমাত্র terminal (যেমন /dev/pts/0). এর একটি foreground group থাকে; বাকি group background.

Session 4000  ──  controlling terminal: /dev/pts/0  (SSH-এর pseudo-terminal)
│
├── group 4000   bash                      session leader, prompt-এ অপেক্ষা
├── group 5001   sleep 100 &               background job [1]
└── group 5100   sort big.txt | uniq -c | head     ← foreground job: terminal এদের হাতে
                 ├── 5100 sort
                 ├── 5101 uniq
                 └── 5102 head

SIGHUP — “লাইন কেটে গেছে”

SIGHUP নামটি এসেছে টেলিফোনের “hang up” থেকে। ১৯৭০-এর দশকে terminal দূরের কম্পিউটারে modem দিয়ে যুক্ত হতো; লাইন কেটে গেলে kernel সেই terminal-এর process-দের জানিয়ে দিত, যাতে কেউ অনন্তকাল এমন কিবোর্ডের অপেক্ষায় না থাকে যা আর নেই। আজকের SSH সংযোগও একটি pseudo-terminal-এর মাধ্যমে চলে, তাই নিয়ম একই। নিচের ডায়াগ্রামে Wi-Fi কেটে যাওয়ার পর সার্ভারে কী ঘটে দেখুন — তিনটি background কাজ তিনভাবে চালানো ছিল:

বাঁচানোর চারটি উপায়

দুটি সূক্ষ্মতা: (১) exit লিখে স্বাভাবিকভাবে বের হলে bash ডিফল্টভাবে চলমান job-দের SIGHUP পাঠায় না (shopt huponexit বন্ধ থাকে); থেমে থাকা job থাকলে শুধু সতর্ক করে There are stopped jobs. তবুও সেই job terminal-এ লিখতে গেলে ব্যর্থ হবে। (২) কিছু Linux distro-তে systemd-logind-এর KillUserProcesses সেটিং চালু থাকলে logout-এ পুরো session-এর সব process মারা যায় — nohup দিয়েও বাঁচে না। আপনার সার্ভারে কী সেটিং আছে, /etc/systemd/logind.conf-এ দেখে নিন।

Daemon — terminal ছাড়া জন্ম থেকে

যে process কোনো terminal ছাড়া পেছনে স্থায়ীভাবে চলে, তাকে বলে daemon — sshd, cron, nginx; নামের শেষে প্রায়ই d. পুরোনো Unix-এ daemon নিজেকে নিজে “আলাদা” করত: fork করে parent বেরিয়ে যেত (যাতে shell ভাবে কাজ শেষ), child setsid() করে নতুন session খুলত (কোনো controlling terminal নেই, SIGHUP-এর ভয় নেই), আবার fork করত যাতে ভুলেও কোনো terminal তার controlling terminal না হয়, তারপর chdir("/"), stdin/stdout/stderr-কে /dev/null-এ পাঠানো। আধুনিক Linux-এ systemd এই কাজ নিজেই করে: সার্ভিসটি সাধারণ প্রোগ্রামের মতো foreground-এ চলে, stdout-এ log লেখে, আর systemd তাকে আলাদা রাখে, নজর রাখে, পড়ে গেলে আবার চালায়। ps-এ daemon-এর TTY কলামে দেখবেন ? — কোনো controlling terminal নেই।

৬ · ps আর pstree — process-এর তালিকা পড়া

ps (process status) একটি মুহূর্তের ছবি তোলে: সেই মুহূর্তে কোন process আছে, কে চালিয়েছে, কী অবস্থায়। ইতিহাসের কারণে এর option-এর দুটি ঘরানা আছে, আর Linux-এর ps (procps প্যাকেজ) দুটিই বোঝে:

সাবধান: ps aux আর ps -aux এক নয় — dash দিলে -u মানে “এই user-এর process”, আর x নামে user খোঁজা হতে পারে। BSD রূপ সবসময় dash ছাড়া লিখুন। আরেকটি পার্থক্য: ps-এর %CPU process-এর পুরো জীবনের গড়, আর top-এরটি শেষ কয়েক সেকেন্ডের — তাই একই process-এর দুটি সংখ্যা মেলে না। একটি সাধারণ ল্যাপটপে ps aux-এর কয়েকটি লাইন দেখতে এমন (উদাহরণ, ছাঁটা):

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.1 167712 12840 ?        Ss   09:02   0:03 /sbin/init splash
root         812  0.0  0.0  15428  8960 ?        Ss   09:02   0:00 sshd: /usr/sbin/sshd -D
rahim       4000  0.0  0.0  11284  5320 pts/0    Ss   10:11   0:00 -bash
rahim       5001  0.0  0.0   8392  1020 pts/0    T    10:20   0:00 sleep 100
rahim       5100 98.7  1.2 210440 99812 pts/0    R+   10:21   1:12 sort big.txt
rahim       4321 12.4  5.1 3914560 412300 ?      Sl   09:15  12:03 /usr/lib/firefox/firefox
rahim       6060  0.0  0.0      0     0 ?        Z    10:25   0:00 [python3] <defunct>

VSZ (virtual size) হলো process-এর পুরো ঠিকানা-জায়গার আকার KiB-তে — যা সে “দাবি” করেছে, ব্যবহার না করলেও। RSS (resident set size) হলো এই মুহূর্তে আসল RAM-এ থাকা অংশ। Firefox-এর VSZ প্রায় ৩.৭ GiB, অথচ RSS মাত্র ৪০০ MiB-এর মতো — কেন এত পার্থক্য, পর্ব ৩৫ আর ৩৮-এ virtual memory দেখার পর পরিষ্কার হবে। -bash-এর আগের dash মানে এটি login shell. আর শেষ লাইনের <defunct> একটি zombie — শেষ হয়ে গেছে, কিন্তু parent এখনো wait করেনি।

STAT কলাম — এক-দুই অক্ষরে পুরো গল্প

এখন উপরের তালিকা পড়ে ফেলতে পারেন: init আর sshd Ss — ঘুমিয়ে আছে, নিজের session-এর leader; sleep 100 T — কেউ Ctrl+Z চেপেছে; sort R+ — CPU-তে চলছে, foreground-এ; firefox Sl — ঘুমন্ত, অনেক thread. এগুলোই পর্ব ০৮-এর process state diagram-এর বাস্তব রূপ।

pstree -p একই তথ্য গাছ আকারে দেখায় — কে কার parent, এক নজরে (উদাহরণ, ছাঁটা):

systemd(1)─┬─sshd(812)───sshd(3990)───sshd(3998)───bash(4000)─┬─sleep(5001)
           │                                                  └─sort(5100)
           ├─cron(640)
           └─tmux: server(7100)───bash(7101)───train.sh(7150)

লক্ষ করুন, tmux-এর ভেতরের কাজটি sshd-এর শাখায় নয়, systemd-এর সরাসরি নিচে — ঠিক এজন্যই SSH কাটলেও সে বাঁচে। নাম দিয়ে PID খুঁজতে pgrep -a nginx (-a পুরো কমান্ড লাইনসহ দেখায়) — ps aux | grep nginx-এর চেয়ে নির্ভরযোগ্য, কারণ grep নিজেকেও তালিকায় ধরে ফেলে।

৭ · top আর htop — চলমান ছবি, আর load average-এর আসল মানে

ps যদি ছবি হয়, top ভিডিও — প্রতি কয়েক সেকেন্ডে পর্দা হালনাগাদ করে, ডিফল্টভাবে সবচেয়ে বেশি CPU খরচ করা process ওপরে রেখে। কয়েকটি কাজের কি: P CPU অনুযায়ী, M মেমরি অনুযায়ী সাজানো, 1 প্রতিটি CPU আলাদা, k signal পাঠানো, r renice, q বেরোনো। Script-এ বা log-এর জন্য top -b -n 1 (batch mode, একবার)। htop একই তথ্য রঙিন বার, গাছ-দৃশ্য (F5) আর মাউস দিয়ে দেখায়; অনেক distro-তে আলাদা ইনস্টল করতে হয়।

Load average — সবচেয়ে বেশি ভুল বোঝা সংখ্যা

top-এর প্রথম লাইনে, uptime-এ আর /proc/loadavg-এ তিনটি সংখ্যা থাকে, যেমন 2.15, 1.40, 0.90 — গত ১, ৫ আর ১৫ মিনিটের load average. এটি শতাংশ নয়। এটি “গড়ে কতগুলো task কাজ চাইছিল” তার একটি মাপ:

• Linux-এ যা গোনা হয়: যে task-গুলো R অবস্থায় (CPU-তে চলছে বা CPU-র অপেক্ষায় run queue-তে) এবং যেগুলো D অবস্থায় (uninterruptible sleep, সাধারণত I/O). প্রতিটি thread আলাদা task হিসেবে গোনা হয়।
• গড় কীভাবে: সাধারণ গড় নয় — kernel প্রায় প্রতি ৫ সেকেন্ডে একবার সংখ্যাটি নমুনা নেয় আর একটি exponentially-damped moving average হালনাগাদ করে: load = load × e−5/(60m) + n × (1 − e−5/(60m)), যেখানে m = ১, ৫ বা ১৫ মিনিট আর n = এই মুহূর্তের R + D task-এর সংখ্যা। ফলে পুরোনো নমুনার প্রভাব ধীরে ধীরে মিলিয়ে যায়।
• কীসের সাথে তুলনা: CPU-র সংখ্যার সাথে। ৪টি CPU-তে load ৪.০ মানে গড়ে সব CPU ব্যস্ত, কেউ অপেক্ষায় নেই; ৮.০ মানে প্রায় সমান সংখ্যক task লাইনে দাঁড়িয়ে (অথবা I/O-তে আটকে)। ১টি CPU-র যন্ত্রে ৪.০ একই সংখ্যা হলেও অবস্থা অনেক খারাপ।
• প্রবণতা: ১ মিনিটেরটি ১৫ মিনিটেরটির চেয়ে বড় হলে চাপ সম্প্রতি বাড়ছে; ছোট হলে কমছে।

এবার একটি পূর্ণ top পর্দা লাইন ধরে ধরে পড়ি। যন্ত্রটি একটি ৪-CPU ল্যাপটপ, ৮ GB RAM (উদাহরণ):

1top - 10:15:02 up 3 days,  2:41,  1 user,  load average: 2.15, 1.40, 0.902Tasks: 231 total,   2 running, 228 sleeping,   0 stopped,   1 zombie3%Cpu(s): 23.5 us,  4.1 sy,  0.0 ni, 70.2 id,  1.9 wa,  0.0 hi,  0.3 si,  0.0 st4MiB Mem :   7837.4 total,    512.3 free,   4210.8 used,   3114.3 buff/cache5MiB Swap:   2048.0 total,   1900.0 free,    148.0 used.   3205.6 avail Mem6 7    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND8   4321 rahim     20   0 3914560 412300  98200 S  87.5   5.1  12:03.44 firefox9   1187 rahim     20   0  812344  95120  60480 R  12.0   1.2   0:48.10 code10    498 root      20   0       0      0      0 D   0.3   0.0   0:05.12 jbd2/sda2-811   5570 rahim     39  19   20480   4096   3500 S   2.0   0.1   0:01.02 backup.sh

৮ · /proc — kernel-এর দিকে খোলা জানালা

ps আর top কোনো জাদু জানে না। তারা kernel-এর বানানো একটি বিশেষ ফোল্ডার /proc পড়ে। এটি procfs — একটি virtual file system: ডিস্কে এর কোনো ফাইল নেই; আপনি কোনো “ফাইল” পড়লে kernel সেই মুহূর্তে নিজের ভেতরের তথ্য থেকে লেখাটি বানিয়ে দেয়। প্রতিটি process-এর জন্য একটি ফোল্ডার /proc/<pid>/, আর /proc/self সবসময় যে process পড়ছে তার নিজের ফোল্ডার।

এবার এই ব্লকটি যে bash চালাচ্ছে, তাকেই ভেতর থেকে দেখি:

echo "shell PID $$, parent PID $PPID"
tr '\0' ' ' < /proc/$$/cmdline; echo        # NUL-separated argv
grep -E '^(Name|State|PPid|Threads|VmRSS)' /proc/$$/status
ls -l /proc/$$/fd | awk 'NR>1 {print $9, $10, $11}'
read one five fifteen procs last < /proc/loadavg
echo "load average: $one $five $fifteen (running/total: $procs)"
echo "CPUs seen: $(nproc)"
echo "PID 1 is: $(cat /proc/1/comm)"
top -b -n 1 | head -12

lsof — কে কোন ফাইল ধরে রেখেছে

lsof (list open files) সব process-এর /proc/<pid>/fd ঘুরে একটি তালিকা বানায়। Linux-এ “সবকিছুই ফাইল” — তাই সাধারণ ফাইল, ফোল্ডার, pipe, network socket সবই এখানে আসে। এই সাইটের সার্ভারে এটি ইনস্টল নেই, তাই উদাহরণ:

$ lsof -i :8080                 # কে 8080 পোর্টে শুনছে?
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    9120 rahim   21u  IPv4  73412      0t0  TCP *:8080 (LISTEN)
$ lsof +L1                      # মুছে ফেলা কিন্তু এখনো খোলা ফাইল
COMMAND  PID USER FD  TYPE DEVICE   SIZE/OFF NLINK  NODE NAME
java    3301 app   7w  REG  259,2 8589934592     0 13321 /var/log/app.log (deleted)
$ lsof -p 9120 | head -3        # একটি process-এর সব খোলা ফাইল

দ্বিতীয় উদাহরণটি পর্ব ০৩-এর একটি রহস্যের সমাধান: log ফাইল rm করার পরও ডিস্ক ভরা, কারণ java এখনো ৮ GiB-এর ফাইলটি খুলে রেখেছে। প্রোগ্রামটি restart করলে (বা তাকে log ফাইল নতুন করে খুলতে বললে) জায়গা খালি হয়। lsof না থাকলে ls -l /proc/*/fd 2>/dev/null | grep deleted একই কাজ করে, আর পোর্টের জন্য ss -ltnp.

৯ · kill, pkill, nice — আর Windows-এ একই কাজ

নাম যতই ভয়ংকর হোক, kill আসলে শুধু একটি signal পাঠায়। কোনটি পাঠাবেন, সেখানেই ভদ্রতা:

• kill 1234 — ডিফল্ট SIGTERM (১৫): “দয়া করে শেষ করুন”। প্রোগ্রাম চাইলে এটি ধরে গুছিয়ে নিতে পারে — খোলা ফাইল flush, temp ফাইল মোছা, অর্ধেক লেনদেন শেষ করা বা বাতিল।
• kill -9 1234 বা kill -KILL 1234 — SIGKILL (৯): kernel সরাসরি process শেষ করে; ধরা বা উপেক্ষা করা যায় না, তাই গোছানোর সুযোগও নেই। এটি শেষ উপায় — আগে SIGTERM দিয়ে কয়েক সেকেন্ড অপেক্ষা।
• kill -0 1234 — কিছুই পাঠায় না, শুধু যাচাই করে process আছে কি না আর signal পাঠানোর অনুমতি আছে কি না।
• kill -l — সব signal-এর নাম আর নম্বর। পূর্ণ তালিকা আর আচরণ পর্ব ১৩-এ।
• pkill nginx — নামের সাথে মেলে এমন সব process-কে signal; pkill -f পুরো কমান্ড লাইনে খোঁজে। আগে সবসময় pgrep -a দিয়ে দেখে নিন কারা মিলছে।
• killall nginx — Linux-এ (psmisc প্যাকেজ) ঠিক এই নামের সব process. সতর্কতা: Solaris-এর মতো কিছু পুরোনো Unix-এ killall মানে “সব process মেরে ফেলা” — shutdown-এর জন্য তৈরি। অন্য OS-এ অভ্যাসবশত লিখবেন না।

সাধারণ user শুধু নিজের process-এ signal পাঠাতে পারেন; অন্যের process-এ পাঠাতে root লাগে (পর্ব ৪৭)। অন্যের process মারতে sudo kill -9 লেখার আগে ভাবুন — সেটি হয়তো কোনো ডেটাবেস, যার অর্ধেক লেখা ডেটা নষ্ট হবে।

nice আর renice — ভদ্র process

প্রতিটি process-এর একটি nice মান থাকে, −২০ থেকে ১৯; ডিফল্ট ০. মান যত বেশি, process তত “ভদ্র” — CPU নিয়ে কাড়াকাড়ির সময় অন্যদের বেশি সুযোগ দেয়। nice -n 10 ./backup.sh কম priority-তে চালায়; renice -n 15 -p 5570 চলমান process-এর মান বদলায়। সাধারণ user শুধু মান বাড়াতে (ভদ্রতর করতে) পারেন; কমাতে, মানে নিজের priority বাড়াতে, সাধারণত root লাগে। উপরের runnable ব্লকেই দেখেছেন, NI 10 থেকে nice -n 5-এ 15. মনে রাখুন, nice শুধু CPU-র ভাগ বদলায়; ডিস্কের জন্য আলাদা টুল ionice. Linux scheduler nice মানকে কীভাবে CPU-র ভাগে বদলায়, পর্ব ২১-এ দেখবেন।

Windows-এ একই কাজ

Windows-এ fork নেই (process তৈরি হয় CreateProcess দিয়ে), SIGHUP বা SIGTSTP-ও নেই, তাই Unix-এর job control-এর হুবহু রূপ নেই। কিন্তু process দেখা আর থামানোর টুল আছে:

Get-Process -Name notepad | Select-Object Id, CPU, WorkingSet64, StartTime
Stop-Process -Name notepad            # -Force ছাড়া আগে চেষ্টা করুন
# উদাহরণ: WorkingSet64 মোটামুটি Linux-এর RSS-এর মতো — RAM-এ থাকা অংশ (byte-এ)

macOS-এ ps, top, kill, job control সবই আছে (BSD ঘরানার, তাই top-এর option ভিন্ন, যেমন top -o cpu), কিন্তু /proc নেই — তথ্য আসে sysctl আর বিশেষ system call থেকে; গ্রাফিক্যাল দৃশ্য Activity Monitor.

১০ · AI-এর যুগে process সামলানো — কমান্ড আর কোড যাচাই

“সার্ভার ধীর, কী করব?” — AI সাথে সাথে পাঁচটি কমান্ড দেবে। কিন্তু AI আপনার সার্ভার দেখে না: কোন distro, কোন container, কতগুলো CPU, কোন process আসলে জরুরি — কিছুই জানে না। এই বিষয়ে AI-এর ভুলগুলো বেশ নির্দিষ্ট ধাঁচের:

AI-এর দেওয়া process কমান্ড বা shell কোড ব্যবহারের আগে — চেকলিস্ট

• কমান্ডটি আমার OS-এর (Linux/macOS/Windows) আর আমার পরিবেশের (VM, container, WSL) জন্য, man দেখে option মিলিয়েছি
• kill/pkill চালানোর আগে pgrep -a বা ps -o pid,ppid,stat,cmd -p … দিয়ে ঠিক কোন process, দেখে নিয়েছি
• প্রথমে SIGTERM দিয়েছি; -9 শুধু সাড়া না পেলে, আর জেনে যে গোছানোর সুযোগ থাকবে না
• load average-কে CPU-র সংখ্যা, wa আর D-অবস্থার task-এর সাথে মিলিয়ে বিচার করেছি; numerical দাবি নিজে হিসাব করে দেখেছি
• লম্বা কাজের জন্য nohup/tmux/systemd — কোনটি দরকার বুঝে বেছেছি, আর logout-এর পর সত্যিই বাঁচে কি না পরীক্ষা করেছি
• C-তে লেখা shell বা process কোডে fork-এর আগে fflush, exec-এর পর _exit, প্রতিটি child-এর waitpid আছে — ভুল কমান্ড আর pipe-এ আউটপুট দিয়ে চালিয়ে দেখেছি