Linux VPS پر systemd service کیسے بنائیں

systemd service کیا ہے اور آپ کو اس کی ضرورت کیوں ہے

systemd service ایک چھوٹی ٹیکسٹ فائل ہے جو آپ کے سرور کو بتاتی ہے کہ کسی پروگرام کو کیسے چلانا ہے: اسے بوٹ پر شروع کرنا، کریش ہونے کی صورت میں دوبارہ چلانا، اور اس کی آؤٹ پٹ کو سسٹم لاگ میں بھیجنا۔ یہی اس کا کل کام ہے۔ SSH سیشن میں آپ کے ہاتھ سے شروع کیا گیا پروگرام آپ کے لاگ آؤٹ ہوتے ہی یا سرور کے ریبوٹ ہوتے ہی بند ہو جاتا ہے۔ systemd service میں لپٹا ہوا پروگرام چلتا رہتا ہے، کیونکہ اسے آپ کی شیل کے بجائے خود سرور کنٹرول کرتا ہے۔

systemd، Ubuntu، Debian، Fedora اور زیادہ تر جدید Linux سرورز پر init سسٹم ہے۔ یہ شروع ہونے والا پہلا عمل (process) ہے اور باقی سب چیزوں کی نگرانی کرتا ہے۔ یہ ہمیشہ سے ایسا نہیں تھا، اور کس طرح systemd نے ان init اسکرپٹس کی جگہ لی جو اس سے پہلے موجود تھیں اس بارے میں پڑھنا تب فائدہ مند ہے جب آپ جان لیں کہ unit فائل کیا کام کرتی ہے۔ جب آپ سروس فائل لکھتے ہیں تو آپ اپنے پروگرام کو اس نگران (supervisor) کے حوالے کر دیتے ہیں۔ یہ گائیڈ آپ کو سب سے چھوٹی کام کرنے والی unit، ہر unit کے تین حصے، اسے آن کرنے اور اس کے لاگز پڑھنے کا طریقہ، ٹائمر کے ساتھ شیڈول پر چلانے کا طریقہ، اور اسے محفوظ بنانے کا طریقہ دکھاتی ہے تاکہ یہ کم سے کم مراعات (privileges) کے ساتھ چل سکے۔

سب سے چھوٹی کام کرنے والی سروس

ایک سروس فائل /etc/systemd/system/ میں رہتی ہے، اس کا اختتام .service پر ہوتا ہے، اور اسے صرف چند لائنوں کی ضرورت ہوتی ہے۔ /usr/local/bin/myapp پر موجود پروگرام کے لیے ایک فائل بنائیں:

sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My application

[Service]
ExecStart=/usr/local/bin/myapp

[Install]
WantedBy=multi-user.target

یہ ایک مکمل اور فعال یونٹ ہے۔ ExecStart وہ کمانڈ ہے جسے چلانا ہے۔ WantedBy=multi-user.target کا مطلب ہے کہ سرور کے نارمل ملٹی یوزر آپریشن تک پہنچنے کے بعد اسے شروع کریں، یہی وہ چیز ہے جو اسے بوٹ کے وقت خودکار طور پر چلاتی ہے۔ باقی سب کچھ بہتری کے لیے ہے۔

تین سیکشنز، اور ہر ایک کا مقصد

ہر unit file مربع بریکٹ میں موجود سیکشنز میں تقسیم ہوتی ہے۔ ایک سروس تین سیکشنز استعمال کرتی ہے۔

[Unit] سروس اور اس کے تعلقات کو بیان کرتا ہے۔ وہ دو لائنیں جو آپ سب سے زیادہ استعمال کریں گے:

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

Description وہ انسانی لیبل ہے جو آپ systemctl status میں دیکھتے ہیں۔ After=network-online.target سسٹم کو بتاتا ہے کہ جب تک نیٹ ورک فعال نہ ہو آپ کا پروگرام شروع نہ کرے، جو ہر اس چیز کے لیے اہم ہے جو کسی پورٹ کو bind کرتی ہے یا آؤٹ باؤنڈ کنکشن بناتی ہے۔

[Service] یہ بتاتا ہے کہ پروگرام کیسے چلتا ہے۔ زیادہ تر ترتیبات یہیں رکھی جاتی ہیں:

[Service]
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.toml
WorkingDirectory=/opt/myapp
User=myapp
Restart=on-failure
RestartSec=5
Environment=LOG_LEVEL=info

