systemd ஏன் வெற்றி பெற்றது? அதன் முழுமையான வரலாறு

systemd ஏன் வெற்றி பெற்றது

systemd-ன் வரலாறு SysV init-ஆல் செய்ய முடியாத இரண்டு விஷயங்களிலிருந்து தொடங்குகிறது. SysV init (System V init, இது AT&T Unix-லிருந்து Linux மரபுரிமையாகப் பெற்ற startup system) ஒரு service எதைச் சார்ந்து இயங்குகிறது என்பதை விவரிக்கவோ, அல்லது ஒரு service இயங்கத் தொடங்கிய பிறகு அதனுடன் தொடர்புடைய processes எவை என்பதைக் கண்டறியவோ வழிவகை செய்யவில்லை. systemd இந்த இரண்டு சிக்கல்களுக்கும் shell script-ஆல் அணுக முடியாத kernel வசதிகளைப் பயன்படுத்தித் தீர்வு கண்டது: processes-ஐக் கண்காணிக்க control groups மற்றும் service-களை வரிசைப்படுத்த pre-opened listening sockets. மீதமுள்ள வரலாறு, இந்த இரண்டு தீர்வுகளும் எவ்வாறு userland-ன் பிற பகுதிகளுக்குப் பரவின என்பதுதான்; அங்கிருந்துதான் எதிர்ப்புகள் தொடங்கின, அந்த எதிர்ப்புகளில் பல நியாயமானவை.

SysV init உண்மையில் என்ன செய்தது

SysV அமைப்பில், PID 1 (kernel தொடங்கும் முதல் process) /etc/inittab-ஐ வாசித்து, ஒரு runlevel-ஐத் தேர்ந்தெடுத்து, அந்த runlevel-க்கான scripts-ஐ இயக்கியது. இந்த scripts /etc/init.d/-ல் இருந்தன. /etc/rc3.d/-ல் உள்ள symbolic links எவை இயங்க வேண்டும், எந்த வரிசையில் இயங்க வேண்டும் என்பதைத் தீர்மானித்தன. எனவே, /etc/rc3.d/S20nginx என்பது /etc/init.d/nginx-ஐச் சுட்டிக்காட்டியது மற்றும் start என்ற argument-உடன் அழைக்கப்பட்டது.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

case "$1" in
  start)
    start-stop-daemon --start --quiet --pidfile /run/nginx.pid \
      --exec /usr/sbin/nginx
    ;;
  stop)
    start-stop-daemon --stop --quiet --retry TERM/30/KILL/5 \
      --pidfile /run/nginx.pid
    ;;
esac

S20nginx-ல் உள்ள 20 என்பது ஒரு வரிசைமுறை, dependency அல்ல. இந்த script S19-க்கு பிறகும், S21-க்கு முன்பும் இயங்கும் என்று அது கூறுகிறது. இது ஏன் என்று கூறாததால், எதையும் சரிபார்க்க முடியாது. மனிதர்கள் பாதுகாப்பானது என்று முடிவு செய்யாமல், தொடர்பில்லாத இரண்டு scripts-ஐ ஒரே நேரத்தில் பாதுகாப்பாக இயக்க முடியாது.

rc நிரல் ஒவ்வொரு script-ஆக வரிசையாக இயக்கி, அது முடியும் வரை காத்திருந்தது. network address-க்காக முப்பது வினாடிகள் காத்திருக்கும் ஒரு script, network-ஐப் பயன்படுத்தாத services-க்குக் கூட boot நேரத்தை முப்பது வினாடிகள் தாமதப்படுத்தியது.

அந்த script-ன் உச்சியில் இருந்த LSB (Linux Standard Base) header, இதை உள்ளிருந்தே சரிசெய்யும் ஒரு முயற்சியாகும். 2011-ல் Debian 6.0, insserv-ஐ default-ஆக்கியது: அது ஒவ்வொரு script-லிருந்தும் Required-Start-ஐ வாசித்து, ஒரு வரைபடத்தை (graph) உருவாக்கி, symlinks-க்கு மறுவரிசை அளித்தது. அதன் பிறகு, Debian-ஆல் startpar மூலம் சுதந்திரமான scripts-ஐ ஒரே நேரத்தில் இயக்க முடிந்தது. இது உதவியது, ஆனால் ஆழமான சிக்கலை இது தீர்க்கவில்லை. dependency என்பது இன்னும் ஒரு script முடிவடைவதையே சார்ந்திருந்தது. S20nginx என்பது 0-ஐத் திரும்ப அளிப்பது, ஒரு shell function வெற்றிகரமாக முடிந்தது என்பதையே குறிக்கிறது. nginx connections-ஐ ஏற்கத் தொடங்கிவிட்டது என்று அது அர்த்தமல்ல.

init script-களால் சரிசெய்ய முடியாத ஐந்து விஷயங்கள்

