आपको कुछ आउट-ऑफ-कंट्रोल लॉग मिले हैं। हर रोज पागलों की तरह हटाने के बजाय, तेजी से बढ़ती फाइल या फाइलों को ढूंढें , और यह जांचने के लिए अंदर देखें कि यह क्या कारण हो सकता है। हो सकता है कि कुछ प्रोग्राम लूप में कताई कर रहा हो, कुछ कंडीशन लॉग कर रहा हो। या तो उस प्रोग्राम को अक्षम करें, उसके लॉगिंग को अक्षम करें या उस स्थिति को ठीक करने का प्रयास करें जिसके बारे में वह शिकायत कर रहा है।
यदि आपकी आंखों के सामने कोई फ़ाइल बढ़ रही है, और आपको पता नहीं है कि कौन सा प्रोग्राम इसे लिख रहा है, तो आप इसे आसानी से ढूंढ सकते हैं। यहाँ एक उदाहरण है। किसने /var/log/syslogखोला है? हम fuserकमांड का उपयोग करते हैं :
# fuser /var/log/syslog
/var/log/syslog: 602
केवल एक प्रक्रिया /var/log/syslogखुली है। यह 602 प्रक्रिया है। वह क्या है? हमें परेशान न करें psऔर grep, लेकिन /procसीधे फाइल सिस्टम को देखें:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
अहा, यह है rsyslogd। हम हैरान नहीं कर रहे हैं कि rsyslogdहै /var/log/syslog/खुला।
यह विधि काम करने की गारंटी नहीं है। इसका कारण यह है कि प्रोग्राम को लिखने के लिए फाइलों को इनो रिडर रखने की आवश्यकता नहीं होती है। मान लीजिए कि आपके पास एक प्रक्रिया है जो एक फ़ाइल खोलती है, इसे संलग्न करती है, और फिर इसे बंद कर देती है। आपके पास कुछ अधिक कठिन जांच होगी। आप fuserकई बार चला सकते हैं जब तक कि संयोग से आप "रेड हैंड" प्रक्रिया को पकड़ नहीं लेते। वह प्रक्रिया स्वयं अस्तित्व में और जल्दी से बाहर जा सकती है। एक और समस्या यह है कि कई प्रक्रियाओं में फ़ाइल खुली हो सकती है, लेकिन केवल एक ही इसे बड़ा बना रही है। उस स्थिति में, आप उनके सिस्टम कॉल का पता लगा सकते हैं।
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
ऊप्स! दो प्रक्रियाओं में यह खुला है: 1234 और 23459। आइए देखें कि वे क्या कर रहे हैं:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
यह कुछ नहीं कर रहा है, बस एक selectकॉल में अवरुद्ध है । ट्रेस को तोड़ने के लिए Ctrl-C:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
अगले एक की जाँच करें:
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
उफ़, जो लगातार लिख रहा है। यह बुरा होना चाहिए। हम यह भी जाँच सकते हैं कि फाइल डिस्क्रिप्टर 5 जिस प्रक्रिया को लिख रहा है वह वास्तव में बड़ी फाइल है:
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
मुझे संदेह नहीं है कि आपके पास एक भ्रष्ट फाइल सिस्टम है, लेकिन एक पूर्ण जांच को मजबूर करने के लिए, आपको एक डीवीडी बूट करने की आवश्यकता नहीं है।
सबसे पहले, अपने फाइलसिस्टम की अधिकतम माउंट गिनती सेटिंग की समीक्षा करें। Df कमांड का उपयोग करके अपने विभाजन को पहचानें। एक उबंटू प्रणाली पर उदाहरण मैं यहाँ है:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
आप देख सकते हैं कि /फाइलसिस्टम आरोहित है /dev/sda1। तो /dev/sda1रूट विभाजन का भंडारण उपकरण है (और इस विशेष प्रणाली में एकमात्र विभाजन)।
आइए उस फाइलसिस्टम की कुछ विशेषताओं को देखें। यह माउंट होने के बावजूद सुरक्षित है। कमांड ने बहुत सारे आउटपुट को प्रायोजित किया। यहाँ एक अंश है:
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
अरे देखो, माउंट की गिनती अधिकतम माउंट गिनती के बराबर है। अगली बार जब मैं रिबूट करूंगा, तो एक फाइलसिस्टम जांच होगी। महत्वपूर्ण बात यह है कि माउंट की गिनती एक सकारात्मक मूल्य है। यदि आपका शून्य है, तो इसे कुछ सकारात्मक मान में बदलें जैसे 22 का उपयोग करना tune2fs -c 22 /dev/whatever। शून्य का मतलब है कि विभाजन को माउंट किए जाने के बिना चेक को कभी भी मजबूर नहीं किया जाता है। शायद ही कभी रिबूट सिस्टम को यहां कम मान होना चाहिए। एक सर्वर जो एक वर्ष में एक बार नीचे जाता है, वह शायद हर बार रिबूट करने के लिए एक fsck का उपयोग कर सकता है। आप दिनांक-आधारित चेक अंतराल भी सेट कर सकते हैं।
अब एक चेक को बाध्य करने के लिए, आप वास्तविक गिनती को अधिकतम से अधिक या उसके बराबर होने के लिए ओवरराइड कर सकते हैं , और फिर रिबूट कर सकते हैं। यही कारण है कि पूंजी के साथ किया जाता है C: tune2fs -C 1234 /dev/whatever। अब विभाजन ऐसा लग रहा है कि यह बिना किसी चेक के 1234 बार चढ़ा गया है, जो कि अधिकतम एक या दो अंकों से अधिक है।
sudo du -sh /var/* ~/.xsession-errorsकृपया पोस्ट को एडिट करके कृपया आउटपुट को बढ़ा सकते हैं ? (अगर मैं मूर्खतापूर्ण कुछ हो रहा हूं तो मैं उन दो स्थानों को उड़ाने की उम्मीद करूंगा)। अन्यथा, मैं एलियाह के साथ हूं - यह डिस्क मुद्दों का संकेत है। इसे गंभीरता से लें।