systemd क्या है, कैसे काम करता है और Linux सर्विस कैसे संभालें

systemd एक init सिस्टम और सर्विस मैनेजर है, जो ज़्यादातर आधुनिक Linux डिस्ट्रीब्यूशन में इस्तेमाल होता है: Debian, Ubuntu, Fedora, RHEL और उनके परिवार। बूट होने के बाद कर्नल systemd को PID 1 वाले पहले प्रोसेस के रूप में चलाता है, और फिर वही नेटवर्क चालू करता है, डिस्क माउंट करता है, वेब सर्वर, डेटाबेस और बाक़ी सब कुछ शुरू करता है। सरल शब्दों में, systemd एक «डिस्पैचर» है, जो जानता है कि कौन-सी सर्विस चलनी चाहिए, किस क्रम में शुरू होनी चाहिए और गिर जाए तो क्या करना है।

जाँचने का आसान तरीक़ा:

$ ps -p 1 -o comm=
systemd

systemd की ज़रूरत क्यों पड़ी

पहले Linux में 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 लगभग हर जगह मिलते हैं।

यूनिट: systemd किससे बना है

systemd जिन भी चीज़ों को संभालता है, वे सब यूनिट (units) से तय होती हैं। यूनिट INI फ़ॉर्मेट में लिखी टेक्स्ट फ़ाइल है, और उसका प्रकार एक्सटेंशन से पहचाना जाता है।

Unit फ़ाइलें कहाँ रहती हैं

यूनिट फ़ाइलें कई डायरेक्टरी में रहती हैं, और उनकी प्राथमिकता तय है:

• /usr/lib/systemd/system/ (Debian और Ubuntu में /lib/systemd/system/ भी) — पैकेज से इंस्टॉल यूनिट। इन्हें हाथ से न बदलें: पैकेज अपडेट होने पर बदलाव मिट जाएँगे।
• /etc/systemd/system/ — एडमिनिस्ट्रेटर की यूनिट और बदलाव। इनकी प्राथमिकता सबसे ऊँची है।
• /run/systemd/system/ — चलते समय बनी अस्थायी यूनिट।

किसी यूनिट की अंतिम सामग्री सारे बदलावों के साथ देखने के लिए systemctl cat nginx.service चलाएँ।

रनलेवल की जगह targets

पुराने runlevel की जगह targets आए हैं। 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 यूनिट को /dev/null से जोड़ देता है, और उसे न हाथ से चलाया जा सकता है, न किसी निर्भरता के रूप में। यह तब काम आता है, जब सर्विस को पक्के तौर पर बंद रखना हो।

journalctl: सर्विस के लॉग

सर्विस जो कुछ stdout और stderr पर लिखती है, उसे systemd-journald पकड़कर बाइनरी जर्नल में सेव करता है, साथ में यूनिट का नाम, PID, प्राथमिकता और समय जोड़कर। जर्नल पढ़ने के लिए journalctl है।

journalctl -u nginx              # एक सर्विस के लॉग
journalctl -u nginx -f           # रियल टाइम में देखना, जैसे tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # आख़िरी 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 को देता है, और वह क्लासिक टेक्स्ट फ़ाइलें /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= नरम निर्भरता है (यूनिट खींचो, पर वह न उठे तो भी न गिरो)। सख़्त निर्भरता 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 में इसकी चेतावनी दिखती है।
• डेमन पृष्ठभूमि में चला जाता है। अगर प्रोग्राम खुद फ़ोर्क करता है, पर Type=simple लिखा है, तो systemd समझता है कि सर्विस बंद हो गई। या तो प्रोग्राम को फ़ोरग्राउंड मोड में चलाएँ, या PIDFile= के साथ Type=forking लें।
• प्रोफ़ाइल के एनवायरनमेंट वेरिएबल। सर्विस ~/.bashrc या /etc/profile नहीं देखती। वेरिएबल Environment= या EnvironmentFile= से दें।

पैकेज की यूनिट बदले बिना बदलाव

पैकेज की सर्विस की सेटिंग बदलने के लिए उसकी फ़ाइल छुए बिना drop-in इस्तेमाल करें:

sudo systemctl edit nginx

एडिटर खुलेगा और बदलाव /etc/systemd/system/nginx.service.d/override.conf में सेव होंगे। उदाहरण के लिए वहाँ [Service] के नीचे Restart=always लिखा जा सकता है। एडिटर बंद करने पर systemd कॉन्फ़िग खुद दोबारा पढ़ लेता है।

cron की जगह systemd टाइमर

टाइमर एक यूनिट है, जो उसी नाम की सर्विस को शेड्यूल पर चलाता है। 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 हर यूनिट के शुरू होने का समय रखता है, इसलिए धीमे बूट का कारण आसानी से मिलता है:

systemd-analyze                  # कुल बूट समय
systemd-analyze blame            # यूनिट, शुरू होने के समय के हिसाब से
systemd-analyze critical-chain   # वह श्रृंखला, जिसने बूट को रोका
systemd-analyze verify /etc/systemd/system/myapp.service   # unit फ़ाइल की जाँच

निष्कर्ष

systemd आधुनिक Linux का PID 1 और सर्विस मैनेजर है। यह सब कुछ यूनिट से तय करता है, systemctl से संभाला जाता है, लॉग एक जर्नल में जमा करता है जिसे journalctl पढ़ता है, और cron की जगह टाइमर से काम शेड्यूल कर सकता है। इसे आत्मविश्वास से इस्तेमाल करने के लिए status, enable --now, journalctl -u समझना और Restart=on-failure वाली सरल unit फ़ाइल लिखना आना काफ़ी है। systemd, journald और लॉगिंग हमारे लिनक्स कोर्स में व्यवहार में सिखाए जाते हैं।