Service চালানো — process, systemd, journalctl আর resource

১ · Server-এ process-এর জীবন — PID 1, signal আর ভদ্রভাবে থামা

আগের পর্বগুলোতে আপনি Linux-এ ঘোরাফেরা, shell আর script শিখেছেন। এবার আসল কাজ: একটি কাল্পনিক অনলাইন বাজার অ্যাপের API, bazar-api, একটি server-এ দিনরাত চালানো। এর আগে এক লাইনে মনে করিয়ে দিই। Process হলো চলমান প্রোগ্রাম; ভেতরের তত্ত্ব আছে Operating Systems কোর্সের প্রসেস, fork, exec আর wait আর Signal পর্বে। এখানে শুধু operations-এর দিকটি দেখব।

Linux boot-এর শেষে kernel একটিমাত্র user-space process চালায়। তার নম্বর, মানে PID, হয় 1. আধুনিক বেশিরভাগ distribution-এ PID 1 হলো systemd. বাকি সব process এরই বংশধর। কোনো process-এর বাবা আগে মরে গেলে অনাথ সন্তানকেও PID 1 দত্তক নেয়, আর শেষে তার exit status তুলে নেয়। পুরো boot-এর গল্প আছে বুট প্রক্রিয়া পর্বে।

একটি service-এর জীবনে তিনটি মুহূর্ত গুরুত্বপূর্ণ: কে তাকে চালাল, কীভাবে সে মারা গেল, আর তারপর কী হলো। মৃত্যুর পথ দুটি: নিজে শেষ হওয়া (exit), অথবা signal পাওয়া। Server-এ দুটি signal প্রতিদিনের সঙ্গী।

Graceful shutdown মানে SIGTERM পাওয়ার পর একটি নির্দিষ্ট ক্রম: নতুন কাজ নেওয়া বন্ধ, হাতের কাজ শেষ, buffer-এর data লেখা, database connection বন্ধ, তারপর exit 0. আর systemd বা অন্য manager অনন্তকাল অপেক্ষা করে না: সময়সীমা পেরোলে SIGKILL পাঠায়। systemd-তে এই সীমা TimeoutStopSec, ডিফল্ট সাধারণত ৯০ সেকেন্ড।

নিচের Bash block সেই আচরণটি ছোট আকারে দেখায়। পেছনে চলা worker-এর সারিতে পাঁচটি কাজ আছে। stop_unit ফাংশন systemd-র ভূমিকায়: আগে SIGTERM, সময় পেরোলে SIGKILL. কাজ ১০৩ চলার সময় signal আসে। দ্বিতীয় ঘটনায় একটি জেদি process SIGTERM উপেক্ষা করে।

tmp=$(mktemp -d)
worker() {                        # a fake service with 5 queued jobs
  local stop=0
  trap 'stop=1; echo "  worker: SIGTERM, no new job after this one"' TERM
  for job in 101 102 103 104 105; do
    [ "$stop" = 1 ] && break
    echo "  worker: start job $job"
    if [ "$job" = 103 ]; then     # the signal arrives during job 103
      touch "$tmp/busy"
      until [ -e "$tmp/sent" ]; do sleep 0.01; done
    fi
    echo "  worker: done  job $job"
  done
  echo "  worker: state saved, exit 0"; exit 0
}
stubborn() { trap '' TERM; touch "$tmp/busy"; while :; do sleep 0.01; done; }

stop_unit() {                     # $1 = job pid, $2 = grace in 0.01 s ticks
  until [ -e "$tmp/busy" ]; do sleep 0.01; done
  echo "manager: send SIGTERM"
  kill -TERM "$1"; touch "$tmp/sent"
  for ((i = 0; i < $2; i++)); do
    kill -0 "$1" 2>/dev/null || break
    sleep 0.01
  done
  if kill -0 "$1" 2>/dev/null; then
    echo "manager: grace over, send SIGKILL"; kill -KILL "$1"
  fi
  wait "$1" 2>/dev/null; echo "manager: exit status $?"
  rm -f "$tmp/busy" "$tmp/sent"
}
echo "== case 1: handles SIGTERM =="; worker &   stop_unit $! 500
echo "== case 2: ignores SIGTERM =="; stubborn & stop_unit $! 30
rm -rf "$tmp"

