Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत · पाठ

systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना

systemctl से सेवाएँ चलाएँ और स्क्रिप्ट किए गए डेमॉन के लिए कस्टम यूनिट और टाइमर फ़ाइलें लिखें।

पाठ 2, कुल 4 में से13 चरण

systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना, CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

systemd और systemctl का परिचय

systemd अधिकांश आधुनिक Linux वितरणों में उपयोग की जाने वाली प्रारंभिक प्रणाली और सेवा प्रबंधक है। यह सिस्टम सेवाओं को शुरू करने, रोकने और प्रबंधित करने के साथ-साथ बूट क्रम और सिस्टम स्थिति को संभालने के लिए ज़िम्मेदार है।

systemd के साथ काम करने का मुख्य उपकरण systemctl है। इसके माध्यम से आप:

सेवाएँ शुरू और रोक सकते हैं
बूट के समय सेवाओं को सक्षम या अक्षम कर सकते हैं
सेवा की स्थिति और लॉग देख सकते हैं
पुनः आरंभ किए बिना कॉन्फ़िगरेशन फिर से लोड कर सकते हैं

systemd द्वारा प्रबंधित सभी सेवाएँ यूनिट फ़ाइलों में परिभाषित होती हैं। ये घोषणात्मक कॉन्फ़िगरेशन फ़ाइलें /etc/systemd/system/ (पूरे सिस्टम के लिए) या ~/.config/systemd/user/ (प्रत्येक उपयोगकर्ता के लिए) में संग्रहीत रहती हैं।

आवश्यक systemctl कमांड

दैनिक सेवा प्रबंधन के लिए सबसे अधिक उपयोग किए जाने वाले systemctl कमांड ये हैं। प्रत्येक कमांड nginx.service या केवल nginx जैसे इकाई नाम पर काम करता है।

systemctl start <unit> — किसी सेवा को तुरंत शुरू करें
systemctl stop <unit> — चल रही सेवा को रोकें
systemctl restart <unit> — पहले रोकें, फिर शुरू करें (पूर्ण पुनःआरंभ)
systemctl reload <unit> — सेवा रोके बिना कॉन्फ़िगरेशन फिर से लोड करने के लिए SIGHUP भेजें
systemctl enable <unit> — बूट के समय इकाई शुरू करने के लिए प्रतीकात्मक लिंक बनाएँ
systemctl disable <unit> — वे प्रतीकात्मक लिंक हटाएँ
systemctl status <unit> — स्थिति, PID और हाल की लॉग पंक्तियाँ दिखाएँ

#!/usr/bin/env bash
# Quick reference: inspect and control an nginx service
# (Requires nginx to be installed; run as root or with sudo)

systemctl status nginx
systemctl start nginx
systemctl enable nginx
systemctl reload nginx
systemctl restart nginx
systemctl stop nginx
systemctl disable nginx

सेवा की स्थिति का विस्तृत निरीक्षण

systemctl status किसी इकाई की विस्तृत स्थिति दिखाता है। समस्याओं का तेज़ी से निदान करने के लिए इसके आउटपुट को समझना आवश्यक है।

Loaded: इकाई फ़ाइल का पथ और यह जानकारी कि वह बूट के समय सक्षम है या नहीं
Active: वर्तमान स्थिति — active (running), inactive (dead), failed
Main PID: सेवा की मुख्य प्रक्रिया का प्रक्रिया पहचानकर्ता
CGroup: सेवा से संबंधित सभी बाल प्रक्रियाएँ
Log lines: इस इकाई की जर्नल में दर्ज सबसे हाल की प्रविष्टियाँ

आप केवल सक्रिय स्थिति के लिए systemctl is-active और सक्षम स्थिति के लिए systemctl is-enabled भी चला सकते हैं। ये स्क्रिप्ट में उपयोग के लिए विशेष रूप से उपयुक्त हैं।

#!/usr/bin/env bash
# Script-friendly service health check
SERVICE="sshd"

if systemctl is-active --quiet "$SERVICE"; then
    echo "$SERVICE is running."
else
    echo "$SERVICE is NOT running. Attempting restart..."
    systemctl restart "$SERVICE"
fi

if systemctl is-enabled --quiet "$SERVICE"; then
    echo "$SERVICE is enabled at boot."
else
    echo "WARNING: $SERVICE is not enabled at boot."
fi

इकाइयों की सूची बनाना और फ़िल्टर करना

कई सेवाओं का प्रबंधन करते समय इकाइयों की सूची बनाने और उन्हें कुशलतापूर्वक फ़िल्टर करने के तरीकों की आवश्यकता होती है। systemctl list-units वर्तमान में लोड की गई सभी इकाइयाँ दिखाता है, जबकि list-unit-files सभी स्थापित इकाई फ़ाइलों और उनकी सक्षम स्थिति को दिखाता है।

