PricingLoginStart free
DevOps बूटकैंप · पाठ

सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी

दौड़ की स्थितियों से मुक्त अस्थायी संसाधन बनाने और एक ही समय में चलने वाली स्क्रिप्ट रोकने के लिए mktemp और flock का उपयोग करें।

पाठ 3, कुल 4 में से13 चरण

सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी, CoddyKit पर DevOps बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह DevOps बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

अस्थायी फ़ाइलें सुरक्षा जोखिम क्यों हैं

Bash स्क्रिप्ट को अक्सर अस्थायी संग्रहण की आवश्यकता होती है — मध्यवर्ती परिणाम, लॉक चिह्न और तैयारी क्षेत्र। लेकिन असावधानी से अस्थायी फ़ाइलें बनाने पर गंभीर सुरक्षा कमज़ोरियाँ खुल जाती हैं।

  • रेस स्थितियाँ: कोई अन्य प्रक्रिया आपके फ़ाइल नाम का अनुमान लगाकर पहले फ़ाइल बना सकती है और आपके लेखन को दूसरी दिशा में भेज सकती है।
  • सिमलिंक हमले: हमलावर आपके अनुमानित पथ पर संवेदनशील फ़ाइल, जैसे /etc/passwd, की ओर संकेत करने वाला सिमलिंक बना सकता है।
  • बची हुई फ़ाइलें: यदि स्क्रिप्ट क्रैश हो जाए, तो अस्थायी फ़ाइलें जमा हो सकती हैं और संवेदनशील डेटा उजागर कर सकती हैं।

इन समस्याओं को समाप्त करने वाले दो मुख्य टूल mktemp और flock हैं। यह पाठ आपको दोनों का सुरक्षित और रक्षात्मक ढंग से उपयोग करना दिखाता है।

mktemp से सुरक्षित अस्थायी फ़ाइलें बनाना

mktemp यादृच्छिक, अप्रत्याशित नाम वाली अस्थायी फ़ाइल बनाता है और उसका पथ लौटाता है। यह फ़ाइल को परमाण्विक रूप से बनाता है, इसलिए कोई अन्य प्रक्रिया पहले उस नाम को हासिल नहीं कर सकती।

  • सिंटैक्स: mktemp [TEMPLATE] — टेम्पलेट का अंत कम-से-कम तीन X अक्षरों से होना चाहिए।
  • प्रत्येक X को यादृच्छिक अक्षर से बदला जाता है, जिससे /tmp/script.aB3kQz जैसा विशिष्ट नाम बनता है।
  • फ़ाइल अपने-आप 0600 अनुमतियों के साथ बनाई जाती है (इसे केवल स्वामी पढ़ सकता है)।

लौटाए गए पथ को हमेशा तुरंत एक वैरिएबल में सहेजें, ताकि बाद में उसका संदर्भ देकर उसे साफ़ किया जा सके।

#!/usr/bin/env bash
set -euo pipefail

# Create a secure temp file
TMPFILE=$(mktemp /tmp/myapp.XXXXXX)
echo "Temp file created at: $TMPFILE"

# Write data to it
echo "some intermediate result" > "$TMPFILE"

# Read it back
cat "$TMPFILE"

# Clean up
rm -f "$TMPFILE"

trap से हमेशा सफ़ाई करें

यदि आपकी स्क्रिप्ट अप्रत्याशित रूप से बाहर निकलती है — किसी त्रुटि, सिग्नल या set -e के सक्रिय होने के कारण — तो सफ़ाई हैंडलर पंजीकृत न होने पर अस्थायी फ़ाइलें पीछे छूट जाएँगी।

trap बिल्ट-इन तब कमांड चलाता है, जब शेल को कोई सिग्नल मिलता है या वह बाहर निकलता है। अस्थायी फ़ाइल की सफ़ाई का मानक पैटर्न है:

  • अस्थायी फ़ाइल बनाने के तुरंत बाद ट्रैप पंजीकृत करें।
  • EXIT पर ट्रैप लगाएँ, ताकि सामान्य और असामान्य दोनों तरह से बाहर निकलने पर सफ़ाई चले।
  • यदि स्क्रिप्ट लंबे समय तक चलती है या इंटरैक्टिव है, तो INT और TERM पर भी ट्रैप लगाएँ।

यह सुनिश्चित करता है कि स्क्रिप्ट के बीच में समाप्त कर दिए जाने पर भी कोई अनाथ फ़ाइल न बचे।

#!/usr/bin/env bash
set -euo pipefail

TMPFILE=$(mktemp /tmp/report.XXXXXX)

# Register cleanup before doing any real work
cleanup() {
    rm -f "$TMPFILE"
    echo "Cleaned up $TMPFILE" >&2
}
trap cleanup EXIT

