Systemd service start नहीं हो रही? इसे ठीक कैसे करें

Start न हो रही systemd service लगभग कभी रहस्यमयी नहीं होती। systemctl status <unit> चलाएँ, फिर उसी unit की आख़िरी 50 journal lines पढ़ें — journalctl -u <unit> -n 50 --no-pager — दोनों के बीच पाँच वजहों में से एक अक्सर साफ़-साफ़ नाम लेकर मिल जाती है: ग़लत path, ग़ायब binary, ग़लत permissions, SELinux/AppArmor की रोक, या unit file में syntax error। Failure की वजह log में है; नीचे दिए fixes उसके मुक़ाबले बस pattern matching हैं।

पता कैसे चलाएँ कि systemd service fail क्यों हुई?

पहले status, फिर journal:

systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager

status आपको हालत देता है (inactive (dead), failed (exit-code), activating (auto-restart)) और आख़िरी कुछ log lines। Journal पूरा क़िस्सा देता है: stdout, stderr, और unit के बारे में systemd की अपनी फ़रियादें।

अगर unit पहले भी फेल हो चुकी है और आपको उसी run का record चाहिए, तो इस boot के लिए -b या --since today जोड़ें:

journalctl -u myapp.service -b --no-pager

पूरा toolkit — boots, priorities, output को लाइव देखना — के लिए देखें journalctl cheat sheet। वही muscle memory है।

एक और जोड़ी जो काम आती है:

systemctl list-units --failed
systemctl reset-failed myapp.service

पहली बक्से की हर लाल unit की फ़ेहरिस्त है। दूसरी, fix हो जाने के बाद, failed हालत साफ़ कर देती है — दिखावटी काम है, पर status pages को बिना आग के धुआँ दिखाने से रोक देती है।

सबसे आम वजहें कौन सी हैं?

Log जब लक्षण नाम ले चुका हो, तो वजह लगभग हमेशा इन पाँच में से कोई एक होती है:

Log कहता है	संभावित वजह	इलाज
status=203/EXEC	ExecStart= का path ग़लत या interpreter मौजूद नहीं	Absolute path, chmod +x, shebang जाँचें
Script पर status=203/EXEC	Script में CRLF line endings या ख़राब shebang	dos2unix script.sh, पहली line ठीक करें
status=1/FAILURE, app का log नहीं	Working directory या env var ग़ायब	WorkingDirectory= सेट करें, Environment= जोड़ें
Permission denied	User फ़ाइलें पढ़ नहीं पा रहा या port बाँध नहीं पा रहा	Ownership ठीक करें; 1024 से नीचे ports के लिए AmbientCapabilities=CAP_NET_BIND_SERVICE या root
Unit is masked	किसी ने systemctl mask चलाया	systemctl unmask myapp.service
Unit file का बदलाव “असर ही नहीं”	Daemon reload नहीं हुआ	systemctl daemon-reload

203/EXEC वाले परिवार का अलग ज़िक्र ज़रूरी है, क्योंकि यही दोपहरें निगल जाता है। Systemd ExecStart= चलाने के लिए आपका shell इस्तेमाल नहीं करता। इसका मतलब:

# ग़लत — कोई shell नहीं, ~ कभी expand नहीं होता, PATH lookup नहीं
ExecStart=~/app/run.sh

# सही
ExecStart=/opt/app/run.sh

