हर डेवलपर को जानने चाहिए ये Linux System APIs

1969 में, Ken Thompson और Dennis Ritchie ने Bell Labs के एक दफ़्तर में बैठकर कुछ ऐसे design फ़ैसले लिए जो उस दौर की लगभग हर दूसरी टेक्नोलॉजी से ज़्यादा टिके रहे। जिस PDP-7 पर उन्होंने Unix लिखा था, वह आज म्यूज़ियम की चीज़ है। जिन भाषाओं से उन्होंने शुरुआत की थी, वे लगभग विलुप्त हो चुकी हैं। लेकिन उन्होंने जो system call interface डिज़ाइन किया, यानी open, read, write, close, fork, exec, वही आज भी हर Linux सर्वर, हर Android फ़ोन और production में चल रहे हर container की नींव है।

ज़्यादातर डेवलपर इन APIs से मोटी-मोटी abstraction की परतों के ज़रिए मिलते हैं। Python का open(), Node का fs.readFile(), Go का os.Open(), ये सब आख़िर में नीचे एक ही kernel syscalls को कॉल करते हैं। इन syscalls को समझना सिर्फ़ जिज्ञासा शांत करने के लिए नहीं है। इससे आप debugging, performance tuning और ऐसे systems डिज़ाइन करने में सचमुच बेहतर बनते हैं जो दबाव में भी ठीक से काम करें।

File Descriptors: सब कुछ एक नंबर है

Unix की सबसे अहम abstraction file descriptor है। यह बस एक integer है, यानी एक छोटा, गैर-ऋणात्मक नंबर जो किसी खुले resource की ओर इशारा करता है। लेकिन यहाँ "resource" जान-बूझकर अस्पष्ट रखा गया है। एक file descriptor disk की फ़ाइल, network socket, processes के बीच की pipe, terminal, timer, या किसी signaling mechanism की ओर भी इशारा कर सकता है। Kernel को इससे फ़र्क नहीं पड़ता। आपके program के लिए ये सब बस ऐसे नंबर हैं जिनसे आप read() कर सकते हैं और जिनमें write() कर सकते हैं।

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main() {
// fd 0 = stdin, 1 = stdout, 2 = stderr (always)
// open() returns the next available fd, typically 3
int fd = open("data.txt", O_RDONLY);
if (fd == -1) {
perror("open");
return 1;
}
char buf[1024];
ssize_t n;
// read() works the same whether fd is a file,
// a socket, a pipe, or a device
while ((n = read(fd, buf, sizeof(buf))) > 0) {
write(STDOUT_FILENO, buf, n);
}
close(fd);
return 0;
}

यही डिज़ाइन Unix को composable बनाता है। चूँकि सब कुछ एक ही interface साझा करता है, आप फ़ाइल का output socket पर भेज सकते हैं, एक program का stdout दूसरे के stdin में pipe कर सकते हैं, या किसी process के stderr को log फ़ाइल से बदल सकते हैं, और programs को इसकी खबर तक नहीं होती। Shell pipelines इसी वजह से काम करती हैं, और Docker जैसे tools container का output इतनी आसानी से इसी वजह से पकड़ पाते हैं।

जब production में आपको "too many open files" error मिलता है, तो आप file descriptor की सीमा से टकरा रहे होते हैं। जब आप socket leak debug करते हैं, तो आप ऐसे file descriptors खोज रहे होते हैं जो खुले तो गए पर कभी बंद नहीं हुए। जब lsof बताता है कि कोई process क्या कर रही है, तो वह असल में file descriptors की सूची दिखा रहा होता है। इस abstraction को समझने से समस्याओं की एक पूरी श्रेणी अचानक साफ़ दिखने लगती है।

Fork और Exec: processes कैसे जन्म लेते हैं

Unix नए processes बनाने का तरीका ज़्यादातर लोगों को पहली बार देखने पर अजीब लगता है। "यह program लेकर process बनाओ" जैसी एक single call की जगह, Unix इसे दो चरणों में बाँटता है: fork() मौजूदा process की copy बनाता है, और exec() उस copy के program को किसी दूसरे program से बदल देता है। यह घुमावदार लगता है, लेकिन यही अलगाव पूरे Unix process model को संभव बनाता है।

#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>
#include <fcntl.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
// Child process: redirect stdout to a file
// This happens BETWEEN fork and exec —
// that's the whole point of the split
int fd = open("output.log", O_WRONLY | O_CREAT | O_TRUNC, 0644);
dup2(fd, STDOUT_FILENO);  // stdout now goes to the file
close(fd);
// Replace this process with 'ls'
execlp("ls", "ls", "-la", NULL);
// If we get here, exec failed
perror("exec");
return 1;
}
// Parent: wait for child to finish
int status;
waitpid(pid, &status, 0);
printf("Child exited with status %d\n",
WEXITSTATUS(status));
return 0;
}