== case 1: handles SIGTERM ==
  worker: start job 101
  worker: done  job 101
  worker: start job 102
  worker: done  job 102
  worker: start job 103
manager: send SIGTERM
  worker: SIGTERM, no new job after this one
  worker: done  job 103
  worker: state saved, exit 0
manager: exit status 0
== case 2: ignores SIGTERM ==
manager: send SIGTERM
manager: grace over, send SIGKILL
manager: exit status 137

২ · nohup বনাম service — কেন একজন ম্যানেজার দরকার

নতুন অনেকে SSH করে server-এ ঢুকে এভাবে অ্যাপ চালান। শব্দটি মনে রাখুন: nohup মানে “no hangup”. Terminal বন্ধ হলে process-কে SIGHUP পাঠানো হয়; nohup সেটি উপেক্ষা করতে বলে আর আউটপুট nohup.out-এ পাঠায়।

# works today, breaks on the first crash or reboot
nohup node server.js &

এটি চলে। রাত তিনটায় একটি unhandled exception হলো, process শেষ। কেউ জানে না। সকালে ক্রেতারা অভিযোগ করবেন। Cloud provider server restart করলেও একই দশা। এই ভঙ্গুরতাই service-এর সংজ্ঞা তৈরি করে: terminal ছাড়া পেছনে দীর্ঘ সময় চলা process-কে বলে daemon, আর তাকে একজন manager-এর হাতে তুলে দেওয়া হলো service হিসেবে চালানো।

systemd যা সামলায় তার প্রতিটিকে বলে unit. Unit-এর ধরন ফাইলের শেষাংশে লেখা থাকে: .service (process), .timer (সময়সূচি, পর্ব ১০-এ দেখেছেন), .socket, .mount, আর .target. Target হলো কয়েকটি unit-এর দল; multi-user.target মোটামুটি বলে “server সাধারণ কাজের জন্য তৈরি”।

একটি unit যেকোনো সময় কোনো একটি অবস্থায় থাকে। নিচের ছবিটি মাথায় গেঁথে নিন, কারণ systemctl status-এর Active: লাইনে ঠিক এই শব্দগুলোই আসে।

৩ · Unit file লেখা — service-এর চুক্তিপত্র

Unit file একটি ছোট লেখা ফাইল, রান্নাঘরের রেসিপি খাতার পাতার মতো: কী লাগবে, কোন ক্রমে, ব্যর্থ হলে কী। নিজের লেখা unit রাখা হয় /etc/systemd/system/-এ; package-এর দেওয়া unit থাকে সাধারণত /usr/lib/systemd/system/-এ, আর একই নাম হলে /etc-এরটি জেতে। নিচের নমুনাটি runner-এ চলবে না, কারণ runner-এ systemd নেই; এটি পড়ার জন্য।

# /etc/systemd/system/bazar-api.service
[Unit]
Description=Bazar API (fictional shop app)
Wants=network-online.target
After=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=bazar
Group=bazar
WorkingDirectory=/opt/bazar-api
Environment=PORT=8080 NODE_ENV=production
EnvironmentFile=/etc/bazar-api/env
ExecStart=/usr/bin/node /opt/bazar-api/server.js
Restart=on-failure
RestartSec=5
TimeoutStopSec=30

[Install]
WantedBy=multi-user.target

এবার দেখা যাক systemctl start দিলে ফাইল থেকে চলন্ত process পর্যন্ত আসলে কী কী ঘটে। “পরে” চাপুন।

$ sudo systemctl start bazar-api
# systemctl নিজে অ্যাপ চালায় না; সে PID 1-কে বলে