# Do work — even if this fails, cleanup() will run
echo "Processing..." > "$TMPFILE"
grep "result" "$TMPFILE" || true

echo "Done. File will be removed on exit."

mktemp -d से अस्थायी निर्देशिकाएँ बनाना

कभी-कभी आपको कई फ़ाइलों को अस्थायी रूप से रखने के लिए पूरी निर्देशिका की आवश्यकता होती है—उदाहरण के लिए, संग्रह बनाते समय या संसाधित करने से पहले tarball निकालते समय। सुरक्षित अस्थायी निर्देशिका बनाने के लिए mktemp -d का उपयोग करें।

  • निर्देशिका 0700 अनुमतियों के साथ बनाई जाती है (केवल स्वामी को पहुँच)।
  • अपने trap में rm -rf से उसे साफ़ करें—सावधान रहें कि केवल variable को हटाएँ, कभी भी hardcoded path को नहीं।
  • दोहरा-उद्धरण इस्तेमाल करें और rm -rf चलाने से पहले जाँच लें कि variable खाली नहीं है। यह एक अतिरिक्त सुरक्षा जाँच है।
#!/usr/bin/env bash
set -euo pipefail

TMPDIR=$(mktemp -d /tmp/extract.XXXXXX)

cleanup() {
    # Guard: only rm if variable is set and non-empty
    [[ -n "${TMPDIR:-}" ]] && rm -rf "$TMPDIR"
}
trap cleanup EXIT

echo "Working in $TMPDIR"

# Simulate staging files
echo "file one" > "$TMPDIR/part1.txt"
echo "file two" > "$TMPDIR/part2.txt"

ls "$TMPDIR"
echo "All done."

एक साथ चलने वाली स्क्रिप्टों की समस्या

Cron jobs, systemd timers और manually triggered scripts एक ही script के कई instances को एक साथ आसानी से शुरू कर सकते हैं। इससे ये समस्याएँ होती हैं:

  • दोहरा processing: एक ही database records या files को दो बार process किया जाता है।
  • दूषित output: दो instances एक ही output file में एक साथ लिखते हैं।
  • Deadlocks या partial state: दोनों instances shared resources में बारी-बारी से, अप्रत्याशित क्रम में बदलाव करते हैं।

पारंपरिक समाधान था कि एक PID file लिखी जाए और startup पर उसकी जाँच की जाए—लेकिन जाँच और लिखने के बीच race window रहती है। सही आधुनिक समाधान flock है, जो kernel की advisory locking mechanism का उपयोग करके race-free lock सुनिश्चित करता है।

flock से locking: एक-पंक्ति pattern

flock command चलाने से पहले file descriptor पर advisory lock प्राप्त करता है। सबसे सरल उपयोग command line से पूरी script को wrap करना है:

flock -n /var/lock/myscript.lock bash myscript.sh

  • -n (non-blocking): यदि lock पहले से लिया जा चुका है, तो प्रतीक्षा करने के बजाय status 1 के साथ तुरंत बाहर निकलता है।
  • -n के बिना, flock lock उपलब्ध होने तक block करता है—queue बनाने के लिए उपयोगी।
  • Lock file स्वयं केवल एक marker है; उसकी सामग्री महत्वपूर्ण नहीं है। उसे runs के बीच रखना सुरक्षित है।
  • Lock रखने वाली process के बाहर निकलने पर kernel उसे अपने-आप release कर देता है—manual cleanup की आवश्यकता नहीं होती।
#!/usr/bin/env bash
# launcher.sh — prevents concurrent runs of worker.sh
set -euo pipefail

LOCKFILE="/tmp/myworker.lock"

if ! flock -n "$LOCKFILE" bash -c 'echo "Running worker..."; sleep 2; echo "Done."'; then
    echo "Another instance is already running. Exiting." >&2
    exit 1
fi

File Descriptor का उपयोग करके Script के अंदर flock

Script को बाहर से wrap करने के बजाय उसके भीतर locking करने के लिए exec से file descriptor खोलें और फिर उस descriptor पर flock चलाएँ। Production scripts में यही idiomatic pattern इस्तेमाल किया जाता है।

  • exec 200>"$LOCKFILE" descriptor 200 पर file को writing के लिए खोलता है (आवश्यक होने पर उसे बनाता है)।
  • flock -n 200 descriptor 200 को non-blocking तरीके से lock करने का प्रयास करता है।
  • Lock file name के बजाय file descriptor से जुड़ा होता है, इसलिए shell process के बाहर निकलने पर वह अपने-आप release हो जाता है।
  • stdin/stdout/stderr से टकराव से बचने के लिए descriptor numbers 200-299 का परंपरागत रूप से उपयोग किया जाता है।
#!/usr/bin/env bash
set -euo pipefail

LOCKFILE="/tmp/myjob.lock"

