systemd কী: কীভাবে কাজ করে ও লিনাক্সে সার্ভিস পরিচালনা

systemd হলো ইনিশিয়ালাইজেশন সিস্টেম ও সার্ভিস ম্যানেজার, যা Debian, Ubuntu, Fedora, RHEL ও তাদের উত্তরসূরি বেশিরভাগ আধুনিক লিনাক্স ডিস্ট্রিবিউশনে ব্যবহৃত হয়। বুট হওয়ার পর কার্নেল systemd-কে PID 1 নম্বরের প্রথম প্রসেস হিসেবে চালায়, আর তারপর systemd নেটওয়ার্ক চালু করে, ডিস্ক মাউন্ট করে, ওয়েব সার্ভার, ডেটাবেস ও বাকি সব সার্ভিস চালু করে। সংক্ষেপে "systemd কী" প্রশ্নের উত্তর: এটি একটি "ম্যানেজার", যে জানে কোন সার্ভিস চলা উচিত, কোন ক্রমে শুরু হবে, এবং কোনো সার্ভিস ভেঙে পড়লে কী করতে হবে।

নিশ্চিত হতে চাইলে যাচাই করুন যে আপনার সিস্টেমে systemd চলছে:

$ ps -p 1 -o comm=
systemd

systemd কেন তৈরি হলো

আগে লিনাক্স ব্যবহার করত SysV init: /etc/init.d/-এর শেল স্ক্রিপ্টের একটি সেট, যেগুলো একে একে চলত। পদ্ধতিটি বোঝা সহজ ছিল, কিন্তু ধীর ও ভঙ্গুর। প্রতিটি স্ক্রিপ্ট নিজের PID ফাইল লিখত, প্রসেস বেঁচে আছে কি না তা নিজেই ঠিক করত, আর ভেঙে যাওয়া সার্ভিস আবার চালুর ব্যবস্থা আলাদাভাবে যোগ করতে হতো।

systemd এই সমস্যাগুলো কেন্দ্রীয়ভাবে সমাধান করে:

• সমান্তরাল চালু। নির্ভরতা না থাকলে সার্ভিসগুলো একসঙ্গে চালু হয়, তাই বুট দ্রুত হয়।
• নির্ভরতা ও ক্রম। সার্ভিসের বর্ণনায় স্পষ্ট লেখা থাকে কী লাগবে (যেমন নেটওয়ার্ক) এবং কার পরে চালু হবে।
• তদারকি। systemd cgroups-এর মাধ্যমে সার্ভিসের সব প্রসেস চেনে এবং ব্যর্থ হলে পুনরায় চালু করতে পারে।
• এক লগ। সব সার্ভিসের আউটপুট journald সংগ্রহ করে, আর এক কমান্ডে সব দেখা যায়।
• একই ইন্টারফেস। প্রতিটি সার্ভিস একইভাবে নিয়ন্ত্রিত হয়: systemctl start|stop|restart|status।

সার্ভিস ম্যানেজারের বাইরে systemd প্রকল্পে আরও কিছু উপাদান আছে: journald (লগ), logind (ব্যবহারকারী সেশন), timesyncd (সময় সিঙ্ক), resolved (DNS) ও networkd (নেটওয়ার্ক)। সব ডিস্ট্রিবিউশন সবগুলো ব্যবহার করে না, কিন্তু PID 1 হিসেবে systemd এবং journald প্রায় সব জায়গায় পাওয়া যায়।

Unit: systemd-এর উপাদান

systemd যা কিছু পরিচালনা করে, তার সবই বর্ণনা করা হয় unit দিয়ে। Unit হলো INI ফরম্যাটের একটি টেক্সট ফাইল, এবং এর ধরন নির্ধারিত হয় এক্সটেনশন দিয়ে।

unit ফাইল কোথায় থাকে

Unit ফাইল কয়েকটি ডিরেক্টরিতে থাকে, আর প্রতিটির অগ্রাধিকার আলাদা:

• /usr/lib/systemd/system/ (Debian ও Ubuntu-তে /lib/systemd/system/-ও) — প্যাকেজের ইনস্টল করা unit। সরাসরি সম্পাদনা করবেন না: প্যাকেজ আপডেট হলে আপনার পরিবর্তন মুছে যাবে।
• /etc/systemd/system/ — অ্যাডমিনিস্ট্রেটরের unit ও ওভাররাইড। এর অগ্রাধিকার সবচেয়ে বেশি।
• /run/systemd/system/ — সিস্টেম চলাকালীন তৈরি অস্থায়ী unit।

সব ওভাররাইড সহ unit-এর চূড়ান্ত বিষয়বস্তু দেখতে systemctl cat nginx.service ব্যবহার করুন।

রানলেভেলের বদলে target

