VPS पर systemd service कैसे बनाएँ

systemd service क्या है, और आपको इसकी आवश्यकता क्यों है

systemd service एक छोटी text file होती है जो आपके server को बताती है कि किसी program को कैसे चलाना है: boot के समय इसे start करना, crash होने पर restart करना, और output को system log में भेजना। बस इतना ही इसका काम है। यदि आप किसी program को SSH session में manually start करते हैं, तो logout करते ही या server reboot होते ही वह बंद हो जाएगा। इसके विपरीत, systemd service में wrapped program चलता रहता है, क्योंकि इसे आपकी shell के बजाय server खुद manage करता है।

systemd, Ubuntu, Debian, Fedora और अधिकांश modern Linux servers का init system है। यह सबसे पहला process है जो start होता है और अन्य सभी processes की निगरानी (supervise) करता है। जब आप service file लिखते हैं, तो आप अपने program को उस supervisor को सौंप देते हैं। यह guide आपको एक working unit का सबसे छोटा रूप, उसके तीनों sections, service को enable और logs पढ़ने का तरीका, timer के साथ schedule पर चलाना, और security के लिए न्यूनतम privileges के साथ इसे run करना सिखाएगी।

सबसे छोटा कार्यशील service

एक service file /etc/systemd/system/ में स्थित होती है, जिसका extension .service होता है, और इसमें केवल कुछ ही lines की आवश्यकता होती है। /usr/local/bin/myapp पर स्थित program के लिए एक file बनाएँ:

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

[Unit]
Description=My application

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

[Install]
WantedBy=multi-user.target

यह एक पूर्ण और कार्यशील unit है। ExecStart वह command है जिसे run करना है। WantedBy=multi-user.target का अर्थ है कि जब server normal multi-user operation पर पहुँच जाए, तब इसे start करें; यही कारण है कि यह boot के समय start होता है। अन्य सभी चीजें केवल refinement हैं।

Teen sections, aur unka upyog

Har unit file square brackets mein diye gaye sections mein vibhajit hoti hai. Ek service teen sections ka upyog karti hai.

[Unit] service aur uske relationships ko describe karta hai. Sabse zyada istemal hone wali do lines:

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

Description woh human label hai jo aapko systemctl status mein dikhta hai. After=network-online.target systemd ko batata hai ki jab tak network up na ho jaye, aapka program start na kare. Yeh un sabhi ke liye zaroori hai jo port bind karte hain ya outbound connection banate hain.

[Service] batata hai ki program kaise chalega. Aapki zyadaatar settings yahan hoti hain:

[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 program ko root ke bajaye ek unprivileged account ke roop mein chalata hai, jo safety ke liye sabse mahatvapurn line hai. Restart=on-failure aur RestartSec=5 ke liye niche alag section hota hai, kyunki log aksar service isi wajah se likhte hain.

[Install] woh hota hai jo service enable karne par hota hai:

[Install]
WantedBy=multi-user.target

WantedBy=multi-user.target service ko boot ke saath link karta hai jab aap systemctl enable chalate hain. [Install] section ke bina, service ko manually start kiya ja sakta hai, lekin reboot ke baad yeh apne aap start nahi hogi.

इसे चालू करें और देखें

किसी भी unit file को लिखने या edit करने के बाद, systemd को reload करें ताकि वह बदलावों को पढ़ सके। फिर, एक ही step में service को enable और start करें:

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

daemon-reload वह step है जिसे लोग अक्सर भूल जाते हैं: systemd unit files को cache करता है, इसलिए reload किए बिना edit करने का कोई असर नहीं होगा। enable --now service को boot के लिए 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 वह output है जो आपको चाहिए। Program का output पढ़ने के लिए, journal से केवल इसी unit का log मांगें:

sudo journalctl -u myapp.service -f

-f नए lines को उसी तरह follow करता है जैसे tail -f करता है। आपका program standard output या standard error पर जो कुछ भी write करेगा, वह यहाँ दिखाई देगा, इसके लिए आपको किसी logging setup की आवश्यकता नहीं है।

Failure पर restart करना, जिसके कारण आप यहाँ हैं

Service का मुख्य लाभ यह है कि जब आपका program बंद हो जाता है, तो systemd उसे restart कर देता है। इसके लिए दो lines का उपयोग किया जाता है:

[Service]
Restart=on-failure
RestartSec=5

Restart=on-failure program को तब restart करता है जब वह non-zero code के साथ exit होता है या SIGKILL या SIGSEGV जैसे crash signal से बंद हो जाता है। Clean exit, या SIGTERM, SIGINT, SIGHUP, या SIGPIPE द्वारा किया गया stop, इसे trigger नहीं करता है। RestartSec=5 हर attempt के बीच पांच सेकंड का wait करता है, ताकि तुरंत crash होने वाला program एक tight loop में न फँस जाए। इसे process को kill करके और systemd को उसे वापस लाते हुए देखकर confirm करें। SIGKILL का उपयोग करें: default SIGTERM एक clean stop माना जाता है, इसलिए on-failure service को restart नहीं करेगा:

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

पाँच सेकंड के भीतर status में एक नया Main PID और active (running) दिखाई देगा। यही इस feature की विशेषता है, और इसी कारण service का उपयोग करना tmux या screen में program को running छोड़ने से बेहतर है।

इसे unprivileged user के रूप में चलाएं, और इसे harden करें

यदि program का exploitation होता है, तो root के रूप में चलने वाली service आपके server पर कुछ भी कर सकती है। इसे इसके अपने user के रूप में चलाएं, और systemd को कुछ directives दें जो इसे सीमित (fence in) कर सकें। सबसे पहले, बिना login और बिना home directory वाला एक system account बनाएं:

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

फिर User=myapp सेट करें और [Service] में hardening lines जोड़ें:

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

प्रत्येक line उस चीज़ को हटा देती है जिसकी program को आवश्यकता नहीं है। NoNewPrivileges=true process को setuid binary के माध्यम से भी नए privileges प्राप्त करने से रोकता है। PrivateTmp=true इसे एक private /tmp देता है जिसे कोई अन्य process नहीं देख सकता। ProtectSystem=strict पूरे filesystem को read-only बना देता है, सिवाय उन कुछ paths के जिन्हें आप ReadWritePaths= के साथ नाम देते हैं। ProtectHome=true पूरी तरह से /home को इससे छुपा देता है। यह firewall के पीछे service रखने जैसा ही least-privilege सिद्धांत है: इसे केवल वही दें जिसकी इसे आवश्यकता है। यदि आपने closing the IPv6 firewall gap on a VPS पर guide पढ़ ली है, तो यह उसी विचार का on-host हिस्सा है। Internet से जुड़े service के लिए, इस hardening को Fail2ban in front of SSH और default-deny firewall के साथ उपयोग करें।

इन सभी को हाथ से टाइप करने और किसी directive को गलत याद रखने के बजाय, एक complete, hardened unit generate करें और उसे copy करें:

Timers: modern cron

systemd timer एक schedule पर service चलाता है, और यह cron job का आधुनिक विकल्प है। एक timer दो files से बना होता है: एक .service जो काम करता है, और एक .timer जो समय बताता है। मान लीजिए आप हर दिन 3am पर backup चाहते हैं। service कार्य को एक बार पूरा करके exit हो जाती है:

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

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

Type=oneshot systemd को बताता है कि program चलता है, पूरा होता है, और बंद हो जाता है, न कि background में चलता रहता है। timer इसे schedule करता है:

# /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 का अर्थ है हर दिन 3am। किसी भी calendar expression को systemd-analyze calendar "*-*-* 03:00:00" के साथ test करें, जो यह confirm करता है कि वह सही से parse हुआ है और अगली बार कब चलेगा। यदि server 3am पर बंद था, तो Persistent=true छूटे हुए job को server चालू होते ही तुरंत चला देता है, जो cron नहीं कर सकता। ध्यान दें कि timer को timers.target के माध्यम से enable किया जाता है, multi-user.target के माध्यम से नहीं। timer को enable करें, service को नहीं:

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

list-timers हर timer को उसके next और last run के साथ दिखाता है, जिससे आप तुरंत देख सकते हैं कि आपका job अगली बार कब चलेगा। ऊपर दिया गया generator timer mode चालू करने पर आपके लिए paired .service और .timer बना देता है। cron की तुलना में, timer आपको journal में real logs, किसी भी service की तरह hardening directives, और Persistent=true द्वारा प्रदान किया गया missed-run catch-up देता है। सरल job के लिए cron अभी भी ठीक है; लेकिन महत्वपूर्ण job के लिए timer एक बेहतर tool है।

FAQ

systemd service और cron job में क्या अंतर है?

एक service लंबे समय तक चलने वाले program को चालू रखती है: यह boot पर शुरू होती है, failure होने पर restart होती है, और journal में log करती है। एक cron job एक schedule पर छोटा command चलाती है और फिर exit हो जाती है। यदि आपको scheduling के साथ-साथ journal logs, hardening, और छूटे हुए runs के लिए catch-up की आवश्यकता है, तो systemd timer का उपयोग करें। यह .timer schedule को oneshot service के साथ जोड़ता है और अधिकांश server tasks के लिए cron का स्थान लेता है।

मैं अपनी systemd service file कहाँ रखूँ?

अपनी units को /etc/systemd/system/ में रखें, जिसका नाम .service पर समाप्त होता हो। वह directory administrator द्वारा जोड़ी गई units के लिए है, और यह /lib/systemd/system/ में packages द्वारा भेजी गई units की तुलना में प्राथमिकता लेती है। वहां कोई file बनाने या edit करने के बाद, sudo systemctl daemon-reload चलाएँ ताकि systemd बदलाव को पहचान सके।

service के crash होने पर उसे restart कैसे करें?

[Service] section में Restart=on-failure और RestartSec=5 जोड़ें, फिर sudo systemctl daemon-reload चलाएँ और service को restart करें। जब program non-zero code के साथ exit होता है या crash signal से मर जाता है, तो systemd उसे relaunch करता है। यह प्रत्येक प्रयास के बीच पांच सेकंड का इंतज़ार करता है। इसे sudo systemctl kill -s SIGKILL myapp.service के साथ test करें — SIGTERM, जो default signal है, एक clean stop माना जाता है और on-failure को trigger नहीं करता है — और देखें कि systemctl status कुछ ही सेकंड में एक नया PID दिखाता है।

systemd service को non-root user के रूप में कैसे चलाएँ?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp के साथ एक system account बनाएँ, फिर [Service] section में User=myapp जोड़ें। NoNewPrivileges=true, PrivateTmp=true, और ProtectSystem=strict जोड़ें ताकि process को केवल आवश्यक न्यूनतम access मिले। unprivileged user के रूप में चलाना किसी service की safety के लिए सबसे महत्वपूर्ण बदलाव है।

मेरी service start होने में fail क्यों हुई?

summary के लिए systemctl status myapp.service चलाएँ और full output के लिए journalctl -u myapp.service चलाएँ। सबसे सामान्य कारण ExecStart में गलत path, missing WorkingDirectory, permission error क्योंकि User= किसी file को पढ़ नहीं सकता, या edit करने के बाद sudo systemctl daemon-reload को भूल जाना है। journal program का अपना error message दिखाता है, जो आमतौर पर समस्या का नाम सीधे बताता है।