Linux VPS-ல் systemd service உருவாக்குவது எப்படி?

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

systemd service என்பது ஒரு சிறிய text file ஆகும். இது ஒரு program-ஐ எவ்வாறு இயக்குவது என்பதை server-க்கு அறிவுறுத்துகிறது: boot செய்யும்போது தொடங்குவது, crash ஆனால் மீண்டும் தொடங்குவது, மற்றும் அதன் output-ஐ system log-க்கு அனுப்புவது போன்றவை இதன் பணிகள். நீங்கள் SSH session-ல் கைமுறையாகத் தொடங்கும் ஒரு program, நீங்கள் logout செய்தவுடன் அல்லது server reboot ஆனவுடன் நின்றுவிடும். ஆனால், systemd service-க்குள் உள்ள ஒரு program தொடர்ந்து இயங்கும், ஏனெனில் அதை உங்கள் shell-க்கு பதிலாக server-ே நிர்வகிக்கிறது.

Ubuntu, Debian, Fedora மற்றும் பெரும்பாலான நவீன Linux server-களில் systemd தான் init system-ஆக உள்ளது. இதுவே முதலில் தொடங்கும் process மற்றும் மற்ற அனைத்தையும் கண்காணிக்கும் அமைப்பாகும். இது எப்போதும் இப்படி இருந்ததில்லை, systemd எவ்வாறு பழைய init scripts-க்கு மாற்றாக வந்தது என்பதைப் பற்றி அறிந்துகொள்வது, unit file-ன் செயல்பாட்டைப் புரிந்துகொண்ட பிறகு பயனுள்ளதாக இருக்கும். நீங்கள் ஒரு service file-ஐ உருவாக்கும்போது, உங்கள் program-ஐ இந்த supervisor-ன் கட்டுப்பாட்டில் ஒப்படைக்கிறீர்கள். இந்த வழிகாட்டி, செயல்படக்கூடிய மிகச்சிறிய unit, ஒவ்வொரு unit-லும் இருக்க வேண்டிய மூன்று பகுதிகள், அதை எவ்வாறு இயக்குவது மற்றும் அதன் logs-ஐப் படிப்பது, timer மூலம் குறிப்பிட்ட நேரத்தில் இயக்குவது, மற்றும் குறைந்தபட்ச அதிகாரங்களுடன் (privilege) பாதுகாப்பாக இயக்குவது எப்படி என்பதை விளக்குகிறது.

செயல்படக்கூடிய மிகச்சிறிய service

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

மூன்று பிரிவுகள் மற்றும் அவற்றின் பயன்பாடுகள்

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

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

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

Description என்பது systemctl status-ல் நீங்கள் காணும் மனிதர்களுக்குப் புரியக்கூடிய பெயராகும். After=network-online.target என்பது network தயாராகும் வரை உங்கள் நிரலைத் தொடங்க வேண்டாம் என்று systemd-க்குக் கட்டளையிடுகிறது; 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-க்கு பதிலாக ஒரு சாதாரண கணக்கின் மூலம் நிரலை இயக்குகிறது; பாதுகாப்பிற்காகச் சேர்க்கப்படும் மிக முக்கியமான வரி இதுவே. இங்கே Type= வரி இல்லாததால், systemd இயல்பாகவே simple-ஐப் பயன்படுத்துகிறது மற்றும் ExecStart process foreground-லேயே இருப்பதாகக் கருதுகிறது; பின்னணியில் (background) இயங்கும் ஒரு நிரலுக்கு அதன் தொடக்க முறைக்கு ஏற்ற Type= தேவைப்படுகிறது, இல்லையெனில் உண்மையான daemon செயலிழந்தாலும், unit file அது active நிலையில் இருப்பதாகக் காட்டும். 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 file-ஐயும் எழுதிய பிறகு அல்லது திருத்திய பிறகு, மாற்றங்களை systemd ஏற்றுக்கொள்வதற்காக அதை reload செய்யவும். பின், ஒரே கட்டளையில் சேவையை enable செய்து தொடங்கவும்:

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

daemon-reload என்பது பலரும் மறக்கும் ஒரு படிநிலை: systemd unit file-களை 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 எதையும் அமைக்கத் தேவையில்லை.

தோல்விக்குப் பிறகு மறுதொடக்கம் (Restart), இதற்காகவே நீங்கள் இங்கு வந்துள்ளீர்கள்

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

[Service]
Restart=on-failure
RestartSec=5

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

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

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

ஒரு privileged அல்லாத பயனராக இயக்குதல் மற்றும் பாதுகாப்பை பலப்படுத்துதல்

