File Descriptor — একটা ছোট সংখ্যার পেছনে তিন স্তরের টেবিল

ফাইল ৬ বাইট, বিষয়বস্তু CCCBBB… না — সাবধানে ধাপে ধাপে করি।

f আর g একই open file description (dup2 নতুন description বানায় না), h আলাদা।

চূড়ান্ত উত্তর: ৬ বাইট, বিষয়বস্তু CCCABB।

CCC প্রথম তিন বাইট (AAA) চাপা দিয়েছে, চতুর্থ A টিকে গেছে, তারপর BB।

স্তর অনুযায়ী কী বদলাল:

Level 11-এর সাথে যোগ: এই “মোট ৯ বাইট লেখা, ফাইল ৬ বাইট” ফাঁকটা performance analysis-এও গুরুত্বপূর্ণ — write amplification মাপার সময় application-স্তরের বাইট-গণনা আর প্রকৃত ফাইল-বৃদ্ধি আলাদা করে দেখতে হয়, নইলে I/O accounting ভুল হয়।

(ক) হিসাব

অর্থাৎ ২৬.৬% log line নীরবে অদৃশ্য — কোনো error, কোনো failed write, কোনো লক্ষণ ছাড়াই। প্রতিটা write() সফলভাবে ৫০ ফেরত দিয়েছে।

(খ) প্রক্রিয়া — একটা হারানো লাইনের জীবনকাহিনি

ফাইল ধরুন 36,700 বাইট, দুইটা process P আর Q:

দুইটা সফল write, ফাইল বাড়ল মাত্র ৫০ বাইট — একটা লাইন হারাল। lseek আর write দুইটা আলাদা syscall, আর তাদের মাঝখানে scheduler যেকোনো সময় ঢুকতে পারে (time-slice শেষ, preemption, বা multi-core-এ সত্যিকার সমান্তরালতা)। ৫৩২টা এমন উইন্ডো ঘটেছে ২০০০ চেষ্টার মধ্যে — প্রায় ২৭%, যা দুইটা CPU-bound process একই ফাইলে লিখলে সম্পূর্ণ স্বাভাবিক।

গুরুত্বপূর্ণ: file descriptor দুইটা process-এ আলাদা open() থেকে এসেছে, তাই তারা offset শেয়ার করে না। যদি একটা process fork() করে দুইটা হতো (offset শেয়ার করত), তাহলেও lseek+write অনিরাপদ থাকত — কারণ f_pos শেয়ার করা মানে শুধু একটা মান, দুইটা syscall-এর মাঝে তা বদলে যেতে পারে।

(গ) O_APPEND দিয়ে: হুবহু ১,০০,০০০ বাইট, শূন্য ক্ষতি।

কারণটা স্তর ২-এ: O_APPEND flag থাকলে write() f_pos উপেক্ষাই করে। কার্নেল inode_lock ধরে, f_pos = i_size বসায়, লেখে, i_size আপডেট করে, তারপর lock ছাড়ে — সবটা এক অবিভাজ্য critical section-এ। “শেষ কোথায় দেখা” আর “সেখানে লেখা”-র মাঝে অন্য কেউ ঢুকতেই পারে না, তাই উপরের t2–t4 interleaving-টা অসম্ভব হয়ে যায়।

তিনটা শর্ত মনে রাখুন: এটা local filesystem-এ প্রযোজ্য (NFS-এ না, man 2 open-এর সতর্কবাণী অনুযায়ী), প্রতিটা লাইন একটা write() কলে যেতে হবে (দুইটা কলে ভাগ করলে মাঝে অন্যের লাইন ঢুকতে পারে), আর pipe-এর ক্ষেত্রে সীমা PIPE_BUF = ৪০৯৬ বাইট।

Level 9-এর সাথে যোগ: এটা distributed systems-এর “read-modify-write race” সমস্যার একদম ছোট, একক-মেশিন সংস্করণ — সেখানেও সমাধানের কাঠামো অভিন্ন: হয় অপারেশনটাকে atomic করো (compare-and-swap, O_APPEND), নয়তো বাইরে থেকে lock দাও। Level 11-এ দেখবেন O_APPEND-এর inode_lock উচ্চ-সমান্তরালতায় নিজেই একটা contention bottleneck হয়ে দাঁড়াতে পারে — তখন per-thread ফাইলে লিখে পরে merge করাই দ্রুততর।

