Bash automation — নিরাপদ script, cron আর systemd timer

১ · কখন script লিখবেন — Bash, Python না Ansible

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। প্রতি রাতে একজন প্রকৌশলী server-এ ঢুকে database-এর backup নেন, ফাইলটি অন্য জায়গায় পাঠান আর পুরোনো backup মোছেন। কাজটি ১৫ মিনিটের। পর্ব ০৭-এর ভাষায় এটি toil: হাতে করা, বারবারের, আর এতে স্থায়ী কোনো উন্নতি নেই। একদিন তিনি ছুটিতে গেলেন, আর সেদিন backup হলো না।

হাতের কাজ script-এ আনার আগে পর্ব ০৭-এর হিসাবটি করুন: কাজটি বছরে কত ঘণ্টা খায়, আর script বানাতে ও রক্ষণাবেক্ষণে কত ঘণ্টা লাগবে। তারপর ঠিক করুন, কোন হাতিয়ার। Bash হলো কমান্ড জোড়া লাগানোর আঠা। Data structure বা জটিল যুক্তি এর শক্তি নয়।

একটি ছোট হিসাব। ওপরের কাজটি বছরে ৩৬৫ × ১৫ = ৫,৪৭৫ মিনিট, অর্থাৎ প্রায় ৯১ ঘণ্টা। ধরে নিই script লিখতে, পরীক্ষা করতে আর monitoring বসাতে ১২ ঘণ্টা লাগে, আর বছরে রক্ষণাবেক্ষণে যায় ৮ ঘণ্টা। তাহলে প্রথম বছরেই প্রায় ৭১ ঘণ্টা বাঁচে। উল্টো দিকও আছে: বছরে দুবারের ৫ মিনিটের নিরীহ কাজের জন্য script বানালে খরচই বেশি। তবে যে কাজ কম হয় কিন্তু ভুল হলে বড় ক্ষতি, যেমন database failover, সেখানে সময়ের হিসাব ছাড়াও script বা runbook দরকার, কারণ চাপের মুহূর্তে মানুষ ভুল করে।

একটি প্রচলিত নিয়ম: Google-এর Shell Style Guide বলে, script ১০০ লাইনের বেশি হলে বা জটিল নিয়ন্ত্রণ-প্রবাহ এলে আরও গোছানো ভাষায় নেওয়ার কথা ভাবতে হবে। সীমাটি আইন নয়, তবে সংকেত হিসেবে ভালো। Ansible নিয়ে বিস্তারিত পর্ব ৫৬-এ, আর Terraform পর্ব ৫২-তে। Python দিয়ে automation দেখতে পারেন Python-এর automation পর্বে।

২ · Shebang, variable আর quoting — ছোট চিহ্নের বড় দাম

Script-এর প্রথম লাইনটিকে বলে shebang. এটি kernel-কে জানায়, এই ফাইল কোন প্রোগ্রাম দিয়ে চলবে।

#!/usr/bin/env bash
# env finds bash through PATH. #!/bin/bash is also common.
name="Rahim"              # no spaces around =
echo "Hello, $name"

chmod +x hello.sh দিলে ./hello.sh লিখে চালানো যায় (অনুমতির কথা পর্ব ০৮-এ)। একটি সতর্কতা: Debian আর Ubuntu-তে /bin/sh সাধারণত dash, Bash নয়। তাই #!/bin/sh লিখে Bash-এর [[ ]] বা array ব্যবহার করলে ভুল হতে পারে। Bash-এর সুবিধা চাইলে shebang-এও Bash লিখুন।

Quoting: সবচেয়ে সস্তা নিরাপত্তা

Quote ছাড়া variable লিখলে shell দুটি বাড়তি কাজ করে। মানটিকে ফাঁকা জায়গায় ভাঙে (word splitting), আর * থাকলে তাকে ফাইলের নামে বদলায় (glob). Quoting এই দুটি বন্ধ করে।

#!/usr/bin/env bash
# Three files. The target has a space in its name.
T=$(mktemp -d)
trap 'rm -rf -- "$T"' EXIT
cd "$T"