• இணையாகத் தொடங்குதல் (Parallel startup). கோப்புப் பெயர்களின் அடிப்படையில் வரிசைப்படுத்துவது, கணினியில் உள்ள அனைத்து service-களுக்கும் ஒரு முழுமையான வரிசையை உருவாக்குகிறது. இதனால், ஒவ்வொரு பகுதியின் நேரத்தையும் கூட்டி கணக்கிடும் அளவுக்கு boot செயல்முறை மெதுவாகிறது.
• தயார்நிலை (Readiness). ஒரு start script, daemon-ஐ fork செய்தவுடன் வெளியேறிவிடும்; ஆனால் அந்த daemon கோரிக்கைகளை ஏற்கத் தயாராக இருக்கும்போது அல்ல. எனவே, அடுத்த script பெரும்பாலும் மிக விரைவாகத் தொடங்குகிறது.
• கண்காணிப்பு (Supervision). ஒரு daemon இரண்டு முறை fork ஆகி, அதன் parent வெளியேறும்போது, அது terminal-லிருந்து துண்டிக்கப்பட்டு PID 1-ன் கீழ் மீண்டும் இணைகிறது. ஒரு child process வெளியேறுவதை init கவனிக்கிறது, ஆனால் எஞ்சியிருக்கும் process-க்கும் அதற்கும் நம்பகமான தொடர்பு இருப்பதில்லை.
• தேவைக்கேற்ப தொடங்குதல் (On-demand start). inetd (internet super-server) ஒரு இணைப்பு வரும்போது daemon-ஐத் தொடங்க முடியும். ஆனால், அது தனித்துவமான configuration கோப்பைக் கொண்ட ஒரு தனி அமைப்பாக இருந்தது; boot-ன் போது மற்ற அனைத்தையும் வரிசைப்படுத்துவதில் அது எந்தப் பங்களிப்பையும் செய்யவில்லை.
• வளக் கட்டுப்பாடு (Resource control). ஒரு service-ன் memory அல்லது CPU பங்கைக் கட்டுப்படுத்தும் வசதி init script-ல் இல்லை. ulimit ஒரு process-க்கு மட்டுமே பொருந்தும், nice scheduler-ஐ மட்டுமே பாதிக்கும். எனவே, ஒரு service-ன் கட்டுப்பாடற்ற child process, கணினியில் உள்ள மற்ற சாதாரண process-களைப் போலவே காட்சியளிக்கும்.

கண்காணிப்பு இடைவெளி (supervision gap) அன்றாட செயல்பாடுகளில் பெரும் பாதிப்பை ஏற்படுத்தியது. PID கோப்பு இதற்கு ஒரு தற்காலிக தீர்வாக இருந்தது: daemon தனது process ID-ஐ /run/nginx.pid-ல் எழுதும், stop function அந்த கோப்பைப் படித்துச் செயல்படும். daemon வலுக்கட்டாயமாக நிறுத்தப்பட்டால், அந்த கோப்பு அப்படியே தங்கிவிடும். kernel அந்த எண்ணை மீண்டும் வேறொரு பயன்பாட்டிற்கு ஒதுக்கும்போது, start-stop-daemon --stop --pidfile அந்த எண்ணிற்குச் சொந்தமான தவறான process-க்கு signal-ஐ அனுப்பும். ஒரு பழைய PID கோப்பு, init script தவறான process-ஐக் கொல்லும் நிலையை உருவாக்குகிறது.

launchd முதலில் socket சிக்கலைத் தீர்த்தது

Apple நிறுவனம் 2005-ல் Mac OS X 10.4 பதிப்பில் launchd-ஐ வெளியிட்டது; இதை Dave Zarzycki உருவாக்கினார். init, rc, xinetd, crond மற்றும் watchdogd ஆகிய அனைத்திற்கும் மாற்றாக ஒரே ஒரு process பயன்படுத்தப்பட்டது.

இதில் பின்பற்றத்தக்க முக்கியமான அம்சம் socket activation ஆகும். launchd முதலில் அனைத்து listening socket-களையும் உருவாக்கிவிட்டு, அதன் பிறகு daemons-ஐத் தொடங்குகிறது. இன்னும் தொடங்கப்படாத ஒரு daemon-க்கு ஒரு client இணைப்பை ஏற்படுத்த முயன்றால், அதற்கு connection refused என்ற பிழை வராது. ஏனெனில், daemon accept()-ஐ அழைக்கும் வரை, kernel அந்த இணைப்பை socket-ன் backlog queue-ல் வைத்திருக்கும். இதனால் இரண்டு daemons-க்கு இடையிலான வரிசைமுறை (ordering) குறித்த கவலை மனிதர்களுக்குத் தேவையில்லை. socket-களே இதைச் சரியாகக் கையாண்டுவிடும்.

launchd என்பது Apple-ன் XNU kernel-ல் உள்ள Mach IPC (inter-process communication)-ஐ அடிப்படையாகக் கொண்டது; இதற்கு Linux-ல் நேரடி இணையான வசதி இல்லை. எனவே, இந்த code-ஐ அப்படியே port செய்வது சாத்தியமற்றது. இருப்பினும், இந்த யோசனை பிற தளங்களுக்கும் பரவியது.

Upstart நிகழ்வுகளை (events) பணியின் அலகாகக் கொண்டது