ஒரு service root பயனராக இயங்கும்போது, அந்த நிரல் ஏதேனும் ஒரு வகையில் ஊடுருவப்பட்டால், அது உங்கள் server-ல் எதை வேண்டுமானாலும் செய்ய முடியும். எனவே, அதை அதற்கென உருவாக்கப்பட்ட ஒரு தனி பயனராக இயக்கவும், மேலும் அதை கட்டுப்படுத்த systemd-ல் சில directives-களைச் சேர்க்கவும். முதலில், login வசதி மற்றும் home directory இல்லாத ஒரு system account-ஐ உருவாக்கவும்:

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 binary மூலமாகக்கூட அந்த process புதிய சலுகைகளைப் பெறுவதைத் தடுக்கிறது. PrivateTmp=true, மற்ற எந்த process-க்கும் தெரியாத ஒரு தனிப்பட்ட /tmp-ஐ வழங்குகிறது. ProtectSystem=strict, ReadWritePaths= மூலம் நீங்கள் குறிப்பிடும் சில பாதைகளைத் தவிர, முழு filesystem-ஐயும் read-only நிலைக்கு மாற்றுகிறது. ProtectHome=true, /home-ஐ அந்த நிரலுக்குத் தெரியாதவாறு முழுமையாக மறைக்கிறது. இது ஒரு service-ஐ firewall-க்கு பின்னால் வைக்கும் அதே "குறைந்தபட்ச சலுகை" (least-privilege) கொள்கையைச் சார்ந்தது: அதற்குத் தேவையானதை மட்டும் வழங்கவும். நீங்கள் VPS-ல் IPv6 firewall இடைவெளியை மூடுவது குறித்த வழிகாட்டியைப் படித்திருந்தால், இது அதே கருத்தின் host-அடிப்படையிலான பாதியாகும். இணையத்தை எதிர்கொள்ளும் ஒரு service-க்கு, இந்த பாதுகாப்பை SSH-க்கு முன்னால் Fail2ban மற்றும் default-deny firewall ஆகியவற்றுடன் இணைக்கவும்.

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

Timers: நவீன cron

ஒரு systemd timer என்பது ஒரு குறிப்பிட்ட கால அட்டவணையில் service-ஐ இயக்கும் கருவியாகும்; இது cron job-க்கு மாற்றாக நவீன முறையில் செயல்படுகிறது. ஒரு timer என்பது இரண்டு கோப்புகளைக் கொண்டது: பணியைச் செய்யும் ஒரு .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-க்கு உணர்த்துகிறது. 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 சரியாக உள்ளதா என்பதை உறுதிப்படுத்தி, அடுத்த முறை அது எப்போது இயங்கும் என்பதைக் காட்டும். அதிகாலை 3 மணிக்கு server அணைக்கப்பட்டிருந்தால், server மீண்டும் இயங்கத் தொடங்கியவுடன் விடுபட்ட பணியை Persistent=true இயக்கும்; இது cron-ல் சாத்தியமில்லை. timer-ஐ multi-user.target மூலம் அல்ல, timers.target மூலமே இயக்க வேண்டும் என்பதைக் கவனத்தில் கொள்க. service-ஐ அல்ல, timer-ஐ enable செய்யவும்:

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

list-timers அனைத்து timer-களையும், அவை கடைசியாக இயங்கிய மற்றும் அடுத்து இயங்கப்போகும் நேரத்துடன் காட்டும்; இதன் மூலம் உங்கள் பணி எப்போது இயங்கும் என்பதை ஒரே பார்வையில் அறியலாம். நீங்கள் timer mode-ஐ மாற்றும்போது, மேலே உள்ள generator உங்களுக்காக இணைக்கப்பட்ட .service மற்றும் .timer கோப்புகளை உருவாக்கும். cron வரியுடன் ஒப்பிடும்போது, timer உங்களுக்கு journal-ல் விரிவான logs-ஐ வழங்குகிறது, மற்ற service-களைப் போலவே இதற்கும் பாதுகாப்பு கட்டுப்பாடுகளை (hardening directives) விதிக்கலாம், மேலும் Persistent=true மூலம் விடுபட்ட பணிகளை ஈடுசெய்யலாம். எளிய பணிகளுக்கு cron போதுமானது; ஆனால் பணி முக்கியமானதாக இருக்கும்போது timer சிறந்த கருவியாகும்.

FAQ

systemd service மற்றும் cron job ஆகியவற்றிற்கு இடையே உள்ள வேறுபாடு என்ன?

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

எனது systemd service கோப்பை எங்கே வைக்க வேண்டும்?

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

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

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

ஒரு systemd service-ஐ root அல்லாத பயனராக எப்படி இயக்குவது?

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

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

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