# Open lock file on FD 200
exec 200>"$LOCKFILE"

# Attempt non-blocking lock
if ! flock -n 200; then
    echo "ERROR: Another instance of this script is running." >&2
    exit 1
fi

echo "Lock acquired. Starting work..."
sleep 1
echo "Work complete. Lock will be released on exit."

एक Script में mktemp और flock को मिलाना

वास्तविक defensive scripts को दोनों की आवश्यकता होती है: एक lock, ताकि एक साथ चलने वाली executions रुकें, और intermediate data के लिए सुरक्षित temp files। यहाँ दोनों techniques को मिलाने वाला पूरा pattern दिया गया है:

  • पहले lock प्राप्त करें—कोई भी temp files बनाने से पहले—ताकि केवल एक instance ही कोई काम करे।
  • Lock की पुष्टि होने के बाद temp resources बनाएँ।
  • Temps बनाने के तुरंत बाद trap register करें, ताकि script चाहे जैसे भी बाहर निकले, cleanup सुनिश्चित हो।
  • Lock file को temp directory में कभी न रखें—वह runs के बीच बनी रहनी चाहिए, ताकि flock उसका reference ले सके।
#!/usr/bin/env bash
set -euo pipefail

LOCKFILE="/tmp/report_builder.lock"
exec 200>"$LOCKFILE"

if ! flock -n 200; then
    echo "Already running — aborting." >&2
    exit 1
fi

# Now safe to create temp resources
TMPDIR=$(mktemp -d /tmp/report.XXXXXX)
TMPLOG=$(mktemp /tmp/report_log.XXXXXX)

cleanup() {
    rm -rf "${TMPDIR:-}"
    rm -f  "${TMPLOG:-}"
}
trap cleanup EXIT

echo "Building report in $TMPDIR" | tee "$TMPLOG"
echo "Step 1 complete"             >> "$TMPLOG"
cat "$TMPLOG"

वैकल्पिक Lock Mechanism के रूप में Lock Directories

जिन systems पर flock उपलब्ध नहीं है (कुछ embedded systems या NFS जैसे network filesystems), वहाँ आप इसके बजाय lock directories का उपयोग कर सकते हैं। POSIX systems पर mkdir atomic होता है: यह तभी सफल होता है जब directory पहले से मौजूद न हो।

  • mkdir /tmp/myscript.lock.d से lock directory बनाएँ—यदि कोई दूसरा instance उसे पहले ही बना चुका है, तो mkdir तुरंत fail हो जाता है।
  • Diagnostics के लिए directory के अंदर metadata (जैसे PID) रखें।
  • EXIT पर trap में directory को हमेशा हटाएँ।
  • सावधानी: flock के विपरीत, यदि process को -9 से kill किया जाए या machine reboot हो जाए, तो directory lock अपने-आप release नहीं होता—stale-lock detection check जोड़ें।
#!/usr/bin/env bash
set -euo pipefail

LOCKDIR="/tmp/myscript.lock.d"

# Atomic mkdir — fails if directory already exists
if ! mkdir "$LOCKDIR" 2>/dev/null; then
    # Check if the holding PID is still alive
    HOLDER_PID=$(cat "$LOCKDIR/pid" 2>/dev/null || echo "")
    if [[ -n "$HOLDER_PID" ]] && kill -0 "$HOLDER_PID" 2>/dev/null; then
        echo "Locked by PID $HOLDER_PID. Exiting." >&2
        exit 1
    else
        echo "Stale lock detected. Removing and continuing." >&2
        rm -rf "$LOCKDIR"
        mkdir "$LOCKDIR"
    fi
fi

echo "$$" > "$LOCKDIR/pid"
trap 'rm -rf "$LOCKDIR"' EXIT

echo "Lock acquired via directory. Running..."
sleep 1
echo "Done."

flock के साथ Timeout-Based Waiting

कभी-कभी आप lock के लिए तुरंत fail होने के बजाय प्रतीक्षा करना चाहते हैं—लेकिन हमेशा के लिए नहीं। flock -w flag के साथ timeout का समर्थन करता है।

  • flock -w 10 200 lock के लिए अधिकतम 10 seconds तक प्रतीक्षा करता है, और फिर भी उपलब्ध न होने पर status 1 के साथ बाहर निकलता है।
  • यह उन scripts के लिए आदर्श है जिन्हें कम समय तक चलने वाले predecessor के पीछे queue में लगना चाहिए, लेकिन predecessor के अटक जाने पर छोड़ देना चाहिए।
  • -w को context सहित meaningful error message के साथ मिलाएँ—इसमें lock file path और आपने कितनी देर प्रतीक्षा की, यह शामिल होना चाहिए—ताकि operators hangs का शीघ्र diagnosis कर सकें।
#!/usr/bin/env bash
set -euo pipefail