User=myapp پروگرام کو root کے بجائے ایک غیر مراعات یافتہ اکاؤنٹ کے طور پر چلاتا ہے، جو حفاظت کے لیے سب سے اہم لائن ہے۔ یہاں کوئی Type= لائن نہیں ہے، لہذا systemd بائی ڈیفالٹ simple پر واپس آ جاتا ہے اور فرض کرتا ہے کہ ExecStart پروسیس foreground میں رہتا ہے؛ وہ پروگرام جو پس منظر میں fork ہوتا ہے اسے شروع ہونے کے درست Type= کی ضرورت ہوتی ہے، ورنہ یونٹ active رپورٹ کرے گا جبکہ اصل daemon پہلے ہی ختم ہو چکا ہوگا۔ Restart=on-failure اور RestartSec=5 کا اپنا الگ سیکشن نیچے دیا گیا ہے، کیونکہ یہی وہ وجہ ہے جس کے لیے زیادہ تر لوگ سروس لکھتے ہیں۔

[Install] وہ ہے جو سروس کو enable کرنے پر ہوتا ہے:

[Install]
WantedBy=multi-user.target

WantedBy=multi-user.target وہ ہے جو سروس کو بوٹ کے ساتھ لنک کرتا ہے جب آپ systemctl enable چلاتے ہیں۔ [Install] سیکشن کے بغیر، سروس کو دستی طور پر تو شروع کیا جا سکتا ہے لیکن ریبوٹ کے بعد یہ خود بخود شروع نہیں ہوگی۔

اسے آن کریں اور مانیٹر کریں

کسی بھی unit file کو لکھنے یا ایڈٹ کرنے کے بعد، systemd کو reload کریں تاکہ وہ تبدیلیوں کو پڑھ سکے، پھر سروس کو ایک ہی مرحلے میں enable اور start کریں:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

daemon-reload وہ مرحلہ ہے جسے لوگ بھول جاتے ہیں: systemd unit files کو cache کر لیتا ہے، اس لیے reload کیے بغیر آپ کی ایڈیٹنگ کا کوئی اثر نہیں ہوتا۔ enable --now سروس کو بوٹ کے لیے enable بھی کرتا ہے اور فوراً start بھی کر دیتا ہے۔ اسے چیک کریں:

sudo systemctl status myapp.service

* myapp.service - My application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
     Active: active (running) since Wed 2026-07-15 22:40:11 UTC; 3s ago
   Main PID: 4123 (myapp)

Active: active (running) اور enabled وہی ہیں جو آپ کو درکار ہیں۔ پروگرام کا آؤٹ پٹ پڑھنے کے لیے، journal سے صرف اس یونٹ کے بارے میں پوچھیں:

sudo journalctl -u myapp.service -f

-f نئی لائنز کو اسی طرح فالو کرتا ہے جیسے وہ موصول ہوتی ہیں، بالکل tail -f کی طرح۔ آپ کا پروگرام جو کچھ بھی standard output یا standard error پر لکھتا ہے وہ یہاں پہنچ جاتا ہے، اس کے لیے آپ کو کوئی logging سیٹ اپ کرنے کی ضرورت نہیں ہوتی۔

ناکام ہونے پر دوبارہ اسٹارٹ کرنا، یہی وہ وجہ ہے جس کے لیے آپ یہاں ہیں

سروس کا سب سے بڑا فائدہ یہ ہے کہ جب آپ کا پروگرام بند ہو جائے تو systemd اسے خود بخود دوبارہ اسٹارٹ کر دیتا ہے۔ دو لائنیں یہ کام کرتی ہیں:

[Service]
Restart=on-failure
RestartSec=5

Restart=on-failure پروگرام کو تب دوبارہ اسٹارٹ کرتا ہے جب وہ non-zero کوڈ کے ساتھ ایگزٹ ہو یا SIGKILL یا SIGSEGV جیسے کریش سگنل کی وجہ سے بند ہو جائے۔ ایک کلین ایگزٹ، یا SIGTERM، SIGINT، SIGHUP، یا SIGPIPE کے ذریعے رکنا اسے ٹرگر نہیں کرتا۔ RestartSec=5 کوششوں کے درمیان پانچ سیکنڈ کا انتظار کرتا ہے، تاکہ جو پروگرام فوری کریش ہو جائے وہ ایک تیز لوپ میں نہ پھنس جائے۔ پروسیس کو kill کر کے اور systemd کو اسے واپس لاتے ہوئے دیکھ کر اس کی تصدیق کریں۔ SIGKILL کا استعمال کریں: ڈیفالٹ SIGTERM ایک کلین اسٹاپ شمار ہوتا ہے، اس لیے on-failure سروس کو دوبارہ اسٹارٹ نہیں کرے گا:

sudo systemctl kill -s SIGKILL myapp.service
sudo systemctl status myapp.service

پانچ سیکنڈ کے اندر اسٹیٹس ایک نیا Main PID اور دوبارہ active (running) دکھاتا ہے۔ یہ مکمل فیچر ہے، اور یہی وجہ ہے کہ سروس کو tmux یا screen میں پروگرام چلتا چھوڑنے پر فوقیت حاصل ہے۔