(ক) Octal মানটা ভেঙে ফেলি। 02102002 octal — প্রতিটা সেট বিট আলাদা করি:

যাচাই: 02000000 + 0100000 + 02000 + 02 = 02102002 — মিলে গেছে (octal-এ কলামভিত্তিক যোগ: 2+0+0+0 → 2, তারপর 1, তারপর 0, 2, 0, 0, 2)।

তাই: O_RDWR | O_APPEND | O_LARGEFILE | O_CLOEXEC — একটা read-write, append-mode, exec-এ বন্ধ হয়ে যাওয়া fd। প্রায় নিশ্চিতভাবে একটা log ফাইল, ভালোভাবে লেখা কোনো প্রোগ্রামের।

(খ) pos: 0 হলেও লেখা যাবে ফাইলের শেষে। কারণ O_APPEND সেট — এই flag থাকলে write() f_pos-কে সম্পূর্ণ উপেক্ষা করে, প্রতিবার i_size থেকে শুরু করে। pos: 0 এখানে শুধু বলছে এই description দিয়ে এখনো কেউ কিছু পড়েনি (read() কিন্তু f_pos থেকেই পড়ে — O_APPEND শুধু write-কে প্রভাবিত করে, read-কে না, এটা একটা সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ অসামঞ্জস্য)। প্রথম write()-এর পরে pos লাফ দিয়ে i_size-এ চলে যাবে।

(গ) fork()-এ থাকবে, exec()-এ থাকবে না। fork() fd table কপি করে, CLOEXEC bitmap-সহ — তাই fd 9 child-এ ঠিকই থাকবে, একই description শেয়ার করে। কিন্তু child যখন execve() করবে, কার্নেল close_on_exec bitmap দেখে fd 9-কে স্বয়ংক্রিয়ভাবে বন্ধ করে দেবে। নতুন প্রোগ্রাম log ফাইলটা দেখতেই পাবে না — যা এখানে ঠিক কাম্য, নিরাপত্তার জন্য।

মনে রাখুন O_CLOEXEC আসলে স্তর ২-এর f_flags-এ নেই, স্তর ১-এর bitmap-এ — /proc উপস্থাপনার সময় দুইটা জুড়ে দেখায়।

Level 10-এর সাথে যোগ: এই CLOEXEC বিটটা privilege separation-এর একটা মৌলিক টুল। Level 10-এ দেখবেন sandbox ডিজাইনের নিয়ম হলো “capability সবসময় স্পষ্টভাবে হস্তান্তর করো, উত্তরাধিকারে দিয়ো না” — CLOEXEC ডিফল্ট-অন করা সেই নীতিরই fd-স্তরের প্রয়োগ, আর seccomp + fd passing (SCM_RIGHTS) দিয়ে গড়া আধুনিক sandbox-এর ভিত্তি।

কেন পরামর্শটা অসম্পূর্ণ: Too many open files = EMFILE, যার দুইটা সম্পূর্ণ ভিন্ন কারণ থাকতে পারে —

“প্রতিদিন দুপুরে” — একটা periodic pattern — দুইটাই হতে পারে (দুপুরের peak traffic, নাকি প্রতি রাতে restart হয়ে আবার ২৪ ঘণ্টায় leak জমে?)। তাই আগে মাপতে হবে।

Diagnosis পরিকল্পনা

ধাপ ১ — fd সংখ্যার সময়-রেখা নিন (leak বনাম spike আলাদা করার একমাত্র উপায়):

PID=$(pgrep -f myservice)
while true; do
  printf '%s %s\n' "$(date +%H:%M:%S)" "$(ls /proc/$PID/fd | wc -l)"
  sleep 60
done | tee fdcount.log

একঘেয়ে ঊর্ধ্বমুখী রেখা = leak। লোডের সাথে ওঠানামা = ক্ষমতার সমস্যা।

ধাপ ২ — fd-গুলো কী তা ভাগ করুন:

ls -l /proc/$PID/fd | awk '{print $NF}' | sed 's/\[[0-9]*\]//' \
  | sort | uniq -c | sort -rn | head

   8912 socket:
     31 /var/log/myservice/app.log
     12 anon_inode:
      4 /dev/urandom

