मेरी डिस्क कौन भर रहा है?

Question

मेरे पास मेरी प्राथमिक डिस्क पूरी तरह से भरी हुई है:

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/ dev / sda1 मेरी प्राथमिक डिस्क है जहाँ ubuntu स्थापित है:

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

कुछ Google ने खोज की और कुछ आदेशों का परीक्षण करने के लिए पाया कि कौन जिम्मेदार है, लेकिन मैं यह नहीं पता लगा सकता कि कौन इसे भर रहा है:

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

जाहिरा तौर पर मेरी डिस्क के 84G को भरने के लिए कोई फ़ाइल या निर्देशिका इतनी बड़ी नहीं है।

कुछ दिन पहले मैंने पाया कि डिस्क .xsession- त्रुटियों के कारण भरा हुआ था जो पागल हो गया था। मैंने पाया कि यह उबंटू में एक ज्ञात बग है और मैंने एक कॉन्ट्राब लाइन बनाने का हल किया है जो हर दस मिनट में .xsession-त्रुटियों को हटाता है। वास्तव में अभी मेरे पास यह नहीं है मेरे घर निर्देशिका में।

कोई मदद, कृपया?

Comments

मेरे पास .xsession- त्रुटियां नहीं हैं, क्रोनजॉब ने इसे हटा दिया। मुझे उबंटू की आधिकारिक रीलों के साथ क्या मतलब नहीं है: मेरे पास उबंटू 16.04.1 LTS है।

— effemmeffe

यह देखने के लिए कि क्या डिलीट की गई फाइलें अभी भी किसी भी प्रोसेस से एक्सेस हैं, sudo lsof | grep deletedसंकेत देंगी।

— 9

@ उपहास की टिप्पणी हाजिर है। यदि आपका .xsession-errorsमुद्दा गलती पर है, तो वह इसे उजागर करेगा; यदि नहीं, तो यह अभी भी आपको सही दिशा में इंगित करने की संभावना है।

— बजे एक CVn

@effemmeffe UNIX में, किसी फ़ाइल को हटाने से वास्तव में इसे तब तक नहीं हटाया जाता है जब तक कि अंतिम हैंडल बंद न हो जाए (इस कारण आप हमेशा UNIX में एक फ़ाइल को हटा सकते हैं, जहां विंडोज में आपको "त्रुटियों आदि से" वंचित होना पड़ेगा)। तो .xsession-त्रुटियाँ फ़ाइल अभी भी है , आपके डिस्क स्थान को भरते हुए, क्योंकि जो भी त्रुटियों को लॉग कर रहा है वह फ़ाइल को खुला रखता है। इसे ठीक से ठीक करने का सबसे अच्छा तरीका यह पता लगाना है कि त्रुटियों का क्या कारण है और इसे ठीक करना है।

— मुजेर

यदि समस्या हटाए गए फ़ाइलों पर खुली फ़ाइल हैंडल के साथ है, तो सिस्टम को रिबूट करना "लापता आपको सभी को" जादुई रूप से वापस करना चाहिए। एक उपयोगी समस्या निवारण कदम हो सकता है।

— फ्लोरिस

Answer 1

आपके क्रोनजॉब के साथ समस्या यह है कि .xsession_errorsअभी भी कुछ अनुप्रयोगों या सिस्टम सेवाओं द्वारा खोला जाता है, यही वजह है कि इसे हटाए जाने पर फाइल सिस्टम तालिका से छिपा दिया जाएगा, लेकिन यह अभी भी डिस्क पर है और अभी भी त्रुटियों को लिखा जाएगा।
तो यह डिस्क को भर देगा, लेकिन अब आप इसे और नहीं देख सकते।

@rinzwind का लक्ष्य वास्तव में इस व्यवहार के लिए है जब वह (सही ढंग से) क्रोनजॉब को हटाने और त्रुटियों की तलाश करने का सुझाव देता है। इस समस्या को ठीक से ठीक करने का यही एकमात्र तरीका है।

वर्कअराउंड के रूप में आप .xsession_errorsफ़ाइल को इस तरह क्रोनजॉब के साथ काट सकते हैं :

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

लेकिन ऐसा करने से पहले आपको उन अंतर्निहित समस्याओं को ठीक करने का प्रयास करना चाहिए जो उन त्रुटि संदेशों को बनाते हैं .xsession_errors

Comments

@terdon मुझे / etc / crontab खुद को अधिक पसंद है: = D

— Rinzwind

@Rinzwind हालांकि एक उपयोगकर्ता के घर निर्देशिका में फ़ाइलों को संशोधित करने के लिए नहीं। कम से कम इसे उपयोगकर्ता के रूप में चलाएं और रूट के रूप में नहीं!

— टेराडॉन

@terdon, @rinzwind आप दोनों सही हैं: मुझे ध्यान देना चाहिए था। उपयोगकर्ता के रूप में इस स्क्रिप्ट को चलाने में rootलापरवाही होगी और कुछ अन्य समस्याएं पैदा हो सकती हैं।

— फिलिप -ज़्यान के ली- स्टॉकमैन