unit      : bazar-api.service  (already loaded)
limit     : 0 of 5 starts in window, allowed
Wants     : network-online.target
After     : wait until that target is done
job       : start, queued

/sys/fs/cgroup/system.slice/bazar-api.service/
# সীমা লেখা থাকলে এখানে বসে (অংশ ৬ দেখুন)
memory.max   536870912
cpu.max      150000 100000

fork()                # systemd-র একটি কপি
set cgroup, sandbox, env, cwd
setuid(bazar)         # root থেকে নেমে আসা
exec /usr/bin/node /opt/bazar-api/server.js

simple : process শুরু হলেই      # port খোলার আগেই!
exec   : exec সফল হলে
notify : অ্যাপ READY=1 পাঠালে   # সবচেয়ে সৎ

$ systemctl status bazar-api
Active: active (running) since Fri 2026-10-30 14:02:11 +06
   Main PID: 2417 (node)
     CGroup: /system.slice/bazar-api.service
             └─2417 /usr/bin/node /opt/bazar-api/server.js

৪ · systemctl আর journalctl — চালানো আর খোঁজা

systemd-কে কমান্ড দেওয়ার টুল হলো systemctl. প্রতিদিনের কমান্ড অল্প কয়েকটি। সবচেয়ে বেশি গুলিয়ে যায় তিনটি জোড়া: start বনাম enable, restart বনাম reload, আর reload বনাম daemon-reload.

তাই unit file বদলানোর পর ক্রমটি হলো: ফাইল সম্পাদনা, daemon-reload, restart, যাচাই। অন্যের unit বদলাতে মূল ফাইলে হাত না দিয়ে systemctl edit ব্যবহার করুন; এটি একটি drop-in override বানায়, যা package আপডেটে হারায় না।

sudo systemctl daemon-reload              # read the new file
sudo systemctl enable --now bazar-api     # boot + right now
systemctl status bazar-api                # read Loaded and Active
systemctl is-active bazar-api             # prints: active
systemctl is-enabled bazar-api            # prints: enabled
systemctl cat bazar-api                   # file plus drop-ins, as loaded

status-এর এই দুটি লাইন আগে পড়ুন। Loaded বলে boot-এর সিদ্ধান্ত (enabled), Active বলে এই মুহূর্তের অবস্থা। নিচেরটি নমুনা আউটপুট, version-ভেদে আলাদা হতে পারে।