Canonical நிறுவனத்தின் Upstart, Scott James Remnant என்பவரால் உருவாக்கப்பட்டது. இது அக்டோபர் 2006-ல் Ubuntu 6.10 பதிப்பில் வெளியிடப்பட்டது. Fedora 9 முதல் Fedora 14 வரையிலான பதிப்புகளிலும், RHEL 6 மற்றும் Chrome OS-லும் இது பயன்படுத்தப்பட்டது. இது runlevel-க்கு பதிலாக நிகழ்வுகளை (events) அறிமுகப்படுத்தியது. ஒரு job எந்த நிகழ்வுகளின் மூலம் தொடங்கப்பட வேண்டும் மற்றும் நிறுத்தப்பட வேண்டும் என்பதை வரையறுத்தது.

# /etc/init/example.conf
start on filesystem and net-device-up IFACE!=lo
stop on runlevel [!2345]
respawn
respawn limit 10 5
exec /usr/local/bin/exampled

பணிகளின் (jobs) எண்ணிக்கை அதிகரித்தபோது இரண்டு சிக்கல்கள் எழுந்தன. முதலாவது, திசை சார்ந்தது. ஒரு job "இந்த நிகழ்வு நடக்கும்போது என்னை தொடங்கு" என்று கூறுகிறது. எனவே, எதனுடன் எது சார்ந்துள்ளது (dependency) என்ற அறிவு தவறான கோப்பில் இருந்தது: ஒரு service-க்கு தனக்கு என்ன தேவை என்பது தெரியும், ஆனால் எதிர்காலத்தில் எந்த service-க்கு தான் தேவைப்படும் என்பது அதற்குத் தெரியாது. ஒரு புதிய service-ஐச் சேர்க்கும்போது, ஏற்கனவே உள்ள ஒரு job-ஐத் திருத்தி, அது ஒரு புதிய நிகழ்வை வெளியிடுமாறு (emit) செய்ய வேண்டியிருந்தது.

இரண்டாவது, கண்காணிப்பு சார்ந்தது. Upstart ஒரு forking daemon-ஐக் கண்காணிக்க, fork() அழைப்புகளை ptrace மூலம் எண்ணியது. இதை நீங்கள் expect fork அல்லது expect daemon என உள்ளமைக்க வேண்டும். fork-களின் எண்ணிக்கையைத் தவறாகக் கணித்தால், ஏற்கனவே வெளியேறிய ஒரு process-ஐ Upstart கண்காணிக்கும், அல்லது ஏற்கனவே நடந்து முடிந்த fork-க்காகக் காத்திருக்கும். இதன் அறிகுறியாக initctl start எந்தப் பிழையும் காட்டாமல் தொங்கிக்கொண்டிருக்கும் (hanging). இதை விளக்குவதற்கு job கோப்பில் எந்த வழியும் இல்லை.

மேலும், Upstart-ல் பங்களிப்பவர்கள் Canonical-ன் பங்களிப்பாளர் ஒப்பந்தத்தில் கையெழுத்திட வேண்டியிருந்தது. இது ஒரு பொறியியல் குறைபாடு அல்ல, ஆனால் இது யார் இதில் பணியாற்றினார்கள் என்பதைத் தீர்மானித்தது.

PID 1-ஐ மறுபரிசீலனை செய்தல், ஏப்ரல் 2010

30 ஏப்ரல் 2010 அன்று Lennart Poettering "Rethinking PID 1" என்ற தலைப்பில் ஒரு பதிவை வெளியிட்டார். Kay Sievers அவருடன் இணைந்து இந்தத் திட்டத்தில் பணியாற்றினார். அந்த வாதம் நான்கு பகுதிகளைக் கொண்டிருந்தது.

• குறைவாகத் தொடங்குதல். பல சேவைகள் தங்களுக்குத் தேவை ஏற்படும் வரை காத்திருக்க முடியும்.
• ஒரு socket மூலம் வரிசையைத் தீர்மானிக்க முடியும் என்றால், வரிசையை முன்கூட்டியே அறிவிப்பதைத் தவிர்த்தல். அனைத்து socket-களையும் ஒரே கட்டத்தில் திறந்துவிட்டு, பின் அனைத்தையும் ஒரே நேரத்தில் தொடங்குதல்.
• PID கோப்புகளுக்குப் பதிலாக control groups மூலம் செயல்முறைகளைக் (processes) கண்காணித்தல்.
• ஒரு சேவையை declarative கோப்பில் விவரித்தல், இதன் மூலம் ஒரு விளக்கம் அனைத்து விநியோகங்களிலும் (distributions) செயல்படும்.

அந்த ஆண்டிலேயே முதல் release வெளியானது. நவம்பர் 2010-ல் Fedora 14 ஒரு விருப்பத்தேர்வாக systemd-ஐ வழங்கியது, மே 2011-ல் Fedora 15 அதை இயல்பான (default) அமைப்பாக மாற்றியது.

cgroups ஏன் கண்காணிப்பை நம்பகமானதாக மாற்றியது