उपयोगी फ़िल्टर विकल्प:

--type=service — केवल सेवा इकाइयाँ दिखाएँ
--state=failed — केवल विफल इकाइयाँ दिखाएँ
--state=active — केवल सक्रिय इकाइयाँ दिखाएँ
--all — सूची में निष्क्रिय इकाइयों को भी शामिल करें

इन फ़िल्टरों को grep के साथ मिलाकर आप रखरखाव स्क्रिप्ट में शक्तिशाली निरीक्षण पाइपलाइन बना सकते हैं।

#!/usr/bin/env bash
# List all failed services and report them
echo "=== Failed Services ==="
systemctl list-units --type=service --state=failed --no-legend

echo ""
echo "=== Services Enabled at Boot ==="
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'

systemd सेवा इकाई फ़ाइल की संरचना

सेवा इकाई फ़ाइल अनुभागों से बनी एक सादा-पाठ INI-शैली की फ़ाइल होती है। प्रत्येक अनुभाग इकाई के जीवनचक्र के अलग पहलू को नियंत्रित करता है।

[Unit] — मेटाडेटा: विवरण और क्रम-संबंधी निर्भरताएँ (After=, Requires=, Wants=)
[Service] — प्रक्रिया को शुरू और रोकने का तरीका: ExecStart, ExecStop, Restart, User, WorkingDirectory
[Install] — यह इकाई कब सक्षम की जानी चाहिए: WantedBy=multi-user.target का अर्थ है कि यह सामान्य बहु-उपयोगकर्ता बूट के दौरान सक्रिय होगी

/etc/systemd/system/ के अंतर्गत इकाई फ़ाइल रखने या उसमें बदलाव करने के बाद, आपको systemctl daemon-reload चलाना होगा ताकि systemd इन बदलावों को अपना सके।

अपनी पहली सेवा इकाई फ़ाइल लिखना

आइए, एक कस्टम Python HTTP सर्वर स्क्रिप्ट के लिए सरल सेवा इकाई फ़ाइल बनाएँ। यह इकाई फ़ाइल systemd को बताती है कि इस प्रक्रिया का प्रबंधन किसी अन्य सिस्टम सेवा की तरह ठीक-ठीक कैसे करना है।

यहाँ उपयोग किए गए [Service] के मुख्य निर्देश:

Type=simple — systemd ExecStart प्रक्रिया को मुख्य प्रक्रिया मानता है
User=www-data — सुरक्षा के लिए रूट के बजाय गैर-रूट खाते के अंतर्गत चलाएँ
WorkingDirectory — प्रक्रिया की कार्यशील निर्देशिका निर्धारित करें
Restart=on-failure — प्रक्रिया के शून्येतर कोड के साथ समाप्त होने पर अपने-आप फिर शुरू करें
RestartSec=5 — पुनःआरंभ के प्रयासों के बीच 5 सेकंड प्रतीक्षा करें

#!/usr/bin/env bash
# Create a custom service unit file for a simple HTTP server
# Run as root

cat > /etc/systemd/system/mywebserver.service << 'EOF'
[Unit]
Description=My Custom Python Web Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mywebserver.service
systemctl status mywebserver.service

सेवा के प्रकार और प्रक्रिया का जीवनचक्र

[Service] में दिया गया Type= निर्देश systemd को बताता है कि सेवा का शुरू होना पूरा हुआ या नहीं, यह कैसे निर्धारित करना है। गलत प्रकार चुनना क्रम-संबंधी त्रुटियों का सामान्य कारण है।

Type=simple — डिफ़ॉल्ट; ExecStart शुरू होते ही systemd सेवा को शुरू हुई मानता है। तैयार होने का कोई संकेत आवश्यक नहीं।
Type=forking — ExecStart प्रक्रिया नई प्रक्रिया बनाकर समाप्त हो जाती है; वास्तविक डेमॉन बाल प्रक्रिया के रूप में चलता है। इसे ट्रैक करने के लिए PIDFile= का उपयोग करें।
Type=notify — प्रक्रिया वास्तव में तैयार होने पर sd_notify(READY=1) भेजती है। जटिल डेमॉन के लिए सबसे विश्वसनीय।
Type=oneshot — एक बार चलता है और समाप्त हो जाता है; बाद की इकाइयाँ इसके पूरा होने तक प्रतीक्षा करती हैं। सेटअप स्क्रिप्ट के लिए आदर्श।
Type=idle — simple जैसा, लेकिन सभी सक्रिय कार्य पूरे होने तक निष्पादन में विलंब होता है।

#!/usr/bin/env bash
# Example: oneshot service for a database migration script
# /etc/systemd/system/db-migrate.service