fresh() { rm -f -- *; touch "old backup.tar" old backup.tar; }
left()  { printf 'left:'; printf ' [%s]' *; echo; }

target="old backup.tar"

echo "--- without quotes ---"
fresh
set -- $target
echo "shell sees $# arguments: [$1] [$2]"
rm -f $target
left

echo "--- with quotes ---"
fresh
rm -f -- "$target"
left

echo "--- empty variable ---"
DIR=""
printf 'the command would become: rm -rf %s*\n' "$DIR/"
if ( : "${DIR:?}" ) 2>/dev/null; then
  echo "guard passed"
else
  echo 'guard ${DIR:?} stopped the script before rm'
fi

৩ · set -euo pipefail — ভুলে থামা, আর তার অবাক করা দিক

Bash-এর default আচরণ অবাক করার মতো: একটি কমান্ড ব্যর্থ হলেও পরের লাইন চলে। নিচের script-টি একটি বানান ভুলে কী করতে পারে, ধাপে ধাপে দেখুন। ধরুন cron এটিকে চালিয়েছে, তাই শুরুর ফোল্ডার ব্যবহারকারীর home.

1#!/usr/bin/env bash2set -euo pipefail   # ধাপ ৬ থেকে3cd /srv/app/tmpp    # বানান ভুল4rm -rf ./*5cp /srv/build/app.tar .6echo "deploy done"

তিনটি option আলাদা কাজ করে। একসাথে লেখা হয় বলে একটি মনে হয়, কিন্তু প্রতিটির আলাদা নাম আছে।

Pipeline-এর exit code default-এ শুধু শেষ ধাপের। ফলে মাঝের ব্যর্থতা ঢাকা পড়ে। একই script দুভাবে চালিয়ে দেখুন। ব্যর্থতা ইচ্ছাকৃত, তবে আলাদা process-এ চলছে, তাই বাইরের প্রোগ্রাম ঠিকভাবেই শেষ হয়।

#!/usr/bin/env bash
# The same pipeline, without and with pipefail. sales.log does not exist.
T=$(mktemp -d)
trap 'rm -rf -- "$T"' EXIT
cd "$T"

cat > report_a.sh <<'EOF'
set -e
cat sales.log 2>/dev/null | sort > report.txt
echo "report ready, sending $(wc -l < report.txt) lines"
EOF

cat > report_b.sh <<'EOF'
set -eo pipefail
cat sales.log 2>/dev/null | sort > report.txt
echo "report ready, sending $(wc -l < report.txt) lines"
EOF

echo "--- set -e only ---"
bash report_a.sh
echo "script exit code: $?"

echo "--- set -eo pipefail ---"
bash report_b.sh
echo "script exit code: $?"

echo "--- what each stage returned ---"
cat sales.log 2>/dev/null | sort | wc -l
echo "PIPESTATUS: ${PIPESTATUS[*]}"

একটি বাড়তি অভ্যাস: set -e থাকলেও গুরুত্বপূর্ণ জায়গায় ব্যর্থতার বার্তা নিজে লিখুন, যেমন cd /srv/app || { echo "cannot enter /srv/app" >&2; exit 1; }. এতে রাতের log পড়ে সকালে বোঝা যায়, ঠিক কোন ধাপে কেন থেমেছিল।

set -e-এর জানা ফাঁদ

set -euo pipefail সিট-বেল্টের মতো: দরকারি, কিন্তু দুর্ঘটনা পুরো ঠেকায় না। নিচের প্রতিটি আচরণ Bash 5.2-তে চালিয়ে মেলানো।

৪ · Function, argument আর exit code

লম্বা script-কে ছোট function-এ ভাগ করুন। Bash-এর function কিছুটা আলাদা: সে মান “ফেরত” দেয় না। সে দেয় exit code (0 থেকে 255), আর লেখা দেয় stdout-এ।

#!/usr/bin/env bash
set -euo pipefail

usage() { echo "usage: $0 PATH LIMIT_PERCENT" >&2; exit 2; }

# Prints the used percentage of a path, e.g. 73
used_percent() {
  local path=$1
  df --output=pcent "$path" | tail -n 1 | tr -dc '0-9'
}