और script ख़ुद executable होनी चाहिए और असली shebang से शुरू होनी चाहिए (#!/bin/bash या #!/usr/bin/env bash)। Script आपके terminal में बख़ूब चलती हो पर systemd के नीचे 203 दे, तो वजह लगभग हमेशा इनमें से एक होती है: executable नहीं, CRLF endings, कहीं न पहुँचने वाला shebang, या relative path।

मैन्युअली चलती है पर boot पर नहीं — क्यों?

यह क्लासिक ordering bug है। अगर log boot के तुरंत बाद failures दिखाए पर आप हाथ से systemctl start करें तो unit ठीक उठ जाए, तो आपकी service race हार रही है — वह network, किसी mounted डिस्क या database तक पहुँच रही है जो अभी जन्मी ही नहीं है।

इलाज यह है कि उम्मीदों की जगह dependencies घोषित करें:

[Unit]
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
ExecStartPre=/usr/bin/test -f /opt/app/config.toml

After= start का क्रम तय करता है; Wants= systemd को dependency को सच में उठाने को कहता है। network-online.target तभी काम करता है जब आपके distro पर network-wait service enabled हो, इसलिए systemctl is-enabled NetworkManager-wait-online.service जाँचें (या systemd-networkd का बराबर)। ExecStartPre= वाली रोक सस्ता और ईमानदार तरीक़ा है stack trace की जगह पढ़ने लायक़ message के साथ चीख़ने का।

दूसरा रूप: boot पर service उठती है पर तुरंत मर जाती है। ढूँढ़ें वे चीज़ें जो आपके interactive environment में थीं पर boot में नहीं हैं — PATH का फ़र्क़, कोई virtualenv, कोई HOME। जो चाहिए, साफ़-साफ़ सेट करें:

[Service]
Environment="PATH=/opt/app/venv/bin:/usr/bin"
User=appuser
WorkingDirectory=/opt/app

मेरी service journal में log क्यों नहीं कर रही?

अगर journalctl -u कुछ न दिखाए, तो क्रम से तीन चीज़ें जाँचें:

1. Unit में StandardOutput= और StandardError= — वे journal (default) या journal+console होने चाहिए। किसी ने उन्हें null किया हो सकता है।
2. App stdout की जगह फ़ाइल में लिखता है। Systemd सिर्फ़ stdout/stderr पकड़ता है; log-file लिखने वाले journal को पूरी तरह bypass कर जाते हैं। या app को stdout पर मोड़ें, या फ़ाइल पढ़ें।
3. Storage की limits ने पुरानी lines उड़ा दीं: journalctl --disk-usage, और अगर journal घुट रहा हो तो /etc/systemd/journald.conf में SystemMaxUse=।

Start को ख़ुद debug करने में boot-time context के भीतर shell गिराने से बेहतर कुछ नहीं:

[Service]
ExecStart=/bin/bash -c 'exec /opt/app/bin/server 2>&1'

या सच में उलझे मामलों के लिए, ठीक वही ExecStart= कमांड unit के user की हैसियत से shell में चलाएँ — environment के ज़्यादातर फ़र्क़ पहले दस सेकंड में सामने आ जाते हैं।

Crash के बाद अपने आप restart कैसे करवाएँ?

Default policy है Restart=no: क्रैश हुई service मरी पड़ी रहती है, और ख़बर किसी user से मिलती है। हर service के लिए यह ठीक करें:

[Service]
Restart=on-failure
RestartSec=5

Setting	कब restart करता है
no (default)	कभी नहीं
on-failure	Non-zero exit, signal, timeout
always	हर exit पर, साफ़-सुथरा exit समेत
on-watchdog	सिर्फ़ watchdog timeout

Restart=on-failure को start-rate guard के साथ जोड़ें ताकि क्रैश का चक्कर बक्से को न कुटता रहे: [Unit] section में StartLimitIntervalSec= और StartLimitBurst=। साठ सेकंड में पाँच failures इंसान को पुकारने लायक़ होने चाहिए, CPU जलाने लायक़ नहीं।

अगर यह daemon नहीं बल्कि तय समय पर चलने वाली job के तौर पर जोड़ रहे हैं, तो पहले cron vs systemd timer तौल लें — timers journal logging और dependency ordering मुफ़्त में देते हैं, जो इस लेख में बार-बार ज़रूरत पड़ता है।

60 सेकंड की checklist

1. systemctl status <unit> — हालत और आख़िरी lines पढ़ें।
2. journalctl -u <unit> -n 50 --no-pager — असली error ढूँढ़ें।
3. 203/EXEC? Path, shebang, permissions ठीक करें। Permission denied? User और फ़ाइल ownership ठीक करें।
4. सिर्फ़ boot पर फेल? After=/Wants=network-online.target और एक ExecStartPre= रोक जोड़ें।
5. Unit file बदली? systemctl daemon-reload && systemctl restart <unit>।
6. Restart=on-failure जोड़ें, ताकि अगली crash छुपने की बजाय ख़ुद बताए।

“Systemd उलझा हुआ है” वाले ज़्यादातर पल एक बात पर उतरते हैं — ग़लती शुरू से journal में मौजूद थी। Unit file edit करने से पहले उसे पढ़ें, बाद में नहीं।