systemd: অ্যাপ service হিসেবে চালান, timer-এ schedule করুন

systemd আপনার অ্যাপ চালু রাখে, ব্যর্থ হলে আবার চালায় এবং কাজ schedule করে। ন্যূনতম service ফাইল, timer ও প্রতিদিনের কমান্ড শিখুন।

পুনরায় চালুর তীর ও ঘড়িসহ একটি service বাক্স

systemd বেশিরভাগ আধুনিক Linux distribution-এর init system। এটি boot-এ service চালু করে, crash হলে আবার চালায়, তাদের log জমায় এবং schedule করা কাজ চালায়। ছোট server-এ নিজের অ্যাপ নির্ভরযোগ্যভাবে চালানোর সবচেয়ে সহজ উপায় এটি।

ন্যূনতম service

/etc/systemd/system/myapp.service বানান:

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

[Service]
User=deploy
WorkingDirectory=/srv/myapp
EnvironmentFile=/etc/myapp.env
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

লাইনগুলো কী করে:

  • After=: network চালু হওয়ার পরে শুরু করা।
  • User=: সাধারণ user হিসেবে চালান, root নয়।
  • EnvironmentFile=: unit-এ না রেখে ফাইল থেকে সেটিংস ও secret লোড করা (ফাইল chmod 600 রাখুন)।
  • ExecStart=: চালানোর কমান্ড, পূর্ণ path সহ।
  • Restart=on-failure: crash হলে আবার চালু।
  • WantedBy=multi-user.target: enable করলে স্বাভাবিক boot-এ চালু।

যে কমান্ড প্রতিদিন লাগবে

sudo systemctl daemon-reload        # unit ফাইল বদলের পর
sudo systemctl enable --now myapp   # এখনই এবং প্রতিবার boot-এ চালু
sudo systemctl status myapp         # অবস্থা ও শেষ কয়েক লাইন log
sudo systemctl restart myapp
sudo systemctl stop myapp
sudo systemctl disable myapp

journalctl দিয়ে log

আপনার অ্যাপ যা print করে systemd তা জমায়।

journalctl -u myapp                 # service-এর সব log
journalctl -u myapp -f              # সরাসরি অনুসরণ
journalctl -u myapp --since "1 hour ago"
journalctl -u myapp -p err          # শুধু error

Hardening বিকল্প (ঐচ্ছিক কিন্তু কাজের)

[Service]-এর ভেতরে অ্যাপ কী করতে পারবে তা সীমিত করা যায়, যেমন:

  • NoNewPrivileges=true
  • PrivateTmp=true
  • ProtectSystem=full
  • ProtectHome=true

একটি একটি করে যোগ করে পরীক্ষা করুন, কারণ কড়া সেটিং বৈধ অ্যাপও থামিয়ে দিতে পারে।

Timer: cron-এর আধুনিক বিকল্প

Timer schedule অনুযায়ী একটি service চালায়। একই নামে দুটি ফাইল লাগে: .service (কী চলবে) ও .timer (কখন)।

/etc/systemd/system/backup.service

[Unit]
Description=Daily backup

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

/etc/systemd/system/backup.timer

[Unit]
Description=Run the backup every day

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

[Install]
WantedBy=timers.target
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

কাজের বিকল্প:

  • OnCalendar=: ক্যালেন্ডারের সময় (প্রতিদিন, প্রতি সপ্তাহ, বা নির্দিষ্ট সময়)।
  • OnUnitActiveSec=15min: শেষ চালানোর ১৫ মিনিট পর পুনরাবৃত্তি।
  • Persistent=true: নির্ধারিত সময়ে মেশিন বন্ধ থাকলে ফিরে এলে চালানো।
  • RandomizedDelaySec=: load ছড়ানো।

Cron-এর তুলনায় timer journal-এ log, dependency সামলানো এবং সহজ status যাচাই দেয়।

সাধারণ ভুল

  • বদলের পর daemon-reload ভুলে যাওয়া।
  • ExecStart-এ আপেক্ষিক path (পূর্ণ path ব্যবহার করুন)।
  • দরকার না থাকলেও root হিসেবে চলা service।
  • Unit ফাইলে সরাসরি secret রাখা, যা অনেক user পড়তে পারে।

মূল কথা: একটি ছোট unit ফাইল auto-start, auto-restart ও পরিষ্কার log দেয়। Schedule করা কাজে timer ব্যবহার করুন, service সাধারণ user হিসেবে চালান, আর secret তালাবদ্ধ environment ফাইলে রাখুন।


Linux ও DevOps সিরিজ, পর্ব ১ (server ও container): 2 নম্বর (মোট 5)। আগের লেখা: Linux file permission সহজ ভাষায়: chmod, chown ও umask.

আরও পড়ুন

Recursion ও backtracking সহজ উদাহরণে

Recursion সমস্যার ছোট কপি সমাধান করে সমাধান করে। অনেক interview সমস্যায় ব্যবহৃত চিন্তার ধাপ ও backtracking টেমপ্লেট শিখুন।

Interview ও DSA•৩ মিনিটে পড়া