fork() और exec() के बीच का अंतराल ही असली जादू है। उस बीच के समय में child process file descriptors को redirect कर सकता है, environment variables बदल सकता है, resource limits तय कर सकता है, privileges कम कर सकता है, या किसी अलग namespace से जुड़ सकता है, और यह सब नया program चलने से पहले होता है। आपकी shell ls > output.txt ठीक इसी तरह लागू करती है। Containers अपनी isolation इसी तरह सेट करते हैं। sudo इसी तरह privileges गिराता है।

आधुनिक Linux clone() भी देता है (parent और child के बीच क्या साझा हो, इस पर बारीक नियंत्रण के लिए), posix_spawn() (आम fork+exec पैटर्न के लिए, बिना अतिरिक्त overhead के), और vfork() (ज़्यादातर ऐतिहासिक optimization)। लेकिन मूल mental model अब भी fork+exec ही है। Linux का हर process manager, init system और container runtime इस पैटर्न के किसी न किसी रूप का इस्तेमाल करता है।

Signals: Kernel का interrupt सिस्टम

Signals Unix का asynchronous notification का तरीका है। जब आप Ctrl+C दबाते हैं, तो kernel foreground process को SIGINT भेजता है। जब आप kill चलाते हैं, तो आप एक signal भेज रहे होते हैं। जब कोई child process खत्म होता है, तो parent को SIGCHLD मिलता है। ये असल में software interrupts हैं: आपका code जो कर रहा है उसे रोकता है, signal handler चलाता है, और फिर वहीं से आगे बढ़ जाता है।

पेच यह है कि signal handlers एक अजीब context में चलते हैं। Signal handler से ज़्यादातर library functions को सुरक्षित रूप से कॉल नहीं किया जा सकता, क्योंकि वे reentrant नहीं हो सकते। malloc(), printf(), और जो भी lock लेता है, वे सब वर्जित हैं। सुरक्षित तरीका यह है कि handler में एक flag सेट करें और उसे अपने main loop में जाँचें:

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
static volatile sig_atomic_t shutdown_requested = 0;
void handle_sigterm(int sig) {
// Only set a flag — don't do real work here
shutdown_requested = 1;
}
int main() {
struct sigaction sa = {0};
sa.sa_handler = handle_sigterm;
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
printf("Server running (PID %d)...\n", getpid());
while (!shutdown_requested) {
// Do actual work here
sleep(1);
}
printf("Graceful shutdown complete.\n");
return 0;
}

यह पैटर्न, यानी graceful shutdown के लिए SIGTERM को हैंडल करना, container में चलने वाले हर process के लिए ज़रूरी है। Kubernetes pod को मारने से पहले SIGTERM भेजता है। Systemd किसी service को रोकने से पहले SIGTERM भेजता है। अगर आपका application इसे हैंडल नहीं करता, तो timeout के बाद उसे सख़्ती से मार दिया जाता है, जिसका मतलब है टूटे connections, अधूरे writes और data corruption। मैंने ऐसे production outages देखे हैं जो सिर्फ़ इसलिए हुए क्योंकि applications SIGTERM को नज़रअंदाज़ करते थे और routine deployments के दौरान बेरहमी से मारे गए।

Sockets: नेटवर्क एक file descriptor के रूप में

1983 में 4.2BSD में आया Berkeley sockets API एक और ऐसा डिज़ाइन है जो आज भी दुनिया चला रहा है। हर TCP connection, हर UDP packet, और आपकी की गई हर HTTP request आख़िरकार इसी API से होकर जाती है। और चूँकि sockets file descriptors हैं, वे उन्हीं सारे tools के साथ काम करते हैं: read(), write(), select(), close()।

C में एक न्यूनतम TCP server समझना आश्चर्यजनक रूप से आसान है, एक बार आप समझ लें कि हर call क्या करती है:

#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
int main() {
// Create a socket (returns a file descriptor)
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
// Allow address reuse (avoid "address already in use")
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
// Bind to port 8080
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = INADDR_ANY,
.sin_port = htons(8080)
};
bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
// Start listening (backlog of 128 pending connections)
listen(server_fd, 128);
printf("Listening on :8080\n");
while (1) {
// Accept a connection (returns a NEW file descriptor)
int client_fd = accept(server_fd, NULL, NULL);
const char *response =
"HTTP/1.1 200 OK\r\n"
"Content-Length: 13\r\n\r\n"
"Hello, world!";
write(client_fd, response, strlen(response));
close(client_fd);
}
}

यह लगभग 30 लाइनों में एक पूरा HTTP server है। यह single-threaded है और एक समय में एक connection संभालता है, जो production के लिए तैयार नहीं है, लेकिन यह पूरा socket lifecycle दिखाता है: socket(), bind(), listen(), accept(), read()/write(), close()। हर web framework, database driver और message broker अंदर से इसी सटीक क्रम का इस्तेमाल करता है।

