Miért fogy el a helyem???

Linux-kezdő

Van 2 gép is aminél jelentkezik az alábbi probléma.
Az egyik egy debianos gép CF kártyával. A másik egy EEE901-es SSD-vel. Lehet hogy nem a flash miatt fogy a hely, csak itt könyebben észreveszem. Mert az egyik 512MB-os a másik 12GB-os. Igy itt hamarabb szembetünik 1G lefoglalása.

A debianon napról napra folamatosan fogy el a hely. Már próbáltam megkeresni hogy hová tűnik el, de nem találom.
Az eee-n tegnap elfogyott használat közben. A tulajdonosa telörölt kb. 1-2 Gb-nyi anyagot. Ma ugyanugy nincs rajta hely. Init-2vel tudták csak indítani. De igy nincs Pendrive és SD kártya, menteni sem tud.

Hol keressem az elveszett bájtokat?

Debianon igy fogy a hely:
http://farm4.static.flickr.com/3654/3592506608_5edd93f919_o.png

  • 2825 megtekintés

( zoner | 2009. 06. 03., sze – 16:16 )

A /var/log/ -ban mi van?

Mi fut a gépen? Vagy egyáltalán mik ezek?

Az eee azt egy sima gép. r=1 használja fedorával.
A debianon egy daemon fut, az alap dolgokon kivül, de az nem generál helyfoglalást.
pl a debiannnál a /var/log igy néz ki: 

debian:/var/log# du -c | sort -n
1	./lighttpd
1	./news
4	.
4	total

( zwei | 2009. 06. 03., sze – 16:20 )

gumicsizmás módszer, de gyakran használ:

cd /
du -sk * | sort -n

aztán a legnagyobb méretű könvtárban ugyanezt megismételni ... stb.

/var/cache/apt-ban találtam olyan dolgot ami helyet foglalt de elvileg nem volt benne semmi fájl. Könyvár törlése után 18M felszabadult.
Valószinü a debianos 512-es dolgot cserélni fogom egy gentoo-ra vagy valamire, ami csak azt csinálja amit én akarok. Esetleg LFS lesz a vége.

Perlben csináltam régebben egy ilyen kis cuccot, ami dbm-be mentette le a könyvtárak méretét, és meg tudta mondani, hogy az adott időszakban mik voltak amik a legtöbbet híztak.

Nem tudtam, de a wikipediaban is benne van. :)
Szerintem már nincs olyan 3 betűs kombináció, ami ne lenne valami kütyünek a neve...

Es az "ánc" mennyi? En aszittem, csak nagyanyamek mondtak igy, de nem, Bulgakov: Mester es Margaritajaban is igy van (Korovjov penzt ada a lakobizottsag elnokenek) Lehetne forditoi eliras is, de megvan aviban, eredeti orosz hanggal es ott is "ánc, cváj, dráj"
a kiejtes :) (A tobbi orosz :)

igen a negyszogekrefelosztos
egyebkent ha a filelight fent van, az is megjelenik a tealtalad emlitett menuben(a file nezet mellett)
ugyhogy hajra sudo apt-get install filelight

aztan vannak meg kulonbozo prgok, pl az xcruise, aminel a filerendszered az univerzum, az alkonyvtarak a galaxisok, a file-ok a bolygok, a linkek pedig fereglyukak, te pedig 3d-ben jarkalhatsz ezek kozott, vannak ennel sokkal latvanyosabbak is, jarkalhatsz a filerendszeredben 3d-ben.
persze ezek mind csak allatsagok

ff ~/.mozilla alatt szemetel.
vedd le a cache-t(alapesetben 50MB) és hogy törölje az
ff bezárásakor.

cron-apt fennt van? mer az is tud dolgozni, ha nem
megfelelően van configolva.
apt-get clean
ad + szabad helyet?

szerk.
nekem 4GB-os microdrive-n volt kb 300MB szabad hely volt de nem szemetelte tele.

( zhali | 2009. 06. 03., sze – 19:57 )

Nekem nemrégiben az UHU-m /home-járól fogyott el az összes helyem, mire nagy nehezen rájöttem, hogy a .thumbnails könyvtár lett tele az előnézeti képekkel, amikor a fényképeimet rendezgettem a gépen.

( igiboy | 2009. 06. 03., sze – 20:25 )

/var/log-ból le lett törölve 4 gb-nyi dolog, de a helyet nem adta vissza.
du -c | sort -n el nézve
===================== elötte ========================= 

[ivett@eee901w log]$ du -c | sort -n
du: a következő könyvtár nem olvasható: ”./samba”: Hozzáférés megtagadva
du: a következő könyvtár nem olvasható: ”./gdm”: Hozzáférés megtagadva
du: a következő könyvtár nem olvasható: ”./audit”: Hozzáférés megtagadva
du: a következő könyvtár nem olvasható: ”./ppp”: Hozzáférés megtagadva
du: a következő könyvtár nem olvasható: ”./httpd”: Hozzáférés megtagadva
4	./bittorrent
4	./dirmngr
4	./gdm
4	./httpd
4	./ntpstats
4	./ppp
4	./samba
4	./setroubleshoot
4	./vbox
8	./mail
60	./prelink
564	./ConsoleKit
856	./cups
4577048	.
4577048	összesen
[ivett@eee901w log]$ 