cgroup (control group) என்பது செயல்முறைகளை (processes) குழுவாக்குவதற்கான ஒரு kernel வசதியாகும். இது 2008-ல் Linux 2.6.24 பதிப்பில் இணைக்கப்பட்டது. systemd ஒவ்வொரு service-ஐயும் அதன் சொந்த cgroup-ல் வைக்கிறது. ஒரு child process அதன் parent-ன் cgroup-ஐ அப்படியே பெறுகிறது; ஒரு unprivileged process தன்னைத்தானே அந்த குழுவிலிருந்து வெளியேற்றிக்கொள்ள முடியாது. எனவே, double forking மூலம் எதையும் மறைக்க முடியாது: PID 1 எப்போதும் ஒரு unit-க்கு சொந்தமான அனைத்து செயல்முறைகளையும் துல்லியமாக வைத்திருக்கும். ஒரு service-ஐ நிறுத்துவது என்பது அதன் cgroup-ல் உள்ள அனைத்தையும் அழிப்பதாகும், இதுவே இயல்பான KillMode=control-group செய்யும் செயலாகும்.

systemctl status அந்த குழுவை அச்சிடுகிறது:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-08-11 09:14:22 UTC; 3min ago
   Main PID: 1042 (nginx)
      Tasks: 3 (limit: 4653)
     Memory: 6.1M (peak: 7.4M)
     CGroup: /system.slice/nginx.service
             ├─1042 "nginx: master process /usr/sbin/nginx"
             ├─1043 "nginx: worker process"
             └─1044 "nginx: worker process"

அந்த block-தான் stale PID file பிரச்சினைக்கான முழுமையான தீர்வாகும். இங்கே stale ஆகக்கூடிய கோப்பு எதுவும் இல்லை, ஏனெனில் அந்த பட்டியல் kernel-ன் நிலையாகும் (kernel state).

அதே மர அமைப்பில் வரம்புகளையும் (limits) அமைக்க முடியும், ஏனெனில் cgroups முதலில் கண்காணிப்பிற்காகப் பயன்படுத்தப்படுவதற்கு முன்பே கணக்கீட்டிற்காகவே (accounting) உருவாக்கப்பட்டன. MemoryMax=, CPUQuota= மற்றும் TasksMax= ஆகியவை தலா ஒரு வரியைக் கொண்டவை. ஒரு service-க்கு கடினமான memory மற்றும் CPU வரம்பை அமைப்பது இன்று ஒரு drop-in கோப்பு மூலம் எளிதாகிறது, ஆனால் 2009-ல் இது யாரும் எழுதாத ஒரு shell script patch-ஆக இருந்தது.

ஏன் அனைத்து விநியோகங்களும் 2011 மற்றும் 2015-க்கு இடையில் மாறின

• Fedora 15, மே 2011.
• openSUSE 12.1, நவம்பர் 2011.
• Mageia 2, மே 2012.
• Arch Linux, அக்டோபர் 2012 முதல் புதிய நிறுவல்களுக்கான இயல்புநிலை.
• RHEL 7, ஜூன் 2014.
• SLES 12, அக்டோபர் 2014.
• Debian 8, ஏப்ரல் 2015.
• Ubuntu 15.04, ஏப்ரல் 2015.

இதற்கான காரணங்கள் பெரும்பாலும் சலிப்பானவை, அதனால்தான் இந்த மாற்றம் விரைவாக நடந்தது.

• ஒரே unit file அனைத்து விநியோகங்களிலும் வேலை செய்கிறது. எனவே, upstream திட்டங்கள் ஒரு .service கோப்பை வழங்கத் தொடங்கின, மேலும் விநியோகங்கள் ஒவ்வொரு தொகுப்பிற்கும் ஒவ்வொரு வெளியீட்டிற்கும் தனித்தனி shell script-களை பராமரிப்பதை நிறுத்தின.
• 2012 வாக்கில் ConsoleKit பராமரிக்கப்படாமல் போனதால், desktop session tracking systemd-logind-க்கு மாறியது. GNOME-க்கு logind தேவைப்பட்டது, எனவே systemd இல்லாத விநியோகம் அதற்கு மாற்றீட்டைக் கண்டறிய வேண்டியிருந்தது. அந்த மாற்றீடான elogind, systemd-ன் logind-ஐ தனியாகப் பிரித்து பராமரிக்கப்படும் ஒரு பதிப்பாகும்.
• device manager-ஆன udev, ஏப்ரல் 2012-ல் systemd source tree-க்குள் இணைக்கப்பட்டது. udev-ஐ வழங்கும் விநியோகங்கள் இப்போது systemd-ன் repository-ஐப் பின்தொடர்கின்றன. இதற்குப் பதிலாக Gentoo eudev-ஐ fork செய்தது.
• Containers தொழில்நுட்பம், நம்பகமான process tracking மற்றும் ஒவ்வொரு service-க்கும் தனித்தனி வரம்புகளை (limits) முக்கியமாக்கியது. இவை இரண்டுமே cgroup அம்சங்களாகும். ஒரு container process-ஐ எந்த supervisor நிர்வகிக்கிறது என்ற கேள்வி, நீங்கள் reboot-க்குப் பிறகு Docker Compose stack-ஐ மீண்டும் இயக்கும்போது இன்றும் எழுகிறது.