পুরোনো runlevel-এর জায়গা নিয়েছে target। multi-user.target হলো গ্রাফিক্স ছাড়া সাধারণ সার্ভার মোড, graphical.target গ্রাফিক্যাল ইন্টারফেসসহ, আর rescue.target একক-ব্যবহারকারী পুনরুদ্ধার মোড। ডিফল্ট target দেখা যায় systemctl get-default দিয়ে, আর বদলানো যায় systemctl set-default multi-user.target দিয়ে।

systemctl: সার্ভিস নিয়ন্ত্রণ

systemctl systemd-এর প্রধান টুল। বেশিরভাগ কমান্ড সিস্টেমের অবস্থা বদলায় এবং sudo লাগে।

systemctl status কীভাবে পড়বেন

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

Loaded লাইন বলে unit কোথা থেকে নেওয়া হয়েছে এবং স্বয়ংক্রিয় চালু সক্রিয় কি না (enabled)। Active লাইন বর্তমান অবস্থা: active (running), inactive (dead) বা failed। CGroup অংশে সার্ভিসের সব প্রসেস দেখা যায় — এভাবেই systemd জানে কোন প্রসেস তার।

enable ও start-এর পার্থক্য

এটি প্রায়ই বিভ্রান্তির কারণ। start সার্ভিসটি এখনই চালায়, কিন্তু রিবুটের পর সেটি ওঠে না। enable target ডিরেক্টরিতে একটি সিম্বলিক লিংক তৈরি করে (যেমন /etc/systemd/system/multi-user.target.wants/), ফলে বুটের সময় সার্ভিস ওঠে, কিন্তু এখনই চলে না। সাধারণত দুটিই দরকার — enable --now ব্যবহার করুন।

তৃতীয় একটি অবস্থা আছে, mask। systemctl mask service unit-কে /dev/null-এর সঙ্গে যুক্ত করে, ফলে এটি হাতে বা নির্ভরতা হিসেবেও চালানো যায় না। সার্ভিসকে সম্পূর্ণ বন্ধ রাখতে হলে এটি কাজে আসে।

journalctl: সার্ভিসের লগ

সার্ভিস stdout ও stderr-এ যা লেখে, systemd-journald তা ধরে রাখে এবং সঙ্গে মেটাডেটা (unit-এর নাম, PID, অগ্রাধিকার, সময়) সহ একটি বাইনারি জার্নালে সংরক্ষণ করে। জার্নাল পড়া হয় journalctl দিয়ে।

journalctl -u nginx              # একটি সার্ভিসের লগ
journalctl -u nginx -f           # রিয়েল-টাইমে অনুসরণ, tail -f-এর মতো
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # শেষ ৫০ লাইন
journalctl -b                    # বর্তমান বুট থেকে
journalctl -b -1                 # আগের বুট
journalctl -p err -b             # শুধু ত্রুটি ও তার চেয়ে গুরুতর
journalctl -k                    # কার্নেলের বার্তা
journalctl --disk-usage          # জার্নাল কতটা জায়গা নিচ্ছে

-p অপশন syslog অগ্রাধিকার অনুযায়ী ফিল্টার করে: emerg, alert, crit, err, warning, notice, info, debug। উল্লিখিত স্তর তার চেয়ে গুরুতর সবকিছু অন্তর্ভুক্ত করে।

রিবুটের পরেও জার্নাল

যদি /var/log/journal ডিরেক্টরি না থাকে এবং /etc/systemd/journald.conf-এ Storage=auto থাকে, তাহলে জার্নাল শুধু মেমরিতে (/run/log/journal) থাকে এবং রিবুটে হারিয়ে যায়। স্থায়ী করতে Storage=persistent সেট করুন, অথবা ডিরেক্টরিটি তৈরি করে journald পুনরায় চালু করুন। আকার সীমিত করে SystemMaxUse=, আর পুরোনো ডেটা পরিষ্কার করা যায় journalctl --vacuum-time=2weeks বা --vacuum-size=500M দিয়ে।

journald প্রায়ই rsyslog-এর সঙ্গে কাজ করে: জার্নাল বার্তা rsyslog-কে পাঠায়, আর rsyslog /var/log/-এ ঐতিহ্যবাহী টেক্সট ফাইল লেখে এবং লগ কেন্দ্রীয় সার্ভারে পাঠাতে পারে।

নিজের সার্ভিস স্বয়ংক্রিয়ভাবে চালু: unit ফাইলের উদাহরণ

ধরুন আপনার এমন একটি অ্যাপ্লিকেশন আছে — স্ক্রিপ্ট বা বাইনারি — যেটি সচল রাখতে হবে, বুটে চালু করতে হবে এবং ক্র্যাশ করলে পুনরায় চালু করতে হবে। /etc/systemd/system/myapp.service ফাইল তৈরি করুন:

[Unit]
Description=My web application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

বিভাগগুলো এভাবে বুঝুন:

• [Unit] — বর্ণনা ও নির্ভরতা। After= শুধু ক্রম ঠিক করে, Wants= নরম নির্ভরতা (unit-টিকে টেনে আনে, কিন্তু সেটি না উঠলে ব্যর্থ হয় না)। কঠোর নির্ভরতা হলো Requires=।
• [Service] — কীভাবে চালাতে হবে। Type=simple মানে ExecStart-এর প্রসেসই সার্ভিস এবং সেটি পটভূমিতে যায় না। User= সাধারণ, অধিকারহীন ব্যবহারকারী হিসেবে চালায়। Restart=on-failure ত্রুটি নিয়ে বন্ধ হলে RestartSec সেকেন্ড পর পুনরায় চালু করে।
• [Install] — enable কী করে। WantedBy=multi-user.target মানে "সাধারণ বুটে চালাও"।

প্রয়োগ করা:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

unit ফাইলের সাধারণ ভুল

• ExecStart-এ আপেক্ষিক পাথ। প্রোগ্রামের পাথ অবশ্যই অ্যাবসোলিউট হতে হবে। systemd ব্যবহারকারীর PATH-এ শেলের মতো কমান্ড খোঁজে না।
• daemon-reload ভুলে যাওয়া। ফাইল বদলানোর পর systemd পুরোনো সংস্করণ ব্যবহার করে যাচ্ছে এবং status-এ সতর্কবার্তা দেয়।
• ডেমন পটভূমিতে চলে যায়। প্রোগ্রাম নিজে fork করলে অথচ Type=simple লেখা থাকলে systemd ধরে নেয় সার্ভিস শেষ হয়ে গেছে। প্রোগ্রামটিকে ফোরগ্রাউন্ড মোডে চালান, অথবা PIDFile=-সহ Type=forking ব্যবহার করুন।
• প্রোফাইলের এনভায়রনমেন্ট ভেরিয়েবল। সার্ভিস ~/.bashrc বা /etc/profile পড়ে না। ভেরিয়েবল দিতে হবে Environment= বা EnvironmentFile= দিয়ে।

প্যাকেজের unit না বদলে ওভাররাইড

প্যাকেজের সার্ভিসের প্যারামিটার বদলাতে তার ফাইলে হাত না দিয়ে drop-in ব্যবহার করুন:

sudo systemctl edit nginx

সম্পাদক খুলবে, এবং পরিবর্তন সংরক্ষিত হবে /etc/systemd/system/nginx.service.d/override.conf-এ। যেমন সেখানে [Service] বিভাগে Restart=always লেখা যায়। সম্পাদক বন্ধ করলে systemd নিজেই কনফিগারেশন পুনরায় পড়ে।

cron-এর বদলে systemd timer

Timer হলো এমন একটি unit, যা একই নামের সার্ভিস নির্দিষ্ট সময়ে চালায়। cron-এর চেয়ে এর সুবিধা: কাজের লগ জার্নালে থাকে, নির্ভরতা রাখা যায়, এবং ছুটে যাওয়া চালনা পূরণ করা যায় (Persistent=true)। দৈনিক ব্যাকআপের উদাহরণ:

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

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

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

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

OnCalendar অভিব্যক্তি যাচাই করতে systemd-analyze calendar "*-*-* 03:00:00" ব্যবহার করুন — এটি পরবর্তী চালনার সময় দেখাবে।

বুট ডায়াগনস্টিকস

systemd প্রতিটি unit-এর শুরুর সময় সংরক্ষণ করে, তাই ধীর বুট সহজে বিশ্লেষণ করা যায়:

systemd-analyze                  # মোট বুট সময়
systemd-analyze blame            # unit শুরুর সময় অনুযায়ী সাজানো
systemd-analyze critical-chain   # যে শৃঙ্খল বুট দেরি করছে
systemd-analyze verify /etc/systemd/system/myapp.service   # unit ফাইল যাচাই

সংক্ষেপে

systemd আধুনিক লিনাক্সের PID 1 ও সার্ভিস ম্যানেজার। এটি সবকিছু unit দিয়ে বর্ণনা করে, systemctl দিয়ে নিয়ন্ত্রিত হয়, লগ জার্নালে জমা করে যা journalctl দিয়ে পড়া হয়, এবং cron-এর বদলে timer দিয়ে কাজ চালাতে পারে। এটি কাজে লাগাতে status, enable --now, journalctl -u এবং Restart=on-failure-সহ সহজ unit ফাইল লেখার দক্ষতা যথেষ্ট। systemd, journald ও লগিং লিনাক্স কোর্সে হাতে-কলমে শেখানো হয়।