৮৯১২টা socket = network-স্তরে leak। ৮৯১২টা একই log ফাইল = কেউ প্রতি request-এ log ফাইল খুলছে আর বন্ধ করছে না।

ধাপ ৩ — socket হলে অবস্থা দেখুন:

ss -s
ss -tanp state close-wait | wc -l

প্রচুর CLOSE_WAIT একটা নির্দিষ্ট রোগের স্বাক্ষর: peer connection বন্ধ করেছে, কিন্তু আপনার প্রোগ্রাম close() ডাকেনি। এটা প্রায় সবসময় error path-এ একটা ভুলে যাওয়া close() — যেমন timeout বা exception হলে socket বন্ধ না করে বেরিয়ে যাওয়া।

ধাপ ৪ — কোড-স্তরে ধরুন: lsof -p $PID দিয়ে সবচেয়ে পুরনো fd-গুলো দেখুন (নম্বর যত ছোট তত পুরনো নয় — নম্বর পুনর্ব্যবহৃত হয় — তাই /proc/$PID/fdinfo আর application log মিলিয়ে দেখুন)। আরো সরাসরি: strace -f -e trace=openat,socket,accept4,close -p $PID -c চালিয়ে গণনা মেলান — যদি open+socket+accept4 এর যোগফল close-এর চেয়ে ধারাবাহিকভাবে বেশি হয়, leak নিশ্চিত।

ধাপ ৫ — তারপর সীমাও ঠিক করুন। Leak সারানোর পরেও একটা web service-এর ১০২৪ কম। systemd unit-এ LimitNOFILE=65536, আর ক্ষমতা-পরিকল্পনা: প্রয়োজনীয় fd ≈ (সর্বোচ্চ concurrent connection × প্রতি connection fd) + log/config/cache fd + নিরাপত্তা-মার্জিন। Proxy হলে “প্রতি connection fd” ২ (client + upstream), nginx-এর মতোই।

Level 7 ও Level 12-এর সাথে যোগ: CLOSE_WAIT-এর সঠিক ব্যাখ্যা TCP state machine থেকে আসে — Level 7-এর networking module-এ FIN/ACK আর four-way close দেখলে বুঝবেন কেন peer বন্ধ করলে আপনার দিকটা নিজে থেকে মুক্ত হয় না। আর Level 12-এর cloud module-এ দেখবেন container-এ ulimit inherit হয় ভিন্নভাবে (Docker-এর --ulimit, Kubernetes-এ pod-স্তরে সরাসরি সেট করা যায় না) — তাই host-এ ulimit -n ঠিক করেও container-এর ভেতরে সমস্যা থেকে যেতে পারে।

সিদ্ধান্ত ১ — প্রতিটা fd SOCK_CLOEXEC দিয়ে তৈরি করুন, ব্যতিক্রমহীনভাবে।

int s = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0);
/* accept-এও: accept4(lfd, NULL, NULL, SOCK_CLOEXEC) -- accept() না */

socket() + পরে fcntl(F_SETFD) নয় — সেই দুই লাইনের মাঝে অন্য thread fork+exec করলে fd leak হয়েই গেছে, আর multithreaded অ্যাপে এই জানালা বাস্তবে খোলে। একই কারণে pipe2(), dup3(), open(O_CLOEXEC), accept4() — সব CLOEXEC-সহ সংস্করণ ব্যবহার করুন।

Trade-off: পুরনো platform-এ portability। SOCK_CLOEXEC/accept4() Linux 2.6.27+ (2008), macOS-এ SOCK_CLOEXEC নেই — সেখানে fcntl fallback লাগবে, আর সেই fallback-এ race-টা ফিরে আসে (macOS-এ কোনো atomic বিকল্প নেই)। তাই একটা #ifdef-ঘেরা compatibility layer লিখতে হবে, যা কোড জটিল করে।

সিদ্ধান্ত ২ — pthread_atfork() হ্যান্ডলার দিয়ে fork-এর পরে pool-এর অবস্থা স্পষ্টভাবে ঠিক করুন।