اسے ایک غیر مراعات یافتہ صارف کے طور پر چلائیں اور اسے محفوظ بنائیں

اگر کوئی پروگرام کبھی ہیک ہو جائے تو root کے طور پر چلنے والی سروس آپ کے سرور کے ساتھ کچھ بھی کر سکتی ہے۔ اسے اس کے اپنے صارف کے طور پر چلائیں، اور systemd کو چند ایسی ہدایات دیں جو اسے محدود کر دیں۔ سب سے پہلے بغیر لاگ ان اور بغیر ہوم ڈائریکٹری کے ایک سسٹم اکاؤنٹ بنائیں:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp

پھر User=myapp سیٹ کریں اور [Service] میں ہارڈننگ کی لائنیں شامل کریں:

[Service]
User=myapp
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true

ہر لائن ایسی چیز کو ہٹا دیتی ہے جس کی پروگرام کو ضرورت نہیں ہے۔ NoNewPrivileges=true پروسیس کو کبھی بھی نئی مراعات حاصل کرنے سے روکتا ہے، یہاں تک کہ setuid بائنری کے ذریعے بھی۔ PrivateTmp=true اسے ایک نجی /tmp دیتا ہے جسے کوئی دوسرا پروسیس نہیں دیکھ سکتا۔ ProtectSystem=strict پوری فائل سسٹم کو صرف پڑھنے کے قابل (read-only) بنا دیتا ہے، سوائے ان چند راستوں کے جنہیں آپ ReadWritePaths= کے ساتھ نامزد کرتے ہیں۔ ProtectHome=true اس سے /home کو مکمل طور پر چھپا دیتا ہے۔ یہ کم سے کم مراعات (least-privilege) والی وہی سوچ ہے جو کسی سروس کو فائر وال کے پیچھے رکھنے میں استعمال ہوتی ہے: اسے صرف وہی دیں جس کی اسے ضرورت ہے۔ اگر آپ نے VPS پر IPv6 فائر وال کے خلا کو بند کرنے کے بارے میں گائیڈ پڑھی ہے، تو یہ اسی تصور کا آن-ہوسٹ حصہ ہے۔ انٹرنیٹ کا سامنا کرنے والی سروس کے لیے، اس ہارڈننگ کو SSH کے سامنے Fail2ban اور ڈیفالٹ ڈینائی فائر وال کے ساتھ جوڑیں۔

اس سب کو ہاتھ سے ٹائپ کرنے اور کسی ہدایت کو بھول جانے کے بجائے، ایک مکمل، ہارڈنڈ یونٹ تیار کریں اور اسے کاپی کر لیں:

Timers: جدید cron کا متبادل

ایک systemd timer کسی سروس کو ایک طے شدہ شیڈول پر چلاتا ہے، اور یہ cron job کا جدید متبادل ہے۔ ایک ٹائمر دو فائلوں پر مشتمل ہوتا ہے: ایک .service جو کام انجام دیتی ہے، اور ایک .timer جو وقت کا تعین کرتی ہے۔ فرض کریں کہ آپ روزانہ صبح 3 بجے بیک اپ لینا چاہتے ہیں۔ سروس کام کو ایک بار انجام دیتی ہے اور بند ہو جاتی ہے:

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

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

Type=oneshot systemd کو بتاتا ہے کہ پروگرام چلتا ہے، مکمل ہوتا ہے، اور ختم ہو جاتا ہے، بجائے اس کے کہ وہ مستقل طور پر چلتا رہے۔ ٹائمر اسے شیڈول کرتا ہے:

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

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

[Install]
WantedBy=timers.target

OnCalendar=*-*-* 03:00:00 کا مطلب ہے روزانہ صبح 3 بجے۔ کسی بھی کیلنڈر ایکسپریشن کو systemd-analyze calendar "*-*-* 03:00:00" کے ساتھ ٹیسٹ کریں، جو اس بات کی تصدیق کرتا ہے کہ آیا وہ درست ہے اور یہ بتاتا ہے کہ اگلی بار یہ کب چلے گا۔ Persistent=true کسی چھوٹ جانے والی جاب کو سرور کے آن ہوتے ہی فوراً چلا دیتا ہے اگر سرور صبح 3 بجے بند تھا، جو کہ cron نہیں کر سکتا۔ یاد رکھیں کہ ٹائمر کو timers.target کے ذریعے فعال کیا جاتا ہے، نہ کہ multi-user.target کے ذریعے۔ سروس کو نہیں، بلکہ ٹائمر کو فعال کریں:

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