cat > /etc/systemd/system/db-migrate.service << 'EOF'
[Unit]
Description=Run Database Migrations
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/scripts/migrate.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start db-migrate.service

पर्यावरण चर और सुरक्षा सुदृढ़ीकरण

सेवा इकाई फ़ाइलें पर्यावरण चर पास करने और सुरक्षा प्रतिबंध लागू करने के लिए कई निर्देशों का समर्थन करती हैं — उत्पादन प्रणालियों में दोनों महत्वपूर्ण हैं।

पर्यावरण संबंधी निर्देश:

Environment="KEY=value" — एकल चर को उसी पंक्ति में निर्धारित करें
EnvironmentFile=/etc/myapp/env — किसी फ़ाइल से चर लोड करें (प्रत्येक पंक्ति में एक KEY=value)

सामान्य सुरक्षा सुदृढ़ीकरण निर्देश:

NoNewPrivileges=true — setuid के माध्यम से प्रक्रिया को अतिरिक्त विशेषाधिकार प्राप्त करने से रोकें
ProtectSystem=strict — /usr, /boot, /etc को केवल-पठन के रूप में माउंट करें
PrivateTmp=true — सेवा को अपना अलग /tmp दें
CapabilityBoundingSet= — सभी Linux क्षमताएँ हटा दें

#!/usr/bin/env bash
# Hardened service unit with environment file

cat > /etc/systemd/system/secureapp.service << 'EOF'
[Unit]
Description=Secure Application Daemon
After=network.target

[Service]
Type=simple
User=secureapp
Group=secureapp
WorkingDirectory=/opt/secureapp
EnvironmentFile=/etc/secureapp/env
ExecStart=/opt/secureapp/bin/server
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
CapabilityBoundingSet=
ReadWritePaths=/var/lib/secureapp /var/log/secureapp

[Install]
WantedBy=multi-user.target
EOF

# Create the environment file separately so secrets stay out of the unit file
install -m 600 -o secureapp /dev/null /etc/secureapp/env
echo 'APP_PORT=9000' >> /etc/secureapp/env
echo 'DB_URL=postgresql://localhost/mydb' >> /etc/secureapp/env

systemctl daemon-reload

systemd टाइमर इकाइयों का परिचय

systemd टाइमर ऐसी इकाई है जो निर्धारित समय-सारणी के अनुसार किसी अन्य इकाई (आमतौर पर .service) को सक्रिय करती है। यह पारंपरिक cron कार्यों की जगह अधिक एकीकृत, लॉग दर्ज करने योग्य और नियंत्रित तंत्र प्रदान करता है।

प्रत्येक टाइमर इकाई (foo.timer) का समान मूल नाम वाली सेवा इकाई (foo.service) के साथ युग्म होता है, जो वास्तविक कार्य करती है। आप सेवा को सीधे नहीं, बल्कि टाइमर को सक्षम और शुरू करते हैं।

टाइमर के प्रकार:

वास्तविक-समय (कैलेंडर) टाइमर — OnCalendar= अभिव्यक्तियों का उपयोग करके घड़ी के समय पर सक्रिय होते हैं, जैसे daily, weekly या Mon *-*-* 02:00:00
एकरूपी टाइमर — OnBootSec=, OnActiveSec= या OnUnitActiveSec= का उपयोग करके सिस्टम की किसी घटना के सापेक्ष सक्रिय होते हैं

टाइमर इकाई फ़ाइल लिखना

आइए, ऐसा पूर्ण टाइमर और सेवा युग्म बनाएँ जो प्रतिदिन 02:00 बजे बैकअप स्क्रिप्ट चलाए। ध्यान दें कि [Timer] अनुभाग अपनी अलग .timer फ़ाइल में रहता है, जबकि कार्य संबद्ध .service फ़ाइल में रहता है।

[Timer] के मुख्य निर्देश:

OnCalendar= — समय-सारणी के लिए कैलेंडर अभिव्यक्ति
Persistent=true — यदि टाइमर के सक्रिय होने के समय सिस्टम बंद था, तो अगले बूट पर तुरंत चलाएँ
RandomizedDelaySec= — कई होस्ट द्वारा समान समय-सारणी साझा करने पर एक साथ अत्यधिक भार से बचने के लिए अधिकतम N सेकंड का यादृच्छिक विलंब जोड़ें
Unit= — स्पष्ट लक्ष्य इकाई (यदि नाम समान हों तो वैकल्पिक)

#!/usr/bin/env bash
# Create a daily backup timer pair
# Run as root

# 1. The service that does the work
cat > /etc/systemd/system/daily-backup.service << 'EOF'
[Unit]
Description=Daily Database Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup-db.sh
StandardOutput=journal
StandardError=journal
EOF

# 2. The timer that schedules it
cat > /etc/systemd/system/daily-backup.timer << 'EOF'
[Unit]
Description=Run Daily Database Backup at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now daily-backup.timer

