VPS वर program साठी systemd service कशी तयार करावी

systemd service म्हणजे काय आणि तो का वापरावा

systemd service ही एक लहान मजकूर फाइल असते. ती तुमच्या server ला एखादा program कसा चालवायचा हे सांगते: boot वेळी तो सुरू करणे, crash झाल्यास पुन्हा सुरू करणे आणि त्याचे output system log मध्ये पाठवणे. तिचे संपूर्ण काम एवढेच असते. SSH session मध्ये manually सुरू केलेला program तुम्ही logout करताच किंवा server reboot होताच बंद होतो. systemd service मध्ये गुंडाळलेला program चालू राहतो, कारण तुमच्या shell ऐवजी server स्वतः त्याचे व्यवस्थापन करतो.

Ubuntu, Debian, Fedora आणि बहुतेक आधुनिक Linux servers वर systemd ही init system आहे. सुरू होणारी ती पहिली process असते आणि इतर सर्व गोष्टींवर देखरेख ठेवते. हे नेहमीच असे नव्हते. unit file काय करते हे समजल्यानंतर systemd ने त्यापूर्वीच्या init scripts ची जागा कशी घेतली हे एकदा वाचणे उपयुक्त ठरेल. तुम्ही service file लिहिता तेव्हा तुमचा program त्या supervisor कडे सोपवता. या मार्गदर्शकात कार्य करणारी सर्वात लहान unit, प्रत्येक unit मध्ये असलेले तीन sections, ती enable करून तिचे logs कसे वाचायचे, timer वापरून ती schedule नुसार कशी चालवायची आणि शक्य तितक्या कमी 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

हे पूर्णपणे कार्यरत unit आहे. ExecStart ही चालवायची command आहे. WantedBy=multi-user.target म्हणजे सर्व्हर सामान्य multi-user operation पर्यंत पोहोचल्यानंतर ही सेवा सुरू करणे. त्यामुळे ती boot वेळी सुरू होते. उर्वरित सर्व बदल हे सुधारणा आहेत.

तीन sections आणि प्रत्येकाचा उपयोग

प्रत्येक unit file square brackets मधील sections मध्ये विभागलेली असते. एका service मध्ये तीन sections वापरले जातात.

[Unit] service आणि त्याचे संबंध वर्णन करते. तुम्ही सर्वाधिक वापरणाऱ्या दोन ओळी:

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

Description हे systemctl status मध्ये दिसणारे मानवी-वाचनीय label आहे. After=network-online.target systemd ला network सुरू होईपर्यंत तुमचा program सुरू करू नको असे सांगते. Port वर bind होणाऱ्या किंवा outbound connection करणाऱ्या कोणत्याही program साठी हे महत्त्वाचे आहे.

[Service] program कसा चालवायचा हे ठरवते. तुमच्या बहुतेक settings येथे असतात:

[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 root ऐवजी unprivileged account म्हणून चालवते. सुरक्षिततेसाठी ही सर्वात महत्त्वाची ओळ आहे. येथे Type= ओळ नाही. त्यामुळे systemd simple वर अवलंबून राहते आणि ExecStart process foreground मध्येच चालू राहील असे गृहीत धरते. एखादा program background मध्ये fork होत असेल, तर तो ज्या पद्धतीने सुरू होतो त्यासाठी योग्य Type= वापरावे लागते. अन्यथा unit active असल्याचे दाखवेल, पण खरा daemon आधीच बंद झालेला असेल. Restart=on-failure आणि RestartSec=5 यांच्यासाठी खाली स्वतंत्र section आहे, कारण बहुतेक लोक service लिहितात ते याच कारणासाठी.

[Install] service enable केल्यावर काय होते ते ठरवते:

[Install]
WantedBy=multi-user.target

तुम्ही systemctl enable चालवल्यावर WantedBy=multi-user.target service ला boot प्रक्रियेशी जोडते. [Install] section नसल्यास service हाताने सुरू करता येते, पण reboot नंतर ती आपोआप सुरू होणार नाही.

ते सुरू करा आणि त्यावर लक्ष ठेवा

कोणतीही 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 सेवेला boot वेळी सुरू होण्यासाठी enable करते आणि ती लगेच सुरू करते. हे तपासा:

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 वाचण्यासाठी, फक्त या unit साठी journal कडून नोंदी मागवा:

sudo journalctl -u myapp.service -f

-f नवीन ओळी उपलब्ध होताच त्यांचे अनुसरण करते, tail -f प्रमाणे. तुमचा प्रोग्राम standard output किंवा standard error वर जे काही लिहितो, ते तुमच्याकडून कोणतीही logging setup न करता येथे नोंदवले जाते.

बिघाड झाल्यावर पुनर्प्रारंभ, तुम्ही येथे येण्याचे कारण

सेवेचा मुख्य फायदा असा आहे की तुमचा प्रोग्राम बंद पडल्यावर systemd तो पुन्हा सुरू करतो. यासाठी दोन ओळी पुरेशा आहेत:

[Service]
Restart=on-failure
RestartSec=5

Restart=on-failure प्रोग्राम non-zero code सह बंद पडल्यावर किंवा SIGKILL किंवा SIGSEGV सारख्या crash signal मुळे बंद पडल्यावर तो पुन्हा सुरू करतो. स्वच्छपणे बंद होणे किंवा SIGTERM, SIGINT, SIGHUP अथवा SIGPIPE मुळे थांबणे यामुळे पुनर्प्रारंभ होत नाही. RestartSec=5 प्रत्येक प्रयत्नादरम्यान पाच सेकंद थांबतो. त्यामुळे लगेच crash होणारा प्रोग्राम सततच्या tight loop मध्ये फिरत राहत नाही. प्रक्रिया kill करून आणि systemd ती पुन्हा सुरू करताना monitor करून हे पडताळा. SIGKILL वापरा: default SIGTERM ला स्वच्छ थांबवणे मानले जाते, त्यामुळे on-failure सेवा पुन्हा सुरू करणार नाही:

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

पाच सेकंदांच्या आत status मध्ये नवीन Main PID दिसतो आणि active (running) पुन्हा दिसतो. हेच संपूर्ण वैशिष्ट्य आहे. त्यामुळे प्रोग्राम tmux किंवा screen मध्ये चालू ठेवण्यापेक्षा service वापरणे अधिक योग्य ठरते.

अविशेषाधिकार असलेल्या वापरकर्त्याच्या रूपात चालवा आणि सेवा अधिक सुरक्षित करा

एखादा प्रोग्राम exploit झाल्यास root म्हणून चालणारी सेवा तुमच्या सर्व्हरवर कोणतीही कृती करू शकते. ती सेवा स्वतंत्र वापरकर्त्याच्या रूपात चालवा आणि systemd मध्ये काही directives देऊन तिची कार्यमर्यादा ठरवा. प्रथम login आणि home नसलेले 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 प्रोग्रामला आवश्यक नसलेली एखादी गोष्ट काढून टाकते. NoNewPrivileges=true मुळे setuid binary द्वारेसुद्धा process ला नवीन privileges मिळवता येत नाहीत. PrivateTmp=true त्याला private /tmp देते, जे इतर कोणताही process पाहू शकत नाही. ProtectSystem=strict मुळे ReadWritePaths= द्वारे निर्दिष्ट केलेल्या काही paths वगळता संपूर्ण filesystem read-only होते. ProtectHome=true मुळे /home त्याच्यापासून पूर्णपणे लपवले जाते. सेवा firewall मागे ठेवताना वापरतो तोच least-privilege दृष्टिकोन येथे लागू होतो: सेवेला आवश्यक तेवढेच द्या. VPS वरील IPv6 firewall gap बंद करण्याचे मार्गदर्शक तुम्ही वाचले असल्यास, ही त्याच संकल्पनेची on-host बाजू आहे. इंटरनेट-facing सेवेसाठी या hardening सोबत SSH समोर Fail2ban आणि default-deny firewall वापरा.

हे सर्व manually लिहून एखादा directive चुकीचा लक्षात ठेवण्याऐवजी, complete hardened unit तयार करून तो बाहेर copy करा:

Timers: आधुनिक cron

systemd timer ठरावीक वेळापत्रकानुसार एखादी service चालवतो. हा cron job चा आधुनिक पर्याय आहे. Timer मध्ये दोन files असतात: काम करणारी .service आणि ती service कधी चालवायची हे सांगणारी .timer. दररोज पहाटे 3 वाजता backup घ्यायचा आहे असे समजा. Service हे काम एकदा करते आणि बंद होते:

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

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

Type=oneshot systemd ला सांगते की program चालतो, काम पूर्ण करतो आणि समाप्त होतो. तो सतत चालू राहणारा resident process नाही. Timer त्याचे वेळापत्रक ठरवतो:

# /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 वाजता. कोणतेही calendar expression systemd-analyze calendar "*-*-* 03:00:00" वापरून तपासा. ते expression चे parsing यशस्वी झाले आहे का हे निश्चित करते आणि timer पुढील वेळी कधी चालेल ते दाखवते. Server पहाटे 3 वाजता बंद असेल, तर Persistent=true server पुन्हा उपलब्ध होताच चुकलेला job चालवतो. cron हे करू शकत नाही. Timer timers.target द्वारे enable केला जातो, multi-user.target द्वारे नाही, हे लक्षात ठेवा. Service नव्हे, timer enable करा:

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

list-timers प्रत्येक timer, त्याची पुढील run time आणि शेवटची run time दाखवते. त्यामुळे तुमचा job पुढे कधी चालेल हे लगेच दिसते. Timer mode सुरू केल्यावर वरील generator तुमच्यासाठी संबंधित .service आणि .timer तयार करतो. cron line च्या तुलनेत timer मुळे journal मध्ये प्रत्यक्ष logs मिळतात, कोणत्याही service प्रमाणेच hardening directives वापरता येतात आणि Persistent=true पुरवत असलेली missed-run catch-up सुविधा मिळते. साध्या job साठी cron अजूनही योग्य आहे. परंतु job महत्त्वाचा असेल, तर timer हे अधिक चांगले साधन आहे.

FAQ

systemd service आणि cron job यांच्यात काय फरक आहे?

service दीर्घकाळ चालणारा program सक्रिय ठेवते: ती boot वेळी सुरू होते, failure नंतर restart होते आणि journal मध्ये logs नोंदवते. cron job ठरलेल्या वेळापत्रकानुसार एखादी छोटी command चालवते आणि नंतर बंद होते. तुम्हाला scheduling सोबत journal logs, hardening आणि चुकलेल्या runs साठी catch-up हवे असल्यास systemd timer वापरा. तो .timer schedule ला oneshot service सोबत जोडतो आणि server वरील बहुतेक कामांसाठी cron ची जागा घेतो.

माझी systemd service file कुठे ठेवावी?

तुमच्या स्वतःच्या units /etc/systemd/system/ मध्ये ठेवा आणि नावाचा शेवट .service ने करा. हा directory administrator ने जोडलेल्या units साठी असतो. /lib/systemd/system/ मधील packages ने ship केलेल्या units पेक्षा या directory ला प्राधान्य मिळते. तेथे file तयार केल्यानंतर किंवा संपादित केल्यानंतर sudo systemctl daemon-reload चालवा, म्हणजे systemd ला बदल समजतो.

service crash झाल्यास ती पुन्हा सुरू कशी करावी?

[Service] section मध्ये Restart=on-failure आणि RestartSec=5 जोडा. त्यानंतर sudo systemctl daemon-reload चालवून service restart करा. Program non-zero code ने बंद झाल्यास किंवा crash signal मुळे समाप्त झाल्यास systemd तो पुन्हा सुरू करते. प्रत्येक प्रयत्नामध्ये systemd पाच सेकंद थांबते. sudo systemctl kill -s SIGKILL myapp.service वापरून त्याची चाचणी करा. SIGTERM हा default signal आहे; तो clean stop मानला जातो आणि on-failure सुरू करत नाही. काही सेकंदांत नवीन PID दिसतो का हे systemctl status वापरून तपासा.

systemd service non-root user म्हणून कशी चालवावी?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp वापरून system account तयार करा. त्यानंतर [Service] section मध्ये User=myapp जोडा. Process ला आवश्यक तेवढाच access मिळण्यासाठी NoNewPrivileges=true, PrivateTmp=true आणि ProtectSystem=strict जोडा. Unprivileged user म्हणून चालवणे हा service ची safety सुधारण्यासाठी करता येणारा सर्वात महत्त्वाचा एकल बदल आहे.

माझी service सुरू होण्यात failure का आला?

सारांशासाठी systemctl status myapp.service आणि संपूर्ण output साठी journalctl -u myapp.service चालवा. सर्वात सामान्य कारणांमध्ये ExecStart मधील चुकीचा path, WorkingDirectory उपलब्ध नसणे, User= एखादी file वाचू शकत नसल्यामुळे आलेली permission error किंवा edit केल्यानंतर sudo systemctl daemon-reload विसरणे यांचा समावेश होतो. Journal मध्ये program चा स्वतःचा error message दिसतो. त्यात बहुतेक वेळा समस्या थेट नमूद केलेली असते.