CLOEXEC শুধু exec-এ কাজ করে। কিন্তু অ্যাপ যদি fork() করে exec না করে (একটা background worker fork করল), তখন child-এ pool-এর সব socket fd বেঁচে থাকে — আর এখন দুইটা process একই TCP connection-এ লিখছে, যা প্রোটোকল-স্তরে সম্পূর্ণ বিশৃঙ্খলা (দুই দিকের request-response আন্তঃমিশ্রিত)। এটা CLOEXEC দিয়ে ধরা পড়ে না, আর ডিবাগ করা ভয়াবহ কঠিন।

static void after_fork_in_child(void) {
    for (int i = 0; i \< pool->n; i++) close(pool->conn[i].fd);
    pool->n = 0;              /* child নতুন connection বানাবে, উত্তরাধিকার না */
}
pthread_atfork(NULL, NULL, after_fork_in_child);

Trade-off: pthread_atfork handler-এ কী করা নিরাপদ তার কড়া সীমা আছে — child-এ শুধু async-signal-safe ফাংশন ডাকা বৈধ (fork করা multithreaded process-এ অন্য thread-এর ধরে রাখা mutex চিরতরে লক থাকতে পারে)। close() নিরাপদ, কিন্তু malloc/free/logging নিরাপদ না। তাই handler-টা খুব সংযত রাখতে হবে, আর pool-এর data structure এমনভাবে ডিজাইন করতে হবে যাতে শুধু fd-গুলো ছোঁয়া যায়, allocation ছাড়াই।

সিদ্ধান্ত ৩ — library-র নিজস্ব একটা “spawn helper” API দিন, অ্যাপকে কাঁচা fork+exec করতে না দিয়ে।

posix_spawn() (বা fork+close_range+exec-এর একটা wrapper) ব্যবহার করে একটা mylib_spawn(cmd, argv, fds_to_keep[]) ফাংশন দিন, যেটা child-এ শুধু স্পষ্টভাবে চাওয়া fd-গুলো রাখে আর বাকি সব close_range(3, ~0U, 0) (Linux 5.9+) দিয়ে বন্ধ করে দেয়।

Trade-off: এটা “defence in depth” — সবচেয়ে শক্ত গ্যারান্টি, কারণ এটা আপনার library-র বাইরের অন্য library-র leak করা fd-ও ধরে ফেলে (আপনার নিয়ন্ত্রণের বাইরের কোড, যেটা CLOEXEC ব্যবহার নাও করতে পারে)। কিন্তু দাম দুইটা: (ক) এটা অ্যাপের উপর একটা API চাপিয়ে দেয় — অ্যাপ যদি সরাসরি fork করে, সুরক্ষাটা কাজ করে না, তাই ডকুমেন্টেশন আর শৃঙ্খলার উপর নির্ভরশীল; (খ) close_range নেই এমন কার্নেলে fallback হলো RLIMIT_NOFILE পর্যন্ত লুপ — যা সীমা বড় হলে (৫২৪২৮৮) প্রতিটা spawn-এ মাপা যায় এমন বিলম্ব যোগ করে।

সুপারিশকৃত সমন্বয়: ১ + ২ বাধ্যতামূলক (আপনার নিজের fd-র জন্য, আর এগুলো অ্যাপের কোনো সহযোগিতা ছাড়াই কাজ করে), ৩ ঐচ্ছিক সুবিধা হিসেবে — যে অ্যাপ চায় সে ব্যবহার করবে, না চাইলেও ১ ও ২ তাকে রক্ষা করবে।

Level 12-এর সাথে যোগ: container-এ এই সমস্যাগুলো আরো তীব্র — container runtime নিজেই fork/exec/setns-এর একটা শৃঙ্খল চালায়, আর সেখানে একটা leaked fd মানে namespace-এর বেড়া টপকানো (CVE-2016-9962 ঠিক এটাই ছিল)। Level 12-এ দেখবেন কেন container isolation-এর সঠিক মানসিক মডেল হলো “namespace একটা বেড়া, কিন্তু একটা fd সেই বেড়ার নিচ দিয়ে যাওয়া একটা সুড়ঙ্গ” — আর Level 10-এ capability-based security মডেলে দেখবেন fd-কে আসলে একটা capability হিসেবে ভাবাই সবচেয়ে সঠিক: অধিকারটা নামের মধ্যে না, handle-এর মধ্যে।