VPS-ல் systemd service உருவாக்கி நிரலை இயக்குவது எப்படி

systemd service என்றால் என்ன, ஏன் அது தேவை

systemd service என்பது ஒரு சிறிய உரை கோப்பு. ஒரு நிரலை எப்படி இயக்குவது என்பதை இது உங்கள் சேவையகத்திற்குக் கூறுகிறது: பூட் செய்யும்போது அதைத் தொடங்கு, அது செயலிழித்தால் மறுதொடக்கம் செய், அதன் வெளியீட்டை system log-க்கு அனுப்பு. இதுதான் அதன் முழு வேலை. நீங்கள் ஒரு SSH session-ல் கைமுறையாகத் தொடங்கும் நிரல், நீங்கள் வெளியேறியவுடன் அல்லது சேவையகம் மறுதொடக்கம் செய்தவுடன் நின்றுவிடும். systemd service-ல் மடக்கப்பட்ட நிரல் தொடர்ந்து இயங்கும். ஏனெனில் உங்கள் shell-க்குப் பதிலாக சேவையகமே அந்த நிரலை வைத்திருக்கிறது.

Ubuntu, Debian, Fedora, மற்றும் பெரும்பாலான நவீன Linux சேவையகங்களில் systemd தான் init system. இதுதான் முதலில் தொடங்கும் செயல்முறை. மற்ற அனைத்தையும் இதுதான் மேற்பார்வையிடுகிறது. நீங்கள் ஒரு service கோப்பை எழுதும்போது, உங்கள் நிரலை அந்த மேற்பார்வையாளரிடம் ஒப்படைக்கிறீர்கள். இந்த வழிகாட்டி செயல்படும் மிகச் சிறிய அலகைக் காட்டுகிறது. ஒவ்வொரு அலகும் கொண்டிருக்கும் மூன்று பிரிவுகள், அதை எப்படி இயக்குவது மற்றும் அதன் log-களை எப்படி வாசிப்பது, ஒரு timer மூலம் அதை எப்படி திட்டமிட்டு இயக்குவது, மற்றும் முடிந்தவரை குறைந்த அனுமதியுடன் அது இயங்குவதற்கு எப்படி அதைப் பூட்டுவது ஆகியவற்றையும் இது விளக்குகிறது.

செயல்படும் மிகச் சிறிய சேவை

ஒரு சேவை கோப்பு /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 என்பது இயக்க வேண்டிய கட்டளை. WantedBy=multi-user.target என்பது சேவையகம் இயல்பான multi-user செயல்பாட்டை அடைந்ததும் இதை ஒரு முறை தொடங்கு என்று பொருள்படும்; இதுதான் boot செய்யும்போது இது தொடங்கக் காரணமாகிறது. மற்ற அனைத்தும் மேம்படுத்தல்களே.

மூன்று பிரிவுகள், மற்றும் ஒவ்வொன்றின் பயன்

ஒவ்வொரு unit கோப்பும் சதுர அடைப்புக்குறிக்குள் உள்ள பிரிவுகளாக பிரிக்கப்பட்டுள்ளது. ஒரு service மூன்றைப் பயன்படுத்துகிறது.

[Unit] என்பது service மற்றும் அதன் தொடர்புகளை விவரிக்கிறது. நீங்கள் அதிகம் பயன்படுத்தும் இரண்டு வரிகள்:

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

Description என்பது systemctl status இல் நீங்கள் காணும் மனிதக் குறியீடு. After=network-online.target என்பது systemd உங்கள் நிரலை network இயங்கும் வரை தொடங்காமல் இருக்கச் சொல்கிறது. ஒரு port ஐ bind செய்யும் அல்லது வெளிச்சேவைக்கு இணைப்பை ஏற்படுத்தும் எதற்கும் இது முக்கியம்.

[Service] என்பது நிரல் எவ்வாறு இயங்குகிறது என்பதாகும். உங்கள் பெரும்பாலான அமைப்புகள் இங்கே வருகின்றன:

[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 நிரலை root க்கு பதிலாக ஒரு சலுகை இல்லாத கணக்காக இயக்குகிறது. பாதுகாப்பிற்கு இதுவே மிக முக்கியமான வரி. Restart=on-failure மற்றும் RestartSec=5 கீழே தனிப்பிரிவு பெறுகின்றன. ஏனெனில் பெரும்பாலானோர் ஒரு service எழுதுவதற்கு காரணமே இவைதாம்.

[Install] என்பது நீங்கள் service ஐ enable செய்யும்போது என்ன நிகழ்கிறது என்பதாகும்:

[Install]
WantedBy=multi-user.target

WantedBy=multi-user.target என்பது நீங்கள் systemctl enable ஐ இயக்கும்போது service ஐ boot உடன் இணைப்பதாகும். ஒரு [Install] பிரிவு இல்லாவிட்டால், ஒரு service ஐ கைமுறையாக தொடங்கலாம். ஆனால் reboot செய்த பிறகு அது தானாக தொடங்காது.

இயக்கி கவனிக்கவும்

எந்த unit கோப்பையும் எழுதியதும் அல்லது திருத்தியதும், systemd மாற்றத்தைப் படிக்கும்படி reload செய்யவும். பிறகு ஒரே படியில் சேவையை enable செய்து தொடங்கவும்:

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

daemon-reload என்பது நிறைய பேர் மறந்துவிடும் படி: systemd unit கோப்புகளை 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 தான் நீங்கள் எதிர்பார்ப்பவை. நிரலின் வெளியீட்டைப் படிக்க, இந்த unit-க்கான journal-ஐ மட்டும் கேட்கவும்:

sudo journalctl -u myapp.service -f

-f புதிய வரிகள் வரும்போது அவற்றைத் தொடர்ந்து காட்டும், tail -f போல. உங்கள் நிரல் standard output அல்லது standard error-க்கு எழுதும் அனைத்தும் இங்கே வந்து சேரும்; உங்கள் பக்கம் எந்த logging அமைப்பும் தேவையில்லை.

தோல்வியின் போது மறுதொடக்கம், நீங்கள் இங்கே இருப்பதற்கான காரணம்

ஒரு service-ன் முக்கிய நன்மை என்னவென்றால், உங்கள் நிரல் நின்றுபோனால் systemd அதை மீண்டும் தொடங்கும். இரண்டு வரிகள் இதைச் செய்கின்றன:

[Service]
Restart=on-failure
RestartSec=5

நிரல் பூஜ்யமற்ற குறியீட்டுடன் வெளியேறினாலோ அல்லது SIGKILL அல்லது SIGSEGV போன்ற crash signal காரணமாக நின்றுபோனாலோ Restart=on-failure அந்த நிரலை மீண்டும் தொடங்கும். சரியான முறையில் வெளியேறுவது, அல்லது SIGTERM, SIGINT, SIGHUP, அல்லது SIGPIPE மூலமான நிறுத்தம், மறுதொடக்கத்தைத் தூண்டாது. ஒவ்வொரு முயற்சிக்கும் இடையில் RestartSec=5 ஐந்து வினாடிகள் காத்திருக்கும். எனவே உடனடியாக crash ஆகும் நிரல் தொடர்ச்சியான சுழற்சியில் சுழலாது. செயல்முறையை kill செய்து, systemd அதை மீண்டும் தொடங்குவதைப் பார்த்து இதை உறுதிப்படுத்தவும். SIGKILL ஐப் பயன்படுத்தவும்: இயல்புநிலையான SIGTERM ஒரு சரியான நிறுத்தமாகக் கணக்கிடப்படுவதால், on-failure அந்த service-ஐ மறுதொடக்கம் செய்யாது:

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

ஐந்து வினாடிகளுக்குள் நிலை ஒரு புதிய Main PID ஐக் காட்டும், மேலும் active (running) மீண்டும் இயங்கும். இதுதான் அந்த அம்சம் முழுவதும், மேலும் ஒரு நிரலை tmux அல்லது screen இல் இயக்கிக் கொண்டிருப்பதை விட ஒரு service சிறப்பானது என்பதற்கான காரணமும் இதுவே.

சிறப்புச் சலுகைகள் இல்லாத பயனராக இயக்கி, பாதுகாப்பை வலுப்படுத்தவும்

root ஆக இயங்கும் சேவையால், நிரல் ஒருமுறை தாக்கப்பட்டால் உங்கள் சேவையகத்தில் எதை வேண்டுமானாலும் செய்ய முடியும். அதை அதற்கே உரிய தனி ஒரு பயனராக இயக்கவும். systemd-க்கு அதை வரம்புக்குள் வைக்கும் சில செயற்கோள்களையும் சேர்க்கவும். முதலில், உள்நுழைவோ இல்லாத, முகப்பு அடைவோ இல்லாத ஒரு கணக்கை உருவாக்கவும்:

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

பிறகு User=myapp என்பதை அமைத்து, [Service] கோப்பில் பாதுகாப்பை வலுப்படுத்தும் வரிகளைச் சேர்க்கவும்:

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

ஒவ்வொரு வரியும் நிரலுக்குத் தேவையில்லாத ஒரு அம்சத்தை நீக்குகிறது. NoNewPrivileges=true, setuid நிரல் வழியாகக் கூட, இந்தச் செயல்முறை புதிய சலுகைகளைப் பெறுவதைத் தடுக்கிறது. PrivateTmp=true, வேறு எந்தச் செயல்முறையாலும் பார்க்க முடியாத தனியான ஒரு /tmp-ஐ இதற்கு அளிக்கிறது. ProtectSystem=strict, நீங்கள் ReadWritePaths= மூலம் குறிப்பிடும் சில பாதைகளைத் தவிர, முழு கோப்பு முறைமையையும் படிக்க மட்டுமே அனுமதிக்கும் நிலையாக மாற்றுகிறது. ProtectHome=true, /home-ஐ இதிலிருந்து முற்றிலுமாக மறைக்கிறது. இது, ஒரு சேவையை ஃபயர்வாலுக்குப் பின்னால் வைப்பதைப் போன்ற அதே குறைந்தபட்ச சலுகை அணுகுமுறைதான்: அதற்குத் தேவையானதை மட்டுமே வழங்கவும். நீங்கள் VPS-ல் IPv6 ஃபயர்வால் ஓட்டையை அடைத்தல் பற்றிய வழிகாட்டியைப் படித்திருந்தால், இது அதே கருத்தின் சேவையகத்திற்குள்ளேயான பகுதியாகும். இணையத்தை நோக்கி இயங்கும் ஒரு சேவைக்கு, இந்தப் பாதுகாப்பு வலுவூட்டலை SSH-க்கு முன்னால் Fail2ban மற்றும் இயல்பாக நிராகரிக்கும் (default-deny) ஃபயர்வாலுடன் இணைக்கவும்.

இவை அனைத்தையும் கைமுறையாகத் தட்டச்சு செய்து ஒரு செயற்கோளைத் தவறாக நினைவுகூர்வதை விட, முழுமையாகப் பாதுகாப்பு வலுவூட்டப்பட்ட ஒரு unit-ஐ உருவாக்கி அதை நகலெடுக்கவும்:

டைமர்கள்: நவீன cron

ஒரு systemd டைமர் ஒரு சேவையை கால அட்டவணைப்படி இயக்குகிறது. இது cron வேலைக்கு நவீன மாற்றாகும். ஒரு டைமர் என்பது இரண்டு கோப்புகள்: வேலையைச் செய்யும் ஒரு .service, மற்றும் எப்போது என்று கூறும் ஒரு .timer. தினமும் காலை 3 மணிக்கு ஒரு காப்பு வேண்டும் என்று வைத்துக்கொள்வோம். சேவை வேலையை ஒரு முறை செய்து வெளியேறுகிறது:

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

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

Type=oneshot என்பது systemd-க்கு நிரல் இயங்கி முடிந்து முடிந்தது என்று கூறுகிறது; அது நிரந்தரமாக தங்கி இருப்பதில்லை. டைமர் இதை கால அட்டவணைப்படுத்துகிறது:

# /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 மணி என்று பொருள். எந்த நாட்காட்டி வெளிப்பாட்டையும் systemd-analyze calendar "*-*-* 03:00:00" கொண்டு சோதிக்கவும். இது அது சரியாக பாகுபடுத்தப்பட்டதை உறுதிப்படுத்தி, அடுத்து எப்போது இயங்கும் என்பதை அச்சிடும். காலை 3 மணிக்கு சேவையகம் அணைந்திருந்தால், அது மீண்டும் இயங்கத் தொடங்கியவுடன் தவறிய வேலையை Persistent=true உடனே இயக்கும்; இதை cron செய்ய முடியாது. ஒரு டைமர் timers.target வழியாக இயக்கப்படுகிறது, multi-user.target வழியாக அல்ல என்பதை கவனிக்கவும். சேவையை அல்ல, டைமரை இயக்கவும்:

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

list-timers ஒவ்வொரு டைமரையும் அதன் அடுத்த மற்றும் கடந்த இயக்கத்துடன் காட்டுகிறது. எனவே உங்கள் வேலை அடுத்து எப்போது இயங்கும் என்பதை ஒரு பார்வையில் காணலாம். மேலே உள்ள உருவாக்கி, நீங்கள் டைமர் பயன்முறையை இயக்கும்போது இணைந்த .service மற்றும் .timer ஆகியவற்றை உங்களுக்காக உருவாக்குகிறது. ஒரு cron வரியுடன் ஒப்பிடும்போது, ஒரு டைமர் ஜர்னலில் உண்மையான பதிவுகளைத் தருகிறது, எந்த சேவையையும் போலவே அதே பாதுகாப்பு அறிவுறுத்தல்களைத் தருகிறது, மேலும் Persistent=true வழங்கும் தவறிய-இயக்கத்தை பிடித்து இயக்கும் வசதியைத் தருகிறது. எளிய வேலைக்கு cron இன்னும் போதுமானது; வேலை முக்கியமானதாக மாறும்போது டைமர் சிறந்த கருவி.

FAQ

systemd service க்கும் cron job க்கும் என்ன வித்தியாசம்?

ஒரு service நீண்ட நேரம் இயங்கும் நிரலை இயக்கநிலையில் வைத்திருக்கும்: இது boot செய்யும்போது தொடங்கும், தோல்வியடைந்தால் மறுதொடக்கம் செய்யும், மேலும் journal இல் பதிவு செய்யும். ஒரு cron job குறித்த திட்டத்தில் ஒரு குறுகிய command ஐ இயக்கி வெளியேறும். நீங்கள் திட்டமிடல் வேண்டும், அதேசமயம் journal பதிவுகள், hardening, மற்றும் தவறிய இயக்கங்களுக்கான catch-up ஆகியவற்றையும் விரும்பினால், ஒரு systemd timer ஐப் பயன்படுத்தவும். இது ஒரு .timer திட்டத்தை ஒரு oneshot service உடன் இணைக்கிறது, மேலும் பெரும்பாலான server பணிகளுக்கு cron க்கு பதிலாக பயன்படுகிறது.

எனது systemd service file ஐ எங்கே வைப்பது?

உங்கள் சொந்த unit களை /etc/systemd/system/ இல் வைக்கவும், அதன் பெயர் .service உடன் முடிவடைய வேண்டும். அந்த directory நிர்வாகி சேர்க்கும் unit களுக்கானது, மேலும் இது /lib/systemd/system/ இல் package களால் வழங்கப்படும் unit களை விட முன்னுரிமை பெறும். அங்கு ஒரு file ஐ உருவாக்கிய பிறகு அல்லது திருத்திய பிறகு, systemd மாற்றத்தை ஏற்றுக்கொள்ள sudo systemctl daemon-reload ஐ இயக்கவும்.

ஒரு service செயலிழந்தால் அதை எப்படி மறுதொடக்கம் செய்வது?

Restart=on-failure மற்றும் RestartSec=5 ஐ [Service] section இல் சேர்க்கவும், பிறகு sudo systemctl daemon-reload ஐ இயக்கி service ஐ மறுதொடக்கம் செய்யவும். நிரல் பூஜ்யமற்ற குறியீட்டுடன் வெளியேறினாலோ அல்லது crash signal காரணமாக முடிந்தாலோ, systemd அதை மீண்டும் தொடங்கும்; ஒவ்வொரு முயற்சிக்கும் இடையே ஐந்து வினாடிகள் காத்திருக்கும். இதை sudo systemctl kill -s SIGKILL myapp.service உடன் சோதிக்கவும் — இயல்புநிலை signal ஆன SIGTERM ஒரு சீரான நிறுத்தமாகக் கருதப்படும், இது on-failure ஐத் தூண்டாது — மேலும் சில வினாடிகளில் systemctl status ஒரு புதிய PID ஐக் காட்டுவதைக் கவனிக்கவும்.

ஒரு systemd service ஐ non-root user ஆக எப்படி இயக்குவது?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp உடன் ஒரு system account உருவாக்கவும், பிறகு User=myapp ஐ [Service] section இல் சேர்க்கவும். செயல்முறை தேவையான குறைந்தபட்ச அணுகலுடன் இயங்க NoNewPrivileges=true, PrivateTmp=true, மற்றும் ProtectSystem=strict சேர்க்கவும். ஒரு unprivileged user ஆக இயக்குவது ஒரு service பாதுகாப்பிற்கு நீங்கள் செய்யக்கூடிய மிக முக்கியமான ஒற்றை மாற்றமாகும்.

எனது service தொடங்கத் தோல்வியடைந்தது ஏன்?

சுருக்கத்திற்கு systemctl status myapp.service ஐயும் முழு வெளியீட்டிற்கு journalctl -u myapp.service ஐயும் இயக்கவும். மிக பொதுவான காரணங்கள்: ExecStart இல் தவறான path, ஒரு விடுபட்ட WorkingDirectory, User= ஒரு file ஐ படிக்க முடியாததால் ஏற்படும் அனுமதி பிழை, அல்லது திருத்திய பிறகு ஒரு மறந்த sudo systemctl daemon-reload. journal நிரலின் சொந்த பிழைச் செய்தியைக் காட்டும், இது பொதுவாக பிரச்சினையை நேரடியாகக் குறிப்பிடும்.