# Verify
systemctl list-timers daily-backup.timer

लॉग का निरीक्षण और इकाइयों की समस्या-समाधान प्रक्रिया

systemd सभी सेवा आउटपुट को जर्नल में भेजता है, जिसे आप journalctl से देखते हैं। यह सभी इकाइयों के लॉग को एक खोज योग्य संग्रह में केंद्रीकृत करता है।

सेवा की समस्या-समाधान के लिए आवश्यक journalctl फ़्लैग:

-u <unit> — इकाई नाम के आधार पर फ़िल्टर करें
-f — लॉग को वास्तविक समय में देखते रहें (tail -f जैसा)
-n 50 — केवल अंतिम 50 पंक्तियाँ दिखाएँ
--since "1 hour ago" — समय के आधार पर सीमा निर्धारित करें
-p err — केवल त्रुटि-प्राथमिकता और उससे ऊपर की प्रविष्टियाँ दिखाएँ
-b — केवल वर्तमान बूट के लॉग दिखाएँ

जब कोई इकाई शुरू नहीं होती, तो सबसे पहले journalctl -u <unit> -n 30 --no-pager चलाएँ और उसके बाद systemctl status <unit> चलाकर हाल की त्रुटि का संदर्भ प्राप्त करें।

#!/usr/bin/env bash
# Troubleshooting helper: dump unit status and recent logs
# Usage: ./service-debug.sh <unit-name>

UNIT="${1:-nginx.service}"

echo "=============================="
echo "STATUS: $UNIT"
echo "=============================="
systemctl status "$UNIT" --no-pager -l

echo ""
echo "=============================="
echo "RECENT LOGS (last 50 lines): $UNIT"
echo "=============================="
journalctl -u "$UNIT" -n 50 --no-pager

echo ""
echo "=============================="
echo "ERRORS ONLY (current boot)"
echo "=============================="
journalctl -u "$UNIT" -b -p err --no-pager

ज्ञान जाँच: systemd इकाई फ़ाइलें

systemd सेवा और टाइमर इकाई के कॉन्फ़िगरेशन की अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पाठ का पुनरावलोकन: systemd सेवाओं का नियंत्रण और इकाई फ़ाइलें लिखना

इस पाठ में आपने पेशेवर स्तर पर systemd सेवा प्रबंधन और इकाई फ़ाइल लिखने की मूल अवधारणाओं का अध्ययन किया। इसमें शामिल विषयों का सारांश यहाँ दिया गया है:

systemctl की मूल बातें — स्क्रिप्ट-अनुकूल जाँच के लिए start, stop, restart, reload, enable, disable, status, is-active और is-enabled
सूची बनाना और फ़िल्टर करना — विफल या सक्षम सेवाओं को अलग करने के लिए --type और --state फ़्लैग के साथ list-units और list-unit-files
इकाई फ़ाइल की संरचना — तीन अनुभाग [Unit], [Service] और [Install] तथा उनके मुख्य निर्देश
सेवा के प्रकार — simple, forking, notify, oneshot और प्रत्येक का उपयोग कब करना है
पर्यावरण और सुरक्षा — सुदृढ़ डेमॉन के लिए EnvironmentFile, NoNewPrivileges, ProtectSystem, PrivateTmp
टाइमर इकाइयाँ — .timer और .service फ़ाइलों का युग्मन, OnCalendar अभिव्यक्तियाँ और Persistent द्वारा छूटे समय का कार्य पूरा करना
Journalctl — विफलताओं का कुशलतापूर्वक निदान करने के लिए इकाई, समय, बूट और प्राथमिकता के आधार पर फ़िल्टर करना

इन कौशलों के साथ आप किसी भी सिस्टम सेवा का प्रबंधन कर सकते हैं, आवर्ती कार्यों को विश्वसनीय रूप से निर्धारित कर सकते हैं और अपने डेमॉन के लिए उत्पादन-स्तर की इकाई फ़ाइलें लिख सकते हैं।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Bash सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 22
पाठ: 88

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना” पाठ निःशुल्क है?

हाँ—“systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना” में मैं क्या सीखूँगा?

systemctl से सेवाएँ चलाएँ और स्क्रिप्ट किए गए डेमॉन के लिए कस्टम यूनिट और टाइमर फ़ाइलें लिखें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

उपयोगकर्ता और समूह का प्रावधान स्वचालित करना
systemd सेवाओं का नियंत्रण और यूनिट फ़ाइलें लिखना
डिस्क, फ़ाइल सिस्टम और माउंट का स्वचालन
सिस्टम स्वास्थ्य जाँच और चेतावनी स्क्रिप्ट बनाना

← Linux कमांड लाइन और Bash स्क्रिप्टिंग में महारत पर वापस जाएँ