[ "$#" -eq 2 ] || usage        # $# = number of arguments
path=$1
limit=$2

used=$(used_percent "$path")
if [ "$used" -ge "$limit" ]; then
  echo "ALERT: $path is ${used}% full" >&2
  exit 1
fi
echo "ok: $path is ${used}% full"

$1, $2 হলো argument, $# তাদের সংখ্যা, "$@" পুরো তালিকা, আর shift প্রথমটি বাদ দেয়। Function-এর ভেতরের variable-এ local দিন, নইলে সেটি পুরো script-এ ছড়ায়। Exit code-এর কিছু অর্থ প্রচলিত। Cron, systemd আর CI সবাই এই সংখ্যা দেখেই সফল বা ব্যর্থ ঠিক করে, তাই ব্যর্থ হলে script-কে অবশ্যই non-zero দিয়ে শেষ করতে হবে।

একটি অভ্যাস: বার্তা আর ফলাফল আলাদা রাখুন। ফলাফল stdout-এ, error আর log stderr-এ (>&2). তাহলে পরের কমান্ড pipe দিয়ে শুধু ফলাফল পায়।

Script ভুল করলে কীভাবে খুঁজবেন

তিনটি সহজ হাতিয়ার মনে রাখুন। bash -n script চালায় না, শুধু syntax পড়ে। bash -x প্রতিটি কমান্ড চালানোর আগে + চিহ্ন দিয়ে ছাপে, আর variable-এর আসল মান বসিয়ে দেখায়। ফলে ধরা পড়ে $DIR আসলে কী ছিল। শুধু একটি অংশ দেখতে চাইলে সেখানে set -x লিখে শেষে set +x দিন।

bash -n deploy.sh          # syntax check only, runs nothing
bash -x deploy.sh          # print each command after expansion
shellcheck deploy.sh       # static analysis, if installed

৫ · পরিষ্কার করে বের হওয়া — mktemp আর trap

অস্থায়ী ফাইলের নাম হাতে ঠিক করবেন না। /tmp/backup.tmp ধরনের নিশ্চিত নাম দুটি কাজের মধ্যে ধাক্কা লাগায়। আর /tmp সবার জন্য খোলা বলে অনুমান করা যায় এমন নাম নিরাপত্তার ঝুঁকিও। mktemp অনন্য নাম বানায়, আর শুধু মালিকের অনুমতি রাখে।

1#!/usr/bin/env bash2set -euo pipefail3WORK=$(mktemp -d)4trap 'rm -rf -- "$WORK"' EXIT5pg_dump shop > "$WORK/shop.sql"6gzip "$WORK/shop.sql"7upload_backup "$WORK/shop.sql.gz"8echo "backup ok"

EXIT trap স্বাভাবিক শেষ, set -e-এর থামা আর exit সব ক্ষেত্রেই চলে। Bash-এ Ctrl+C (SIGINT) আর SIGTERM-এ থামলেও চলে; এই আচরণ অন্য shell-এ একই নাও হতে পারে। কিন্তু SIGKILL বা বিদ্যুৎ চলে গেলে কিছুই চলে না। তাই পুরোনো অস্থায়ী ফাইল মোছার একটি আলাদা ব্যবস্থাও দরকার হতে পারে। Signal নিয়ে বিস্তারিত অপারেটিং সিস্টেমের signal পর্বে পাবেন।

৬ · বারবার চালালেও নিরাপদ — idempotent script, dry-run, log আর retry

Idempotency মানে কাজটি একবার করা আর দশবার করার ফল একই। লিফটের বোতাম ভাবুন: পাঁচবার চাপলেও লিফট একবারই আসে। Automation-এ এটি জরুরি, কারণ script মাঝপথে ভেঙে যায়, আর তখন “আবার চালান” হওয়া চাই সবচেয়ে নিরাপদ উত্তর।