Debian-ன் முடிவு சத்தமாக விவாதிக்கப்பட்டது. பிப்ரவரி 2014-ல் தொழில்நுட்பக் குழு (Technical Committee) வாக்களித்தது, வாக்குகள் சமமாக இருந்தன, தலைவர் Bdale Garbee, systemd-க்கு ஆதரவாகத் தீர்க்கமான வாக்கை அளித்தார். Ubuntu, Upstart-ஐத் தொடர்வதற்குப் பதிலாக Debian-ஐப் பின்பற்றுவதாகச் சில நாட்களில் அறிவித்தது. Debian உருவாக்குநர்களின் ஒரு குழு, நவம்பர் 2014-ல் Devuan என்ற பெயரில் விநியோகத்தைப் பிரித்தது (fork) மற்றும் மே 2017-ல் Devuan 1.0-ஐ வெளியிட்டது.

எதிர்ப்புகள், நியாயமான முறையில்

Scope. தற்போது ஒரு project-ஆனது PID 1, logging daemon, login session management, device manager, network configuration daemon, DNS (domain name system) resolver, NTP (network time protocol) client, container runner மற்றும் boot loader ஆகியவற்றை வழங்குகிறது. இவை தனித்தனி binaries என்பதால் நீங்கள் அனைத்தையும் நிறுவ வேண்டியதில்லை என்ற வழக்கமான வாதம் உண்மையானதுதான், ஆனால் அது எதிர்ப்புக்குப் பதிலளிக்கவில்லை. ஒரு desktop-க்கு logind தேவைப்படும்போது, அது systemd-ன் tree-லிருந்து பிரிக்கப்பட்டால், தேர்வு சுதந்திரமாக இருக்காது. விவாதத்தில் "coupling" என்று குறிப்பிடப்பட்டது இதுதான், அது நிகழ்ந்துவிட்டது.

The binary journal. journald சாதாரண உரைக்கு (plain text) பதிலாக indexed binary format-ல் பதிவுகளை எழுதுகிறது. உரையால் வழங்க முடியாத வசதிகள் இதில் கிடைக்கின்றன: unit மற்றும் priority வாரியாக filtering, structured fields, மற்றும் அனுப்பும் program-ஆல் மாற்ற முடியாத metadata. ஏனெனில் journald-ஆனது unit மற்றும் cgroup-ஐத் தானே பதிவு செய்கிறது. journalctl -u nginx -p err --since "-1h" ஒரு date regular expression-ஐப் பயன்படுத்தி grep செய்வதை மாற்றுகிறது. இதற்கான விலையும் உண்டு. கணினி boot ஆகாதபோது, rescue shell-லிருந்து less மூலம் log-ஐப் படிக்க முடியாது. அதற்குப் பதிலாக, mounted disk-ஐ நோக்கி journalctl-ஐ இயக்க வேண்டும்:

sudo journalctl --directory /mnt/var/log/journal --boot -1 --priority err

இங்கே ஒரு இரண்டாவது சிக்கல் உள்ளது, இது பலரை ஒருமுறை பாதிக்கும். /var/log/journal இல்லையெனில், journald பதிவுகளை /run/log/journal-ல் (memory) வைத்திருக்கும். அது இல்லாத கணினியில், reboot செய்த பிறகு journalctl -b -1-ல் காண்பிக்க எதுவும் இருக்காது; அந்தத் தருணத்தில்தான் உங்களுக்கு அது தேவைப்படும். இதைச் சரிபார்க்கவும் சரிசெய்யவும்:

journalctl --disk-usage
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

journalctl --disk-usage இப்போது /var/log/journal-ன் கீழ் உள்ள archived journals-ஐக் காட்ட வேண்டும். உங்களுக்கு plain text-ம் தேவைப்பட்டால், /etc/systemd/journald.conf-ல் ForwardToSyslog=yes-ஐ set செய்து, rsyslog-ஐ நிறுவி வைத்திருக்கவும்.

Debuggability of the boot. ஒரு unit முடங்கும்போது, console-ல் ஒரே ஒரு வரி மட்டுமே தெரியும்:

[  *** ] A start job is running for Wait for Network to be Configured (1min 32s / no limit)

மேலும் ஆராய்வதற்கான கருவிகள் உள்ளன: அது முடங்கியிருக்கும்போது systemctl list-jobs, அதற்குப் பிறகு systemd-analyze blame மற்றும் systemd-analyze critical-chain, மற்றும் kernel command line-ல் systemd.log_level=debug. இந்த புகாரின் நியாயமான அம்சம் என்னவென்றால், sh தெரிந்த எவராலும் ஒரு init script-ஐ மேலிருந்து கீழாகப் படித்துப் புரிந்துகொள்ள முடியும், ஆனால் முடங்கிய unit-ஐச் சரிசெய்ய டஜன் கணக்கான கட்டளைகளில் எதைப் பயன்படுத்த வேண்டும் என்று தெரிந்திருக்க வேண்டும். இது ஒரு உண்மையான செலவு. ஒவ்வொரு நிர்வாகியும் இதை ஒருமுறை கற்றுக்கொள்ள வேண்டும், பல நிர்வாகிகள் ஒரே நேரத்தில் இதைக் கற்றுக்கொண்டனர்.