[ivett@eee901w ~]$ df -h
Fájlrendszer         Méret  Fogl. Szab. Fo.% Csatl. pont
/dev/sdb1              15G   14G 1007M  94% /
/dev/sda3             2,5G   74M  2,3G   4% /tmp
/dev/sda1             190M   26M  155M  15% /boot
tmpfs                 501M   76K  501M   1% /dev/shm

============= utánna ============== 

[root@eee901w log]# du -c | sort -n
4	./bittorrent
4	./dirmngr
4	./httpd
4	./ntpstats
4	./ppp
4	./samba/old
4	./setroubleshoot
4	./vbox
8	./mail
8	./samba
60	./prelink
416	./gdm
564	./ConsoleKit
856	./cups
1876	./audit
3820	.
3820	összesen

[ivett@eee901w ~]$ df -h
Fájlrendszer         Méret  Fogl. Szab. Fo.% Csatl. pont
/dev/sdb1              15G   14G 1020M  93% /
/dev/sda3             2,5G   74M  2,3G   4% /tmp
/dev/sda1             190M   26M  155M  15% /boot
tmpfs                 501M   76K  501M   1% /dev/shm

Na erre varjon valaki gombot!

Sajnos a gépet nem tudom elérni mert 6 router mögött van.

Azért itt lett kiadva mert látszik is hogy ebben van 4G-nyi foglalás. A másodikon látszik hogy törölve lett. Ami nem látszik az az hogy rm -f * volt a parancs.
Majd a hely ugynaugy áll, bár a könyvátárból eltünt 4G.
ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ-ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Kicsit drasztikus megoldás, de lényeg hogy működött :)
Egy "sudo /etc/init.d/sysklogd restart" is megtette volna.

Ja és ha nem akarod, hogy ilyesmi előforduljon, akkor az /etc/logrotate.d/-n belül nézz körül és állítsd szigorúbbra a bűnös logok rotate szabályait. Mondjuk ha 1 nap alatt gyűlt össze a 4 giga akkor ez se segít :)

Jót javasolsz; az alábbiakat fűzném hozzá:

  • Én az összes shell-emben (interaktív és script egyaránt) beállítom a
    -C

    (más néven 

    noclobber

    ) opciót, melynek hatására sima output átirányításkor (

    >

    ) meglévő file nem csonkolódik, hanem az átirányítás sikertelen. Az append persze működik (

    >>

    ), illetve lehet a csonkolást kényszeríteni is (

    >|

    ). Szerintem ez hasznos elővigyázat; ha valakinél ez érvényben van, akkor a javaslatod 

    >|

    operátort használ.

  • Nyilván pongyola voltál csak, de azért leírom: nem "EOF-fal felülírásról" van szó az ajánlott módszerben, hanem egy megfelelően paraméterezett
    open()

    syscall-ról, amit nem követ 

    write()

    .

  • Sajnos nagyon gyakori az alkalmazásoknál ill. átirányítást használó script-eknél, hogy a naplókat nem append módban írják. Ennek az a követetkezménye, hogy csonkolás és helyfelszabadulás után az alkalmazás következő írásakor a file description-ben (nem descriptor-ban!) lévő offset a következő íráskor nem követi a csonkolást, vagyis egy sparse file fog létrejönni: az elején irdatlan mennyiségű
    '\0'

    , ami helyet ugyan nem foglal, viszont a naplót nézhetetlenné teszi. Minden naplót append módban nyissunk meg!

Egy kis összefoglaló a különféle (csak) kimeneti átirányításokkal egyenértékű 

open()

flag-ekről -- nem biztos, hogy minden shell így implementálja ezeket, csak ez az értelme. Az 

O_WRONLY | O_CREAT

bitmaszkot nem írom ki, mindenhol hozzá-vagy-olandó fejben. 

  • set +C

    esetén:

    • >

      és 

      >|

      : 

      O_TRUNC
    • >>

      : 

      O_APPEND
  • set -C

    esetén 

    >|

    és 

    >>

    változatlanok, viszont

    • >

      : 

      O_EXCL

( hud | 2009. 06. 03., sze – 22:35 )

Eddig még nem írták: ha sok kernel van fent (főleg, ha header-ekkel), akkor az is foglalhat több száz megát. Általában elegendő az utolsó verziószámút meghagyni.

( uid_2716 | 2009. 06. 04., cs – 15:04 )

Látatlanban ajánlom (teljesen véletlenül botlottam bele a minap), de úgy tűnik, a gt5 nevű programot pontosan erre a célra hozták létre:

Years have passed and disks have become larger and larger, but even on this incredibly huge harddisk era, the space seems to disappear over time. This small and effective programs provides more convenient listing than the default du(1). It displays what has happened since last run and displays dir size and the total percentage. It is possible to navigate and ascend to directories by using cursor-keys with text based browser [...]