● bazar-api.service - Bazar API (fictional shop app)
     Loaded: loaded (/etc/systemd/system/bazar-api.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-10-30 14:02:11 +06; 3h 12min ago
   Main PID: 2417 (node)
      Tasks: 11 (limit: 512)
     Memory: 186.4M (high: 450.0M max: 512.0M available: 263.6M)
        CPU: 2min 41.302s
     CGroup: /system.slice/bazar-api.service
             └─2417 /usr/bin/node /opt/bazar-api/server.js

journal থেকে ঠিক লাইনটি বের করা

Service-এর stdout আর stderr journald-এ জমা হয়। journalctl হলো সেই খাতা পড়ার যন্ত্র। পর্ব ৯-এর grep-এর আগে এর নিজের ছাঁকনি ব্যবহার করুন; উত্তর দ্রুত আসে।

journalctl -u bazar-api -n 50 --no-pager      # last 50 lines of one unit
journalctl -u bazar-api -f                    # follow live
journalctl -u bazar-api --since "2026-10-30 14:00" --until "2026-10-30 14:30"
journalctl -u bazar-api -b                    # this boot only
journalctl -b -1 -p err                       # previous boot, err and worse
journalctl -k -g "out of memory"              # kernel log, search text
journalctl -u bazar-api -o json-pretty -n 1   # every field of one entry
journalctl --disk-usage                       # how much the journal holds

৫ · Restart policy আর crash loop — কখন থামতে হবে

Restart policy বলে process থামলে কী হবে। Restart=-এর প্রধান মান:

এখানে “পরিষ্কার” মানে exit 0, অথবা SIGTERM, SIGHUP, SIGINT, SIGPIPE দিয়ে শেষ হওয়া। কিন্তু কোড যদি প্রতিবার ভেঙে পড়ে? ভুল config, ভাঙা database, ফুরিয়ে যাওয়া secret — এসবে restart কিছুই ঠিক করে না। এই চক্রের নাম crash loop.

নিয়মটি হলো: StartLimitIntervalSec সময়ের মধ্যে StartLimitBurst-এর বেশি start হবে না। ডিফল্ট সাধারণত ১০ সেকেন্ডে ৫ বার। দুটিই [Unit] section-এ বসে, এবং নিয়মটি হাতের systemctl start-কেও গোনে। এবার সবচেয়ে কাজের হিসাবটি। ধরুন process চালু হওয়ার u সেকেন্ড পরে ভেঙে পড়ে, আর r হলো RestartSec. তাহলে এক চক্র u + r. সীমা আটকাতে পারবে কেবল তখনই, যখন:

নিচের simulator চারটি ঘটনা এক ঘণ্টার কাল্পনিক ঘড়িতে চালায়। সব সময় মিলিসেকেন্ডে, কোনো আসল ঘড়ি বা random নেই।

// systemd Restart= with a start limit, on a simulated clock (milliseconds).
// Fixed window, like systemd's rate limiter: the count resets once the
// window has passed. A crash happens "uptimeMs" after every start.
function run(c) {
  let t = 0, begin = -1, num = 0, starts = 0, crashes = 0, last = 0;
  while (t < c.horizonMs) {
    if (begin < 0 || t > begin + c.intervalMs) { begin = t; num = 0; }
    if (num >= c.burst) return [starts, crashes, 'failed (limit hit)', t];
    num++; starts++; last = t;
    if (crashes >= c.crashLimit) return [starts, crashes, 'active (healthy)', t];
    t += c.uptimeMs; crashes++;
    t += c.restartMs;
  }
  return [starts, crashes, 'still looping', last];
}
const hour = 3600000;
const cases = [ // name, restart, window, burst, uptime, crashes until fixed
  ['A default   100ms 10s/5', 100, 10000, 5, 200, 1e9],
  ['B slow      5s    10s/5', 5000, 10000, 5, 1000, 1e9],
  ['C tuned     5s    300s/5', 5000, 300000, 5, 1000, 1e9],
  ['D transient 5s    300s/5', 5000, 300000, 5, 1000, 2],
];
console.log('case                      starts crashes end state          at');
for (const [label, restartMs, intervalMs, burst, uptimeMs, crashLimit] of cases) {
  const [s, cr, end, at] = run({ restartMs, intervalMs, burst, uptimeMs, crashLimit, horizonMs: hour });
  console.log(label.padEnd(25), String(s).padStart(6), String(cr).padStart(7),
    ' ' + end.padEnd(18), (at / 1000).toFixed(1) + 's');
}
// The limit can stop a loop only if burst full cycles fit inside the window.
for (const [label, r, i, b, u] of cases.slice(0, 3)) {
  const need = (b * (r + u)) / 1000;
  console.log(label[0], 'needs', need + 's', need < i / 1000 ? '< window: stops' : '>= window: never stops');
}

case                      starts crashes end state          at
A default   100ms 10s/5        5       5  failed (limit hit) 1.5s
B slow      5s    10s/5      600     600  still looping      3594.0s
C tuned     5s    300s/5       5       5  failed (limit hit) 30.0s
D transient 5s    300s/5       3       2  active (healthy)   12.0s
A needs 1.5s < window: stops
B needs 30s >= window: never stops
C needs 30s < window: stops

এবার ছোট সংখ্যায় একটি crash loop ধাপে ধাপে দেখুন। ধরুন RestartSec=5, StartLimitIntervalSec=60, StartLimitBurst=3, আর ভুল database password-এর কারণে অ্যাপ প্রতিবার ১ সেকেন্ড পরে exit 1 দেয়।

৬ · Resource সীমা আর sandboxing — একজনের ভুলে সবাই যেন না ডোবে

একটি server-এ কয়েকটি service থাকে। একটির memory leak যেন পুরো machine না ডোবায়। মেসের কথা ভাবুন: এক সাব-মিটার ছাড়া একজনের হিটার সবার বিল বাড়ায়। সাব-মিটার বসালে প্রত্যেকের হিসাব ও সীমা আলাদা। সেই সাব-মিটার হলো cgroup. Linux এই সুবিধা দেয়, আর systemd প্রতিটি service-কে নিজের cgroup-এ রাখে; ভেতরের তত্ত্ব আছে Linux-এর scheduler পর্বে। Docker আর Kubernetes-ও একই kernel সুবিধা ব্যবহার করে (পর্ব ৩৯, ৪৮)।

# sudo systemctl edit bazar-api   (saved as a drop-in override)
[Service]
MemoryHigh=450M
MemoryMax=512M
CPUQuota=150%
TasksMax=512

NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/bazar-api

হিসাবের দুটি ফাঁদ। এক, CPUQuota=50% চার core-এর machine-এর অর্ধেক নয়, একটি core-এর অর্ধেক; মানে পুরো machine-এর ১২.৫%. চার core-এর পুরোটা হলো 400%. দুই, systemd-র M হলো 1024 ভিত্তিক: 512M = 512 × 1024 × 1024 = 536,870,912 byte, যা এই পর্বের stepper-এর memory.max-এর সাথে মেলে।

Sandboxing বাগ ঠিক করে না, ক্ষতির blast radius ছোট করে। অ্যাপ দখল হলেও সে সিস্টেম ফাইল বদলাতে পারে না, আর /tmp দিয়ে অন্য service-এর গোপন ফাইল দেখতে পারে না। ভেতরে এগুলো namespace ও অন্যান্য kernel সুবিধা; তত্ত্ব আছে Sandboxing পর্বে। systemd-analyze security bazar-api একটি service-এর উন্মুক্ততার মোটামুটি নম্বর দেয়, যা হিসেবে ভালো তবে নিরাপত্তার প্রমাণ নয়। নতুন setting একটি একটি করে যোগ করুন, কারণ ProtectSystem=strict অ্যাপের লেখার পথ বন্ধ করে ভেঙে দিতে পারে।

৭ · Load average, memory pressure আর OOM killer

এবার পুরো machine-এর স্বাস্থ্য। uptime বা top-এর প্রথম লাইনে তিনটি সংখ্যা থাকে: load average ১, ৫ আর ১৫ মিনিটের। এটি CPU-র শতাংশ নয়। এটি বলে গড়ে কতটি task চলছে বা চলার অপেক্ষায় আছে।

Linux-এ একটি বিশেষ কথা আছে: এই গণনায় CPU-র অপেক্ষায় থাকা task-এর সাথে D state-এর task-ও পড়ে, মানে যারা সাধারণত disk I/O-র জন্য আটকে আছে। তাই load উঁচু আর CPU প্রায় ফাঁকা হলে সমস্যা CPU নয়, খুব সম্ভবত disk. Kernel প্রতি ৫ সেকেন্ডে একটি সূচকীয় গড় হিসাব করে: load = load × e + n × (1 − e), যেখানে এক মিনিটের জন্য e = exp(−5/60). নিচের simulator ৪ core-এর machine-এ এক মিনিটের spike দেখায়, আর তারপর একই load ৮.০ চার রকম machine-এ মাপে।

// Linux load average: every 5 s, load = load*e + n*(1-e), with
// e = exp(-5/60), exp(-5/300), exp(-5/900) for the 1, 5, 15 minute figures.
// n = tasks runnable or in uninterruptible sleep. Machine has 4 cores.
const cores = 4;
const decay = [60, 300, 900].map(w => Math.exp(-5 / w));
let load = [2, 2, 2];                             // steady n = 2 before spike
const nAt = s => (s >= 60 && s < 120 ? 16 : 2);   // 1-minute spike of 16 tasks
const verdict = l => l / cores < 0.7 ? 'ok' : l / cores <= 1 ? 'busy' : 'QUEUE';

console.log('min  n   load1  load5 load15  load1/core  trend    verdict');
for (let s = 0; s <= 600; s += 5) {
  if (s % 60 === 0 && (s <= 240 || s === 600)) {
    const [a, b, c] = load;
    console.log(String(s / 60).padStart(3), String(nAt(s)).padStart(2),
      a.toFixed(2).padStart(7), b.toFixed(2).padStart(6), c.toFixed(2).padStart(6),
      (a / cores).toFixed(2).padStart(11),
      (a > c + 0.5 ? 'rising' : a < c - 0.5 ? 'falling' : 'steady').padEnd(8), verdict(a));
  }
  const n = nAt(s);
  load = load.map((l, i) => l * decay[i] + n * (1 - decay[i]));
}

console.log('\nsame load 8.0 on different machines');
for (const c of [2, 4, 8, 16]) {
  const r = 8 / c;
  console.log(String(c).padStart(3) + ' cores  per core ' + r.toFixed(2).padStart(4) + '  ' +
    (r > 1 ? (8 - c) + ' tasks waiting on average' : r === 1 ? 'exactly full' : (c - 8) + ' cores free on average'));
}

min  n   load1  load5 load15  load1/core  trend    verdict
  0  2    2.00   2.00   2.00        0.50 steady   ok
  1 16    2.00   2.00   2.00        0.50 steady   ok
  2  2   10.85   4.54   2.90        2.71 rising   QUEUE
  3  2    5.26   4.08   2.84        1.31 rising   QUEUE
  4  2    3.20   3.70   2.79        0.80 steady   busy
 10  2    2.00   2.51   2.53        0.50 falling  ok

same load 8.0 on different machines
  2 cores  per core 4.00  6 tasks waiting on average
  4 cores  per core 2.00  4 tasks waiting on average
  8 cores  per core 1.00  exactly full
 16 cores  per core 0.50  8 cores free on average

Memory: free কম মানেই বিপদ নয়

Linux ফাঁকা RAM ফেলে রাখে না; disk-এর data রেখে দেয় page cache-এ। দরকার হলে এই জায়গা ছেড়ে দেয়। তাই দেখার সংখ্যা available, free নয়। আসল চাপ শুরু হয় যখন kernel-কে কষ্ট করে memory ফেরাতে হয়: swap-এ ঘন ঘন লেখা-পড়া, ধীর হয়ে যাওয়া। এই memory pressure সরাসরি মাপে PSI (/proc/pressure/memory, Linux 4.20 থেকে)। আরও তত্ত্ব আছে Linux-এ মেমরি পর্বে।

শেষ পর্যন্ত জায়গা না মিললে OOM killer নামে। Linux সাধারণত চাওয়া memory-র প্রতিশ্রুতি আগে দিয়ে দেয়, এই overcommit-এর দাম এখানেই শোধ হয়। Kernel একটি process বেছে SIGKILL পাঠায়, সাধারণত যার oom_score বেশি, মানে সাধারণত যে বেশি memory ধরে আছে। OOMScoreAdjust= দিয়ে এই পছন্দ প্রভাবিত করা যায়। দুটি ধরন আলাদা করুন: MemoryMax-এর কারণে হলে শুধু সেই cgroup-এর ভেতরে kill, journal-এ Memory cgroup out of memory; পুরো machine ফুরালে Out of memory: Killed process, আর শিকার যে কেউ হতে পারে। নিচের ঘটনাটি প্রথম ধরনের।

Memory: 186.4M (max: 512.0M)

Memory: 498.0M (max: 512.0M)
# kernel page cache ছেড়ে দিচ্ছে, অ্যাপ ধীর হচ্ছে

limit : 512 MiB = 524288 kB
used  : anon-rss 519844 kB + file-rss 1204 kB + kernel
reclaim failed, OOM killer in this cgroup

handler চলার সুযোগ নেই
চলমান request ভেঙে গেল
exit status 137, মানে 128 + 9
Restart=on-failure: 5 সেকেন্ড পরে আবার

$ systemctl status bazar-api
Active: activating (auto-restart) (Result: oom-kill)
Process: 2417 ExecStart=... (code=killed, signal=KILL)

$ journalctl -k -g "out of memory" --since "16:30"
kernel: Memory cgroup out of memory: Killed
  process 2417 (node) total-vm:1834212kB,
  anon-rss:519844kB, file-rss:1204kB, UID:998

$ journalctl -u bazar-api --since "16:30"
systemd[1]: bazar-api.service: A process of this
  unit has been killed by the OOM killer.
systemd[1]: bazar-api.service: Failed with result
  'oom-kill'.

ধীরে ধীরে সিঁড়ির মতো বাড়ে, নামে না → leak: কোড ঠিক
ট্রাফিকের সাথে বাড়ে, পরে নামে  → সীমা ছোট: load test
                                  করে MemoryMax বাড়ান

৮ · top, free, vmstat, iostat, df, du আর USE method

সমস্যার সময় অনুমান নয়, ক্রম দরকার। ২০১২ সালে Brendan Gregg ACM Queue-তে যে পদ্ধতি লেখেন, তার নাম USE method: প্রতিটি resource-এর জন্য তিনটি প্রশ্ন। Utilization: কত সময় ব্যস্ত? Saturation: কত কাজ সারিতে? Errors: ভুল হচ্ছে কি? Utilization একা ঠকায়, কারণ ৯০% ব্যস্ত কাউন্টারে লাইন নাও থাকতে পারে; লাইন দেখায় saturation. Metric-এর দিক থেকে USE আবার আসবে পর্ব ৬৩-তে, আর গভীর performance তদন্ত আছে পারফরম্যান্স আর observability পর্বে।

নিচের সবগুলো নমুনা আউটপুট, শেখার জন্য বানানো এবং version-ভেদে column আলাদা হতে পারে। একই ঘটনার ছবি: ২ vCPU, ৮ GB-র একটি server ধীর হয়ে গেছে।

$ top -bn1 | head -3                     # sample
top - 14:32:07 up 12 days,  3:11,  1 user,  load average: 6.42, 5.10, 3.87
Tasks: 142 total,   3 running, 139 sleeping,   0 stopped,   0 zombie
%Cpu(s): 38.2 us,  7.1 sy,  0.0 ni, 12.4 id, 41.0 wa,  0.0 hi,  1.3 si,  0.0 st

$ free -m                                # sample
               total        used        free      shared  buff/cache   available
Mem:            7820        7050         180          64         590         420
Swap:           2047        1460         587

$ vmstat 1 3                             # sample; line 1 is average since boot
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1 1458000 188000  12000 580000    3    5    40    60  300  600 12  3 83  2  0
 2  6 1460200 181000  12000 578000  820  640  9120  1530 2210 4310 38  7 12 41  0
 3  5 1461100 180000  12000 577000  790  710  8840  1660 2180 4250 37  8 13 40  0

$ iostat -xz 1                           # sample; some columns removed
Device     r/s    w/s   r_await  w_await  aqu-sz  %util
vda      412.0   88.0     18.40    41.20    9.80   98.7

$ df -h                                  # sample
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   37G  1.1G  97% /
/dev/vdb1       100G   61G   34G  65% /data

$ du -xsh /var/log/* | sort -h | tail -2   # sample
1.2G    /var/log/journal
19G     /var/log/bazar-api

এবার এই সব নমুনার মূল অংশ একটি heredoc-এ রেখে ছোট একটি triage script চালাই। এটি সত্যিকারের সিস্টেমের কোনো কিছু পড়ে না, শুধু নিজের ভেতরের লেখা।

cat > snapshot.txt <<'EOF'
top - 14:32:07 up 12 days,  3:11,  1 user,  load average: 6.42, 5.10, 3.87
%Cpu(s): 38.2 us,  7.1 sy,  0.0 ni, 12.4 id, 41.0 wa,  0.0 hi,  1.3 si,  0.0 st
               total        used        free      shared  buff/cache   available
Mem:            7820        7050         180          64         590         420
Swap:           2047        1460         587
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   37G  1.1G  97% /
/dev/vdb1       100G   61G   34G  65% /data
tmpfs           3.9G     0  3.9G   0% /dev/shm
EOF
cores=2; warns=0
alert() { echo "WARN  $1"; warns=$((warns + 1)); }
over()  { awk -v a="$1" -v b="$2" 'BEGIN { exit !(a > b) }'; }

load1=$(sed -n 's/.*load average: \([0-9.]*\),.*/\1/p' snapshot.txt)
per=$(awk -v l="$load1" -v c="$cores" 'BEGIN { printf "%.2f", l / c }')
echo "load1=$load1 cores=$cores per-core=$per"
over "$per" 1 && alert "tasks are queueing"

wa=$(awk -F'[ ,]+' '/^%Cpu/ { print $10 }' snapshot.txt)
echo "iowait=$wa%"
over "$wa" 20 && alert "much time lost waiting for disk"

read -r avail pct < <(awk '/^Mem:/ { printf "%d %.1f\n", $7, 100 * $7 / $2 }' snapshot.txt)
echo "available=$avail MiB ($pct%)"
over 10 "$pct" && alert "less than 10% memory available"

read -r used swp < <(awk '/^Swap:/ { print $3, int(100 * $3 / $2) }' snapshot.txt)
echo "swap used=$used MiB ($swp%)"
over "$swp" 50 && alert "more than half of swap used"

while read -r mnt use; do alert "disk $mnt at $use%"; done < <(
  awk '$5 ~ /^[0-9]+%$/ && $5 + 0 >= 90 { print $6, $5 + 0 }' snapshot.txt)
echo "summary: $warns warnings"

load1=6.42 cores=2 per-core=3.21
WARN  tasks are queueing
iowait=41.0%
WARN  much time lost waiting for disk
available=420 MiB (5.4%)
WARN  less than 10% memory available
swap used=1460 MiB (71%)
WARN  more than half of swap used
WARN  disk / at 97%
summary: 5 warnings

৯ · AI-এর যুগে service চালানো

AI কয়েক সেকেন্ডে unit file লিখে দেয়, আর ফাইলটি দেখতে ঠিকঠাকই লাগে। কিন্তু ফাইলটি production-এ root হিসেবে চলবে। তাই এখানে “চলছে” যথেষ্ট প্রমাণ নয়। AI সাধারণত যে ভুলগুলো করে:

AI-এর দেওয়া unit বা কমান্ড হাতে পেলে

• systemd-analyze verify চালিয়েছি, আর প্রতিটি অচেনা setting man page-এ মিলিয়েছি
• Service root হিসেবে চলছে না, আর কোনো secret unit file-এ নেই
• Restart-এর হিসাব করেছি, আর ইচ্ছা করে একবার crash ঘটিয়ে দেখেছি limit থামায় কি না
• systemctl stop দিয়ে দেখেছি service SIGTERM-এ পরিষ্কারভাবে বের হয়
• rm -rf, kill -9 বা মুছে ফেলার কমান্ড চালানোর আগে কী হারাবে তা জেনেছি, আর throwaway server-এ পরীক্ষা করেছি
• Cloud-এ পরীক্ষা করলে খরচ হতে পারে জেনেছি, budget alert রেখেছি, শেষে server মুছেছি