அனைவருக்கும் மாறும் default. 2016-ல் systemd 230, logind-ன் default-ஐ மாற்றியது, இதனால் logout செய்யும்போது மீதமுள்ள user processes கொல்லப்பட்டன. detached tmux மற்றும் screen sessions, அவற்றை ஆரம்பித்த session முடிந்தவுடன் அழிந்தன. Distributions /etc/systemd/logind.conf-ல் KillUserProcesses=no-ஐ வழங்கின, இதற்கான ஆதரவு அளிக்கப்பட்ட பதில் loginctl enable-linger <user> ஆகும். ஒரு project-ல் உள்ள ஒரு default, மில்லியன் கணக்கான மக்கள் நம்பியிருந்த ஒரு பழக்கத்தை மாற்றியது. நடைமுறையில் "userland-ன் அதிகப்படியான பகுதிகள் ஒரே இடத்தில் இருப்பது" என்பதன் அர்த்தம் இதுதான்.

Default dependency ஒரு security surface. மார்ச் 2024-ல், xz-utils-ல் இருந்த backdoor, Debian மற்றும் Ubuntu-வில் உள்ள sshd-ஐக் குறிவைத்தது. Upstream OpenSSH, libsystemd-ஐ இணைப்பதில்லை (link). அந்த distributions, sshd-ஆனது systemd-க்குத் தனது தயார்நிலையைத் தெரிவிக்க வேண்டும் என்பதற்காக அதை patch செய்தன. libsystemd, liblzma-வை உள்ளிழுத்தது, அங்குதான் backdoor இருந்தது. தயார்நிலை protocol என்பது $NOTIFY_SOCKET-ல் குறிப்பிடப்பட்ட socket-க்கு அனுப்பப்படும் ஒரு ஒற்றை datagram மட்டுமே, எனவே அதற்கு எந்த library-யும் தேவையில்லை. systemd-ன் பதில், compression libraries-ஐ dlopen மூலம் load செய்வதுதான், எனவே அவை இனி default-ஆக இணைக்கப்படுவதில்லை. இது போன்ற ஒரு வகை bug இதே வடிவத்தைக் காட்டுகிறது: 2017-ல், இலக்கத்துடன் தொடங்கும் User= மதிப்பு தவறானது எனக் கருதப்பட்டு, unit தோல்வியடைவதற்குப் பதிலாக root-ஆக இயங்கியது. இதனால் ஒரு தட்டச்சுப் பிழை (typo) privilege escalation-ஆக மாறியது. பிந்தைய பதிப்புகள் அந்த unit-ஐத் தொடங்க மறுக்கின்றன.

உங்கள் systemctl prompt-ல் வரலாறு

மேலே உள்ள ஒவ்வொரு சிக்கலும் இப்போது நீங்கள் வாசிக்கக்கூடிய ஒரு கோப்பில் உள்ள கட்டளையாக மாறியுள்ளது.

• Serial boot என்பது After= மற்றும் Wants= ஆக மாறியுள்ளது, மேலும் உங்கள் boot-ஐ உண்மையில் எது தடுத்தது என்பதை systemd-analyze critical-chain காட்டுகிறது.
• Readiness என்பது Type=notify ஆக மாறியுள்ளது; இதில் service தயாரானதும் READY=1 என்பதை $NOTIFY_SOCKET-க்கு எழுதும். பழைய daemons-களுக்காக Type=forking உடன் PIDFile= இன்னும் உள்ளது, PID file உருவாகாதபோது start operation timed out. Terminating. பிழையுடன் தோல்வியடையும் வகை இதுதான்.
• Supervision என்பது cgroup ஆக மாறியுள்ளது, எனவே Restart=on-failure உடன் RestartSec= ஒரு wrapper script-க்கு மாற்றாக அமைகிறது, மேலும் StartLimitBurst= ஒரு crash loop தொடர்ந்து இயங்குவதைத் தடுக்கிறது.
• inetd என்பது .service unit-க்கு அருகில் இருக்கும் ஒரு .socket unit ஆக மாறியுள்ளது.
• ulimit என்பது MemoryMax=, CPUQuota= மற்றும் TasksMax= ஆக மாறியுள்ளது.
• Init script-ல் இருந்த su - appuser -c வரி இப்போது User=, NoNewPrivileges=yes மற்றும் ProtectSystem=strict ஆக மாறியுள்ளது, எனவே ஒரு service-ஐ unprivileged user-ஆக இயக்குவது என்பது கூடுதல் வேலை அல்ல, அதுவே unit-ன் இயல்பான வடிவமாகும்.

[Unit]
Description=Example API
Wants=network-online.target
After=network-online.target postgresql.service
Requires=postgresql.service

[Service]
Type=notify
ExecStart=/usr/local/bin/exampled
Restart=on-failure
RestartSec=2
MemoryMax=512M
CPUQuota=50%
TasksMax=128
User=exampled
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
StateDirectory=exampled

[Install]
WantedBy=multi-user.target