LOCKFILE="/tmp/data_sync.lock"
TIMEOUT=15

exec 200>"$LOCKFILE"

echo "Waiting up to ${TIMEOUT}s for lock on $LOCKFILE..."

if ! flock -w "$TIMEOUT" 200; then
    echo "ERROR: Could not acquire lock after ${TIMEOUT}s." \
         "Another instance may be hung." >&2
    exit 1
fi

echo "Lock acquired. Syncing data..."
sleep 1
echo "Sync complete."

Defensive Checklist: सुरक्षित Temp Resources

Temp files या locking का उपयोग करने वाली किसी भी script को ship करने से पहले इस checklist से जाँच करें:

  • mktemp का उपयोग करें, hardcoded paths का कभी नहीं—/tmp/myapp.tmp अनुमान लगाने योग्य और exploit किया जा सकने वाला है।
  • Path को तुरंत capture करें—किसी भी अन्य command से पहले TMPFILE=$(mktemp ...)।
  • Creation के तुरंत बाद trap cleanup EXIT register करें—script के अंत में नहीं।
  • सभी variable uses को double-quote करें—rm -f "$TMPFILE", कभी भी rm -f $TMPFILE नहीं।
  • PID files के बजाय flock को प्राथमिकता दें—kernel द्वारा managed और crash पर अपने-आप release होने वाला।
  • डिफ़ॉल्ट रूप से non-blocking -n का उपयोग करें—चुपचाप block करने वाले locks performance problems छिपाते हैं।
  • Lock file को temp directory के बाहर रखें—ताकि वह cleanup trap के बाद भी बनी रहे।
  • Cleanup behavior को test करें—अपनी script चलाएँ और execution के बीच उसे kill -9 करें; जाँचें कि कोई leftover files न बची हों (flock-based scripts के लिए; directory locks में अतिरिक्त सावधानी चाहिए)।

ज्ञान जाँच: flock Flag का व्यवहार

एक cron job हर minute चलती है और shared file को process करती है। आप चाहते हैं कि यदि पिछला run अभी भी active हो, तो कोई भी नया invocation प्रतीक्षा किए बिना error के साथ तुरंत बाहर निकल जाए। कौन-सा flock invocation इसे सही ढंग से लागू करता है?

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: सुरक्षित Temporary Files और Lock Directories

इस lesson में आपने Bash में defensive resource management के दो आवश्यक tools सीखे:

  • mktemp अप्रत्याशित, सुरक्षित permissions वाली temporary files (0600) और directories (0700) बनाता है, जिससे hardcoded paths से होने वाली race conditions और symlink attacks समाप्त हो जाती हैं।
  • trap cleanup EXIT creation के तुरंत बाद register किए जाने पर किसी भी exit—सामान्य, error-triggered या signal-triggered—पर temp file removal की गारंटी देता है।
  • flock kernel-enforced advisory locking देता है: contention पर तुरंत fail होने के लिए -n, timeout के साथ प्रतीक्षा के लिए -w N, और in-script locking के लिए exec 200>file pattern का उपयोग करें; process के बाहर निकलने पर kernel इसे अपने-आप release कर देता है।
  • Lock directories (mkdir) उन environments के लिए portable fallback देते हैं जहाँ flock उपलब्ध नहीं है, लेकिन इनके लिए stale-lock detection स्पष्ट रूप से आवश्यक है।
  • Lock file को हमेशा temp directory के बाहर रखें और cleanup में उपयोग किए जाने वाले प्रत्येक variable को double-quote करें।

mktemp + flock + trap को मिलाने से ऐसी scripts मिलती हैं जो concurrent invocations, अप्रत्याशित crashes और filesystem के दुर्भावनापूर्ण manipulation से सुरक्षित होती हैं।

शुरुआत निःशुल्क

एआई शिक्षक के साथ DevOps बूटकैंप सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
142
पाठ
568
निःशुल्क सीखना शुरू करेंपूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी” पाठ निःशुल्क है?

हाँ — DevOps बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी” में मैं क्या सीखूँगा?

दौड़ की स्थितियों से मुक्त अस्थायी संसाधन बनाने और एक ही समय में चलने वाली स्क्रिप्ट रोकने के लिए mktemp और flock का उपयोग करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ DevOps बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या DevOps बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर DevOps बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।

“सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस DevOps बूटकैंप पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर DevOps बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. set -euo pipefail के साथ सख्त मोड
  2. सफ़ाई और सिग्नल के लिए Trap हैंडलर
  3. सुरक्षित अस्थायी फ़ाइलें और लॉक डायरेक्टरी
  4. Idempotent स्क्रिप्ट और बैकऑफ़ सहित पुनःप्रयास तर्क
← DevOps बूटकैंप पर वापस जाएँ