रोटेशन में विलोपन के समान ही समस्या है: कोडी पहचान नहीं पाएगी कि फ़ाइल घुमाई गई है और जब तक आप इस फाइल को फिर से खोलने के लिए सूचित नहीं करते, तब तक उसमें लिखना जारी रहेगा। (सबसे अधिक संभावना है कि ऐसी कोई बात नहीं है और आपको

— कोड़ी

@terdon truncate -cएक फ़ाइल नहीं बनाएगा और यह मौजूदा फ़ाइल के स्वामित्व को नहीं बदलेगा। इसे रूट के रूप में नहीं चलाना अच्छा है, लेकिन फ़ाइल का स्वामित्व एक कारण नहीं है।

— हॉब्स

Answer 2

मेरी डिस्क कौन भर रहा है?

जब से आप ऐसा करते हैं ...

मैंने पाया कि यह उबंटू में एक ज्ञात बग है और मैंने एक कॉन्टैब लाइन बनाने का हल किया है जो हर दस मिनट में .xsession-त्रुटियों को हटाता है।

इस प्रश्न का उत्तर देना असंभव है।

हमें जिन त्रुटियों को देखने की आवश्यकता है उन्हें प्राप्त करने के लिए कृपया निम्नलिखित का अनुसरण करें:

• उस कॉन्टैब लाइन को हटा दें जिसे आपने हटा दिया है .xsessions_errors।
• रिबूट और फिर कमांड लाइन से जांचें कि क्या .xsessions_errorsउपयोग कर रहा है tail -f 100 ~/.xsessions_errors।
• जब आपको कोई समस्या मिलती है जो बहुत बार दोहराई जाती है तो उनमें से कुछ को अपने प्रश्न में कॉपी कर लें।
• Crontab लाइन को वापस जोड़ें ताकि आप अपने सिस्टम का उपयोग कर सकें।
• समस्या के समाधान के लिए प्रतीक्षा करें और फिर आवेदन करें। फिर कॉन्टैब लाइन को फिर से हटा दें ( .xsessions_errorsफ़ाइल को हटाने से हमेशा बचा जाना चाहिए)।

Comments

"जब आपको कोई समस्या मिलती है जो बहुत बार दोहराई जाती है तो उनमें से कुछ को अपने प्रश्न में कॉपी कर लें।" नहीं, यह एक नया, अलग सवाल होगा।

— ऑर्बिट

अनुवर्ती: मैंने कॉन्टैब को हटा दिया और अब .xsession-error फाइल को विकसित करने के लिए स्वतंत्र है। लेकिन ऐसा नहीं है। और मेरा डिस्क स्थान अभी भी गिर रहा है। तो समस्या नहीं थी। एक रिबूट डिस्क को खाने से रोकता है, लेकिन मैं चाहूंगा कि हर दिन मशीन को रिबूट न ​​करें। कोई सुराग?

— effemmeffe

Answer 3

जब कोई बड़ा अंतर (कुछ प्रतिशत से अधिक) (रूट के रूप में) df -g /some/partition_rootऔर du -gx /some/partition_root( -xएक ही विभाजन के लिए डु को खुद को सीमित करने के लिए कहता है, उदाहरण के लिए '/' जांचने के लिए उपयोगी): वहाँ शायद फ़ाइल (ओं) अभी भी कर रहे हैं खोला कि कुछ प्रक्रियाएं अभी भी लिख रही हैं, लेकिन आपने डिस्क पर हटा दिया है (इसलिए: फ़ाइल अभी भी मौजूद है क्योंकि यह प्रक्रियाओं द्वारा खोला जाता है, और डिस्क स्थान को भरता है (df -g यह देखता है) लेकिन जैसा कि कोई भी नहीं है लंबे समय तक लिंक (या फ़ाइलनाम) इसके इनोड्स में, डु-जीएक्स उन्हें याद करते हैं।

आपके मामले में, के आउटपुट की तुलना करें:

df -g /
du -gx /

यह पता लगाने के लिए कि कौन सी फाइलें 1 से कम लिंक वाली हैं (यानी, हटाई गई फाइलें लेकिन अभी भी खोली गई हैं):

lsof -nP +L1  /

प्रक्रिया के नामों की जाँच करें और यह देखने के लिए कि कौन सी प्रक्रियाएँ हैं जो उन "भूत" फ़ाइलों को लिख रही हैं, और तदनुसार कार्य करें (कुछ आप को रोकने / शुरू करने में सक्षम हो सकते हैं, और जब उन्हें रोक दिया जाता है तो फ़ाइल रिलीज़ हो जाएगी और इसका स्थान मुक्त हो जाएगा, दूसरों को एक उचित रिबूट की आवश्यकता हो सकती है)

Comments

df -g मेरे ubuntu पर एक वैध कमांड नहीं है: root @ kodi: / home / fmf # df -g / df: अमान्य विकल्प - 'g'

— effemmeffe

@effemmeffe: उसके बाद उपयुक्त विकल्प का उपयोग करें (यदि aix; -H में सोलारिस) और डु के लिए इसी का उपयोग करें ...

— ओलिवियर दुलैक

मैं आपके उत्तर से नहीं मिल सकता कि विकल्प -g को क्या करना चाहिए, इसलिए मैं समकक्ष विकल्प की खोज नहीं कर सकता, क्या आप कृपया विस्तार से बता सकते हैं?

— effemmeffe

df या du पर linux पर ggababites का आकार दिखाता है

— Olivier Dulac

यह मेरे ubuntu में नहीं है। वैसे भी, मुझे मिल गया, धन्यवाद।

— 13