এবার backup rotation-সহ একটি ছোট কাজ দুবার চালানো যাক। ফাইলের নাম db-2026-03-01.tar.gz ধরনের। এই ISO তারিখের নাম বর্ণানুক্রমে সাজালে সময়ের ক্রমও পাওয়া যায়, তাই glob-এর সাজানো তালিকাই পুরোনো থেকে নতুনের ক্রম। ফাইলগুলো খালি, শুধু নাম দিয়ে কৌশলটি দেখানো।

#!/usr/bin/env bash
# Idempotent setup + backup rotation. The second run must change nothing.
set -euo pipefail
shopt -s nullglob
T=$(mktemp -d)
trap 'rm -rf -- "$T"' EXIT
cd "$T"
mkdir backups
for d in 01 02 03 04 05; do : > "backups/db-2026-03-$d.tar.gz"; done

job() {
  local today="2026-03-06" keep=3 i
  mkdir -p backups logs
  touch app.conf
  if grep -qx 'retention=3' app.conf; then echo "conf: already set"
  else echo 'retention=3' >> app.conf; echo "conf: added retention=3"; fi

  if [ -e "backups/db-$today.tar.gz" ]; then echo "backup: $today exists"
  else : > "backups/db-$today.tar.gz"; echo "backup: created $today"; fi

  local files=(backups/db-*.tar.gz)          # sorted: oldest first
  local extra=$(( ${#files[@]} - keep ))
  for (( i = 0; i < extra; i++ )); do
    rm -- "${files[i]}"
    echo "rotate: removed ${files[i]#backups/}"
  done
  [ "$extra" -gt 0 ] || echo "rotate: nothing to remove"
}

echo "=== first run ===";  job
echo "=== second run ==="; job
echo "=== final state ==="
printf '%s\n' backups/*
echo "conf lines: $(wc -l < app.conf)"

Dry-run, log আর retry

Dry-run: --dry-run flag দিলে script শুধু বলে কী করত, করে না। ঝুঁকির কমান্ডগুলো একটি ছোট run function-এর ভেতর দিয়ে চালালেই এটি হয়ে যায় (পরের অংশের পুরো script দেখুন)। অনেক tool-এও আছে, যেমন rsync --dry-run.

Log: রাত ৩টার script-এর একমাত্র সাক্ষী তার log. প্রতিটি লাইনে UTC সময়, আর কী ঘটল সেটি লিখুন। logger -t backup "done" কমান্ড system log-এ লেখে। Cron-এ দুটি ধারাই ফাইলে নিতে চাইলে লিখুন >>job.log 2>&1. ক্রমটি জরুরি: আগে >>job.log, পরে 2>&1; উল্টো লিখলে error ফাইলে যাবে না। Log ফাইলও বাড়তে থাকে, তাই Linux-এর logrotate দিয়ে তারও মেয়াদ ঠিক করুন। অনেক server-এর log একসাথে খোঁজার কথা পর্ব ৬৪-এ।

Retry: Network ক্ষণিকের জন্য ব্যর্থ হতেই পারে। পর্ব ০৬-এর exponential backoff আর jitter এখানেও খাটে: অপেক্ষা দ্বিগুণ হতে থাকে, আর একটু এলোমেলো মেশানো হয়, যাতে অনেক server একসাথে ঝাঁপিয়ে না পড়ে (thundering herd).

# retry MAX_TRIES command args...
retry() {
  local max=$1 n=1 delay=2
  shift
  until "$@"; do
    if [ "$n" -ge "$max" ]; then
      echo "giving up after $n tries: $*" >&2
      return 1
    fi
    sleep $(( delay + RANDOM % 3 ))     # jitter: 0 to 2 extra seconds
    delay=$(( delay * 2 ))              # 2, 4, 8, 16 ...
    n=$(( n + 1 ))
  done
}

# -f makes curl fail on HTTP errors; without it a 500 page counts as success
retry 5 curl -fsS -o report.csv https://example.com/report.csv

৫ বার চেষ্টায় অপেক্ষা ৪ বার, jitter ছাড়া মোট ২ + ৪ + ৮ + ১৬ = ৩০ সেকেন্ড। মনে রাখবেন, যে কাজ idempotent নয়, তাকে retry করলে কাজটি দুবার হতে পারে। তাই retry আর idempotency একসাথে ভাবতে হয়।

৭ · Cron — পাঁচটি ঘর আর তার ফাঁদ

Crontab-এর প্রতিটি লাইনে পাঁচটি সময়ের ঘর, তারপর কমান্ড। crontab -e দিয়ে নিজের তালিকা সম্পাদনা করা যায়, আর /etc/cron.d/-এর ফাইলে কমান্ডের আগে ব্যবহারকারীর নামও লিখতে হয়।

একটি অদ্ভুত নিয়ম: “তারিখ” আর “বার”, দুটিই নির্দিষ্ট করলে শর্ত হয় অথবা, এবং নয়। 0 0 2 * 5 মানে “মাসের ২ তারিখে, অথবা যেকোনো শুক্রবারে”। নিচের simulator একটি কাল্পনিক ঘড়ি মিনিটে মিনিটে এগিয়ে এই নিয়মগুলো মিলিয়ে দেখে। Server ধরে নেওয়া হয়েছে UTC-তে।

// Next-run calculator for 5-field cron on a simulated clock. Edit and Run again.
const START = Date.UTC(2026, 1, 27, 23, 50);  // Fri 27 Feb 2026, 23:50 UTC
const JOBS = ["*/15 * * * *", "30 2 * * *", "0 9 * * 0-4", "0 0 1 * *", "0 0 2 * 5", "0 3 31 2 *"];
function parse(field, lo, hi) {               // "1-5", "*/15", "0,30"
  const set = new Set();
  for (const part of field.split(",")) {
    const [range, step = "1"] = part.split("/");
    const [a, b] = range === "*" ? [lo, hi] : range.split("-").map(Number);
    for (let v = a; v <= (b ?? a); v += Number(step)) set.add(v);
  }
  return set;
}
function matcher(expr) {
  const [mi, hr, dom, mon, dow] = expr.split(" ");
  const [m, h, d, o, w] = [parse(mi, 0, 59), parse(hr, 0, 23),
    parse(dom, 1, 31), parse(mon, 1, 12), parse(dow, 0, 7)];
  if (w.has(7)) w.add(0);                     // 0 and 7 both mean Sunday
  const anyDay = dom[0] === "*" || dow[0] === "*";
  return t => {
    const a = d.has(t.getUTCDate()), b = w.has(t.getUTCDay());
    return m.has(t.getUTCMinutes()) && h.has(t.getUTCHours()) &&
      o.has(t.getUTCMonth() + 1) && (anyDay ? a && b : a || b);
  };
}
const show = t => t.toUTCString().slice(0, 3) + " " + t.toISOString().slice(0, 16).replace("T", " ");
const dhaka = t => new Date(t.getTime() + 6 * 3600e3).toISOString().slice(11, 16);
for (const expr of JOBS) {
  const hit = matcher(expr), runs = [];
  for (let i = 1; i <= 5 * 366 * 1440 && runs.length < 2; i++) {  // max 5 years
    const t = new Date(START + i * 60000);
    if (hit(t)) runs.push(show(t) + " UTC = " + dhaka(t) + " Dhaka");
  }
  console.log(expr.padEnd(14), runs.length ? "" : "never in 5 years");
  runs.forEach(r => console.log("   " + r));
}

Cron-এর ফাঁদগুলো

একটি বাস্তবসম্মত crontab এমন দেখায়। প্রথম সারির variable-গুলো নিচের সব লাইনে খাটে।

PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@example.com

# 20:30 UTC = 02:30 Dhaka. Output goes to a log, errors stay visible to MAILTO.
30 20 * * * /usr/local/bin/nightly-backup.sh /srv/backups >>/var/log/backup.log

Time zone-এর একটি গল্প। ধরুন দল ঠিক করল, ব্যবহারকারী যখন ঘুমিয়ে, তখন ভারী backup চলবে। কেউ লিখলেন 30 2 * * *. Server UTC-তে, তাই কাজটি চলল ঢাকার সকাল ০৮:৩০-এ, ঠিক অফিস শুরুর সময়। অ্যাপ ধীর হলো, আর কেউ বুঝলেন না কেন। সমাধান সহজ: timedatectl দিয়ে server-এর ঘড়ি দেখা, আর crontab-এ মন্তব্যে দুই সময়ই লেখা। বাংলাদেশে এখন daylight saving নেই। কিন্তু যেসব দেশে আছে, সেখানে ঘড়ি বদলের রাতে স্থানীয় সময়ের কাজ বাদ পড়তে বা দুবার চলতে পারে। Server UTC-তে রাখলে এই ঝামেলাও থাকে না।

কোন ব্যবহারকারী হিসেবে চালাবেন? root-এর crontab সবচেয়ে সহজ, কিন্তু সেখানে ভুল হলে ক্ষতির সীমা থাকে না। কাজটির জন্য আলাদা সীমিত ব্যবহারকারী বানান, যে শুধু দরকারি ফোল্ডার ছুঁতে পারে। Password crontab-এর লাইনে লিখবেন না; chmod 600 করা ফাইলে বা secret manager-এ রাখুন।

নীরব ব্যর্থতা ধরার সবচেয়ে ভালো উপায় হলো উল্টো করে ভাবা: কাজ ব্যর্থ হলে খবর দেওয়া নয়, কাজ সফল হলে খবর দেওয়া। Script-এর শেষে একটি monitoring ঠিকানায় সংকেত যায়। নির্দিষ্ট সময়ে সংকেত না এলেই alert বাজে। এতে script না চললেও ধরা পড়ে, যা script-এর ভেতরের কোনো error handling পারে না। Alert নিয়ে বিস্তারিত পর্ব ৬৬-তে।

৮ · Overlap আর lock — দুটি চলা একসাথে নয়

একটি কাল্পনিক SMS কাজ প্রতি ৫ মিনিটে চলে (*/5 * * * *). এটি last_id ফাইল পড়ে, নতুন বিলের SMS পাঠায়, শেষে last_id লেখে। সাধারণত ১ মিনিটে শেষ হয়। একদিন SMS gateway ধীর হলো, আর কাজটি ৭ মিনিট নিল। ফলে তৈরি হলো একটি race condition. ধরে নিই ৫০১–৫২০ নম্বর বিল বাকি, আর ০২:০৩-এ আরও ৩টি (৫২১–৫২৩) আসে।

touch job.lock ধরনের পুরোনো lock file-এর সমস্যা হলো, script ক্র্যাশ করলে ফাইলটি থেকে যায়, আর পরের সব চলা চিরকাল আটকে থাকে। আবার “ফাইল আছে কি” দেখা আর বানানোর মাঝেও ফাঁক থাকে। flock kernel-এর lock নেয়, যা file descriptor বন্ধ হলেই ছাড়ে, তাই process মরে গেলেও আটকায় না। Crontab-এ এক লাইনেই লেখা যায়, আবার script-এর ভেতরেও বসানো যায়।

# In a crontab line: skip this run if the previous one holds the lock
*/5 * * * * flock -n /run/lock/sms.lock /usr/local/bin/send-sms.sh

# Inside a script: fd 9 stays open until the script ends
exec 9>/run/lock/sms.lock
flock -n 9 || { echo "previous run still active, skipping" >&2; exit 0; }

-n মানে অপেক্ষা নয়; -w 30 দিলে ৩০ সেকেন্ড অপেক্ষা করে। Crontab-এর এক লাইনের রূপে lock না পেলে exit code হয় 1; -E 0 দিলে 0 হয়। মনে রাখবেন, lock শুধু একটি মেশিনের ভেতরে কাজ করে। একই cron দুটি server-এ চললে এই lock কিছুই থামাবে না। সেই সমস্যা নিচের ভাবনার প্রশ্নে আছে।

সব একসাথে: একটি পূর্ণ script

নিচের উদাহরণে এই পর্বের সব অভ্যাস এক জায়গায় আছে। Argument যাচাই, lock, অস্থায়ী ফোল্ডার, dry-run, log আর rotation. shop একটি কাল্পনিক database.

#!/usr/bin/env bash
# nightly-backup.sh — usage: nightly-backup.sh [--dry-run] DEST_DIR
set -euo pipefail

readonly KEEP=7
DRY_RUN=0

log() { printf '%s %s\n' "$(date -u +%FT%TZ)" "$*" >&2; }
die() { log "ERROR: $*"; exit 1; }
run() { if (( DRY_RUN )); then log "DRY-RUN: $*"; else "$@"; fi; }

if [[ ${1:-} == --dry-run ]]; then DRY_RUN=1; shift; fi
DEST=${1:?usage: nightly-backup.sh [--dry-run] DEST_DIR}
[[ -d $DEST ]] || die "no such directory: $DEST"

exec 9>/run/lock/nightly-backup.lock
flock -n 9 || { log "previous run still active, skipping"; exit 0; }

WORK=$(mktemp -d)
trap 'rm -rf -- "$WORK"' EXIT

FILE="db-$(date -u +%F).sql.gz"
pg_dump shop | gzip > "$WORK/$FILE"
run mv -- "$WORK/$FILE" "$DEST/"

shopt -s nullglob
backups=("$DEST"/db-*.sql.gz)
for (( i = 0; i < ${#backups[@]} - KEEP; i++ )); do
  run rm -- "${backups[i]}"
done
log "finished: $FILE"

৯ · systemd timer বনাম cron

আধুনিক Linux-এ systemd সব service চালায়, আর তার systemd timer cron-এর একটি শক্তিশালী বিকল্প। এখানে দুটি ফাইল লাগে: .service বলে কী চালাতে হবে, .timer বলে কখন। Service unit-এর ভেতরের কথা পর্ব ১১-তে।

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly database backup

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/nightly-backup.sh /srv/backups

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup every night

[Timer]
OnCalendar=*-*-* 02:30:00 Asia/Dhaka
Persistent=true
RandomizedDelaySec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer        # next and last run
systemd-analyze calendar "*-*-* 02:30:00 Asia/Dhaka"   # check the expression
journalctl -u backup.service -n 50        # logs of the last runs
sudo systemctl start backup.service       # run it once now, by hand

সিদ্ধান্তের সহজ নিয়ম: ছোট, অল্প গুরুত্বের কাজে cron যথেষ্ট। Backup-এর মতো গুরুত্বপূর্ণ কাজে timer ভালো। Cloud-এ তৃতীয় পথও আছে: provider-এর managed scheduler (যেমন Amazon EventBridge Scheduler, Azure Logic Apps-এর recurrence, Google Cloud Scheduler), যা কোনো একটি server-এর ওপর নির্ভর করে না। Kubernetes-এও CronJob আছে।

১০ · AI-এর যুগে — AI-এর লেখা script চালানোর আগে

AI কয়েক সেকেন্ডে script লিখে দেয়, আর সেটি দেখতে গোছানো। কিন্তু script-এর ভুল প্রায়ই খালি variable, ব্যর্থতা বা দ্বিতীয়বার চালানোর সময় ধরা পড়ে, যা সাধারণ পরীক্ষায় আসে না। তাই একে অপরিচিত কারও লেখা কোডের মতো পড়ুন, বিশেষ করে সেটি rm, sudo বা cloud CLI ছুঁলে।

AI-এর script চালানোর আগে

• প্রতিটি লাইন পড়েছি; যে লাইন বুঝিনি, সেটি জেনে নিয়েছি
• ShellCheck চালিয়েছি, আর সতর্কবার্তাগুলোর কারণ বুঝেছি
• খালি variable আর ভুল argument দিয়ে পরীক্ষা করেছি, ফাঁকা পরীক্ষার ফোল্ডারে
• Dry-run দিয়ে দেখেছি, তারপর throwaway VM-এ চালিয়েছি
• দুবার চালিয়েছি, আর দ্বিতীয়বারে কিছু বদলায়নি
• ইচ্ছা করে একটি ধাপ ব্যর্থ করেছি: exit code non-zero, clean-up হয়েছে, log আছে
• Script-এ বা prompt-এ কোনো secret নেই; cron-এর ছোট environment-এ চলেছে