அந்தக் கோப்பில் உள்ள ஒரு வரிதான் அனைவரும் ஒருமுறை செய்யும் தவறு. After=postgresql.service இல்லாமல், இரண்டும் ஒரே நேரத்தில் தொடங்க முயற்சிக்கும், இதனால் எவ்வித சேவையும் இயங்காத port-ல் உங்கள் service இணைய முயலும். Requires=postgresql.service என்பது ஒரு தேவை (requirement), அது வரிசைப்படுத்துதல் (ordering) அல்ல: Postgres தோல்வியடைந்தால் உங்கள் unit-ம் தோல்வியடையும் என்று அது கூறுகிறது, ஆனால் Postgres-ஐ முதலில் தொடங்கு என்று அது கூறவில்லை. இவை இரண்டும் வேண்டுமென்றே தனித்தனியாக வைக்கப்பட்டுள்ளன, ஏனெனில் சில நேரங்களில் உங்களுக்கு ஒன்று மட்டும் தேவைப்படலாம். ProtectSystem=strict இந்த service-க்காக filesystem-ஐ read-only ஆக மாற்றுகிறது, அதனால்தான் StateDirectory= அங்கு உள்ளது: இது /var/lib-ன் கீழ் service-க்கு ஒரு writable path-ஐ வழங்குகிறது.

2026 server-ல் 2005-ன் தொழில்நுட்பத்தைப் பார்க்க சிறந்த இடம் Ubuntu 24.04-ல் உள்ள SSH ஆகும், இது ஆகஸ்ட் 2026 நிலவரப்படி systemd 255-ஐக் கொண்டுள்ளது. ssh.service இயல்பாகவே socket activated ஆக உள்ளது: ssh.socket listening socket-ஐ வைத்திருக்கிறது, ஒரு இணைப்பு வரும்போது sshd தொடங்குகிறது. எனவே /etc/ssh/sshd_config-ல் உள்ள Port 2222 எந்த விளைவையும் ஏற்படுத்தாது, ஏனெனில் port-ஐத் திறந்த process sshd அல்ல. இந்த மாற்றம் socket unit-ல் செய்யப்பட வேண்டும்.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

வெற்று ListenStream=, packaged unit-லிருந்து பெறப்பட்ட மதிப்பை நீக்குகிறது. இதைத் தவிர்த்தால், systemd பட்டியலை மாற்றாமல் அதற்குப் பின்னால் சேர்ப்பதால், உங்களுக்கு இரண்டு port-களும் கிடைக்கும். பிறகு, இரண்டாவது SSH session-ஐத் திறந்து வைத்துக்கொண்டு, மாற்றங்களைச் செய்து சரிபார்க்கவும்:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -lntp | grep 2222

ss, sshd-க்கு பதிலாக systemd-க்கு சொந்தமான port 2222-ல் ஒரு socket-ஐக் காட்ட வேண்டும். இதுதான் இருபது ஆண்டுகளுக்குப் பிறகு உங்கள் VPS-ல் உள்ள launchd வடிவமைப்பு. நீங்கள் பழைய முறையை விரும்பினால், sudo systemctl disable --now ssh.socket-ஐத் தொடர்ந்து sudo systemctl enable --now ssh.service-ஐப் பயன்படுத்தினால், அது தனது சொந்த config-லிருந்து Port-ஐ வாசிக்கும் நீண்டகாலமாக இயங்கும் sshd-ஐ உங்களுக்கு வழங்கும்.

இந்த விவரங்களில் எவை உங்களுக்குப் பொருந்தும் என்பது நீங்கள் பயன்படுத்தும் release-ஐப் பொறுத்தது, எனவே ஒரு upgrade-ஐத் திட்டமிடுவதற்கு முன் LTS மற்றும் interim Ubuntu release-க்கு இடையிலான வேறுபாட்டை அறிந்துகொள்வது அவசியம். ஒன்றுக்கும் மேற்பட்ட இயந்திரங்களில், unit file எல்லா இடங்களிலும் ஒரே மாதிரியாக இருப்பதுதான், பல server-களை ஒரே இடத்திலிருந்து நிர்வகிப்பதை இப்போது ஒரு shell scripting சிக்கலாக இல்லாமல், ஒரு configuration சிக்கலாக மாற்றியுள்ளது. நீங்கள் சொந்தமாக unit-களை எழுதும்போது, service மற்றும் timer ஜோடி, 2009-ல் init script மற்றும் cron வரிக்கு இடையே நீங்கள் பிரித்துச் செய்த வேலையைச் சிறப்பாகச் செய்கிறது.

FAQ

Linux distributions ஏன் SysV init-க்கு பதிலாக systemd-ஐ மாற்றின?

இரண்டு பொறியியல் காரணங்கள் மற்றும் ஒரு பராமரிப்பு காரணத்திற்காக இது நடந்தது. SysV init சேவைகளை கோப்புப் பெயரின் வரிசைப்படி (filename) மட்டுமே கையாண்டது, இது சார்புநிலையை (dependency) விட இட அமைப்பையே அடிப்படையாகக் கொண்டது. மேலும், ஒரு daemon அதன் parent-லிருந்து பிரிந்து (fork) செல்லும்போது, அதைத் தொடர்ந்து கண்காணிக்கும் திறன் அதற்கு இல்லை; இதனால் தவறான PID கோப்புகள் மூலம் தவறான process-ஐ நிறுத்தும் அபாயம் இருந்தது. systemd, socket activation மற்றும் dependency directives மூலம் வரிசைப்படுத்தும் சிக்கலைத் தீர்த்தது; control groups மூலம் process கண்காணிப்பைச் சரிசெய்தது. பராமரிப்பு காரணம் வேகத்தை அடிப்படையாகக் கொண்டது: ஒரு unit file அனைத்து distribution-களிலும் வேலை செய்யும். எனவே, upstream திட்டங்கள் ஒரு .service கோப்பை வழங்கின, distribution பராமரிப்பாளர்கள் ஒவ்வொரு தொகுப்பிற்கும் தனித்தனியாக shell script எழுதும் வேலையை நிறுத்தினர். Fedora 15 மே 2011-ல் மாறியது, Ubuntu 15.04 ஏப்ரல் 2015-ல் மாறிய கடைசி பெரிய distribution ஆகும்.