list-timers ہر ٹائمر کو اس کے اگلے اور پچھلے رن کے ساتھ دکھاتا ہے، تاکہ آپ ایک نظر میں دیکھ سکیں کہ آپ کی جاب اگلی بار کب چلے گی۔ جب آپ ٹائمر موڈ آن کرتے ہیں تو اوپر دیا گیا جنریٹر آپ کے لیے جوڑی میں .service اور .timer بناتا ہے۔ cron لائن کے مقابلے میں، ٹائمر آپ کو journal میں حقیقی لاگز، کسی بھی سروس کی طرح سخت سیکیورٹی ڈائریکٹوز، اور چھوٹ جانے والی جاب کو دوبارہ چلانے کی سہولت دیتا ہے جو Persistent=true فراہم کرتا ہے۔ سادہ کاموں کے لیے cron اب بھی ٹھیک ہے؛ لیکن جب کام اہم ہو تو ٹائمر ایک بہتر ٹول ہے۔

FAQ

systemd service اور cron job میں کیا فرق ہے؟

ایک service طویل عرصے تک چلنے والے پروگرام کو زندہ رکھتی ہے: یہ بوٹ پر شروع ہوتی ہے، ناکامی کی صورت میں دوبارہ اسٹارٹ ہوتی ہے، اور journal میں لاگز لکھتی ہے۔ ایک cron job ایک مختصر کمانڈ کو شیڈول کے مطابق چلاتی ہے اور پھر ختم ہو جاتی ہے۔ جب آپ کو شیڈولنگ کے ساتھ ساتھ journal لاگز، ہارڈننگ، اور چھوٹ جانے والے کاموں کو پورا کرنے کی ضرورت ہو، تو systemd timer استعمال کریں، جو ایک .timer شیڈول کو ایک oneshot سروس کے ساتھ جوڑتا ہے اور زیادہ تر سرور ٹاسکس کے لیے cron کی جگہ لے لیتا ہے۔

میں اپنی systemd service فائل کہاں رکھوں؟

اپنی یونٹس کو /etc/systemd/system/ میں رکھیں، جس کا نام .service پر ختم ہو۔ یہ ڈائریکٹری ان یونٹس کے لیے ہے جو ایڈمنسٹریٹر شامل کرتا ہے، اور اسے /lib/systemd/system/ میں پیکجز کے ذریعے فراہم کردہ یونٹس پر فوقیت حاصل ہے۔ وہاں فائل بنانے یا ترمیم کرنے کے بعد، sudo systemctl daemon-reload چلائیں تاکہ systemd تبدیلیوں کو لاگو کر سکے۔

اگر سروس کریش ہو جائے تو میں اسے دوبارہ اسٹارٹ کیسے کروں؟

[Service] سیکشن میں Restart=on-failure اور RestartSec=5 شامل کریں، پھر sudo systemctl daemon-reload چلائیں اور سروس کو دوبارہ اسٹارٹ کریں۔ جب پروگرام نان-زیرو کوڈ کے ساتھ ختم ہوتا ہے یا کریش سگنل کی وجہ سے بند ہوتا ہے تو systemd اسے دوبارہ لانچ کرتا ہے، اور کوششوں کے درمیان 5 سیکنڈ کا وقفہ لیتا ہے۔ اسے sudo systemctl kill -s SIGKILL myapp.service کے ساتھ ٹیسٹ کریں، SIGTERM، جو کہ ڈیفالٹ سگنل ہے، ایک کلین اسٹاپ کے طور پر شمار ہوتا ہے اور on-failure کو متحرک نہیں کرتا، اور دیکھیں کہ systemctl status چند سیکنڈ کے اندر ایک نیا PID دکھاتا ہے۔

میں systemd service کو نان-root صارف کے طور پر کیسے چلاؤں؟

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp کے ساتھ ایک سسٹم اکاؤنٹ بنائیں، پھر [Service] سیکشن میں User=myapp شامل کریں۔ NoNewPrivileges=true، PrivateTmp=true، اور ProtectSystem=strict شامل کریں تاکہ پروسیس کو صرف اتنی ہی رسائی ملے جتنی اسے درکار ہے۔ ایک غیر مراعات یافتہ (unprivileged) صارف کے طور پر چلانا سب سے اہم تبدیلی ہے جو آپ سروس کی حفاظت کے لیے کر سکتے ہیں۔

میری سروس شروع ہونے میں ناکام کیوں ہوئی؟

خلاصے کے لیے systemctl status myapp.service اور مکمل آؤٹ پٹ کے لیے journalctl -u myapp.service چلائیں۔ سب سے عام وجوہات میں ExecStart میں غلط پاتھ، کسی WorkingDirectory کا غائب ہونا، اجازت (permission) کی غلطی کیونکہ User= فائل کو پڑھ نہیں سکتا، یا ترمیم کے بعد sudo systemctl daemon-reload کا بھول جانا شامل ہیں۔ جرنل پروگرام کا اپنا ایرر میسج دکھاتا ہے، جو عام طور پر مسئلے کی براہ راست نشاندہی کرتا ہے۔