Epoll: हज़ारों connections संभालना

ऊपर का single-threaded server एक समय में एक connection संभालता है। असल दुनिया में servers को हज़ारों समवर्ती connections संभालने पड़ते हैं। सरल तरीका, यानी हर connection के लिए एक thread, scale नहीं करता। 10,000 connections पर आप 10,000 thread stacks, context switches और scheduling के फ़ैसलों का overhead चुका रहे होते हैं।

Linux का समाधान है epoll, एक event notification mechanism जो एक single thread को हज़ारों file descriptors कुशलता से मॉनिटर करने देता है। हर 10,000 sockets से यह पूछने के बजाय कि "क्या यह socket तैयार है?", आप kernel से कहते हैं कि "जब इनमें से कोई भी socket तैयार हो, मुझे जगा देना", और सिर्फ़ उन्हीं को संभालते हैं जिनमें डेटा है।

#include <sys/epoll.h>
// Create an epoll instance
int epfd = epoll_create1(0);
// Register the server socket
struct epoll_event ev = {
.events = EPOLLIN,
.data.fd = server_fd
};
epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);
// Event loop
struct epoll_event events[1024];
while (1) {
// Block until at least one fd is ready
int nfds = epoll_wait(epfd, events, 1024, -1);
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == server_fd) {
// New connection — accept and add to epoll
int client = accept(server_fd, NULL, NULL);
ev.events = EPOLLIN;
ev.data.fd = client;
epoll_ctl(epfd, EPOLL_CTL_ADD, client, &ev);
} else {
// Data ready on existing connection
handle_client(events[i].data.fd);
}
}
}

Linux पर हर high-performance server की यही नींव है। Nginx epoll इस्तेमाल करता है। Node.js epoll इस्तेमाल करता है (libuv के ज़रिए)। Go का goroutine scheduler epoll इस्तेमाल करता है। Redis epoll इस्तेमाल करता है। जब लोग कहते हैं कि कोई server "event-driven I/O" या "non-blocking I/O" इस्तेमाल करता है, तो वे आम तौर पर epoll की बात कर रहे होते हैं (या इसके cross-platform समकक्षों की: macOS/BSD पर kqueue, और नवीनतम Linux systems के लिए io_uring)।

High-level डेवलपर्स को इसकी परवाह क्यों करनी चाहिए

हो सकता है आप production में कभी C न लिखें। कोई बात नहीं। लेकिन इन APIs को समझना ऐसे तरीकों से फ़ायदा देता है जो तुरंत नज़र नहीं आते:

• Production issues की debugging — जब strace दिखाए कि आपकी Python app accept() पर अटकी है या file descriptors leak कर रही है, तो आप ठीक जानेंगे कि kernel स्तर पर क्या हो रहा है।
• Performance को समझना — Node.js I/O के लिए तेज़ क्यों है, लेकिन CPU काम के लिए धीमा क्यों? क्योंकि epoll I/O के इंतज़ार को कुशलता से संभालता है, पर JavaScript computation के लिए single-threaded है। System call मॉडल runtime मॉडल को समझा देता है।
• Container और orchestration की समझ — Namespaces, cgroups, seccomp filters, capabilities, ये सब उन्हीं अवधारणाओं पर बने Linux kernel features हैं। Containers कोई जादू नहीं हैं। वे असल में अतिरिक्त flags वाला clone() हैं।
• बेहतर architecture फ़ैसले लेना — Threads या async I/O इस्तेमाल करें? Process-per-request या connection pooling? ये मूल रूप से इस बात के सवाल हैं कि kernel resources को कैसे मैनेज करता है, और सही जवाब syscall स्तर पर trade-offs समझने पर निर्भर करता है।

Thompson और Ritchie containers, cloud computing या smartphones की कल्पना नहीं कर सकते थे। लेकिन उनका डिज़ाइन किया system call interface इतना सरल और composable था कि वह इन सबको संभाल सके। Linux system programming का असली सबक यही है: अच्छे abstractions सिर्फ़ आज की समस्याएँ नहीं सुलझाते। वे एक ऐसी नींव बनाते हैं जो उन समस्याओं के अनुकूल हो जाती है जिनकी किसी ने कल्पना भी नहीं की थी।

आपको हर syscall याद करने की ज़रूरत नहीं है। लेकिन एक दोपहर open(2), fork(2), socket(2) और epoll(7) के man pages पढ़ने में बिताएँ। एक छोटा server लिखें। strace से चल रहे process को trace करें। जो mental model आप बनाएँगे, वह आपको किसी भी भाषा या framework में बेहतर engineer बनाएगा।