systemd என்பது ஒரே ஒரு பிரம்மாண்டமான binary-யா?

இல்லை. இதன் source tree பல தனித்தனி நிரல்களை உருவாக்குகிறது. PID 1 என்பது /usr/lib/systemd/systemd ஆகும். அதேசமயம் journald, logind மற்றும் udevd ஆகியவை தனித்தனி binaries-ஐக் கொண்ட தனித்தனி process-கள் ஆகும்; உங்கள் கணினியில் அவற்றைப் பார்க்க ls /usr/lib/systemd/ கட்டளையை இயக்கவும். binary அளவை விட, release coupling பற்றிய விமர்சனமே இன்றும் உள்ளது: இந்த நிரல்கள் ஒன்றாகவே வெளியிடப்படுகின்றன மற்றும் தனிப்பட்ட interfaces-ஐப் பகிர்ந்து கொள்கின்றன. எனவே, distribution-கள் இவற்றை ஒரு தொகுப்பாகவே எடுத்துக்கொள்கின்றன, மேலும் GNOME போன்ற மென்பொருள்கள் logind-ஐ பிரத்யேகமாக எதிர்பார்க்கின்றன.

systemd இல்லாமல் என்னால் Linux-ஐ இயக்க முடியுமா?

ஆம். Devuan sysvinit-ஐ வழங்குகிறது, Gentoo இயல்பாக OpenRC-ஐப் பயன்படுத்துகிறது, Void runit-ஐப் பயன்படுத்துகிறது, Alpine busybox init மற்றும் OpenRC-ஐப் பயன்படுத்துகிறது, மேலும் Slackware BSD பாணி scripts-ஐத் தொடர்கிறது. இதற்கான விலை, இணக்கத்தன்மைக்கான (compatibility) கூடுதல் உழைப்புதான். logind-ஐ எதிர்பார்க்கும் Desktop மென்பொருள்களுக்கு elogind தேவைப்படுகிறது; இது systemd-ன் logind-ஐத் தனித்தனி தொகுப்பாகப் பராமரிக்கும் ஒரு திட்டமாகும். மேலும், பல server மென்பொருள்கள் இப்போது .service கோப்பை மட்டுமே வழங்குகின்றன, எனவே நீங்கள் startup script-ஐ நீங்களே எழுதி பராமரிக்க வேண்டியிருக்கும்.

journal ஏன் plain text கோப்பாக இல்லாமல் binary-ஆக உள்ளது?

ஏனெனில் journald, குறியீட்டுடன் (index) கூடிய கட்டமைக்கப்பட்ட புலங்களைச் சேமிக்கிறது. இது unit வாரியான வடிகட்டுதல், முன்னுரிமை வாரியான வடிகட்டுதல் மற்றும் அனுப்பும் நிரலால் மாற்ற முடியாத metadata-வை வழங்குகிறது: log வரியை நம்புவதற்குப் பதிலாக, journald அந்த unit, cgroup மற்றும் உண்மையான UID ஆகியவற்றைத் தானே பதிவு செய்கிறது. இதற்கான விலை, நீங்கள் அதை வாசிக்க journalctl-ஐப் பயன்படுத்த வேண்டும் என்பதுதான். rescue system-ல் கூட, journalctl --directory /mnt/var/log/journal மூலம் mounted disk-ஐக் குறிப்பிட்டு இதைப் பார்க்கலாம். உங்களுக்கு text வடிவம் வேண்டுமென்றால், /etc/systemd/journald.conf-ல் ForwardToSyslog=yes-ஐ அமைக்கவும்.

எனது /etc/init.d script-ஐத் திருத்துவதற்குப் பதிலாக எது வந்துள்ளது?

Drop-in கோப்புகள். /usr/lib/systemd/system/-ல் உள்ள unit-ஐத் திருத்த வேண்டாம், ஏனெனில் தொகுப்பு மேம்படுத்தப்படும்போது (package upgrade) அது மேலெழுதப்படும் (overwrite). sudo systemctl edit nginx.service கட்டளையை இயக்கினால், systemd /etc/systemd/system/nginx.service.d/override.conf-ஐ உருவாக்கும்; இது தொகுக்கப்பட்ட unit-ன் மேல் இணைக்கப்படும். systemctl cat nginx.service இணைக்கப்பட்ட முடிவைக் காட்டும், மேலும் systemd-delta கணினியில் உள்ள அனைத்து மாற்றங்களையும் (override) பட்டியலிடும். கைமுறையாக ஏதேனும் திருத்தம் செய்த பிறகு, sudo systemctl daemon-reload கட்டளையை இயக்கவும், இல்லையெனில் அடுத்த கட்டளை Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk.-ஐக் காட்டும்.