Lemezterület módosítása
csuhas32
Elnézést de váratlanul kellett elmennem. elfoglalt hely:
Lemezek:
Lemezhasználat:
/usr/lib 6,7GB, /usr/share 2,4 GB, /var/lib 22 GB, /var/log 11.6 Gb
Én a foglaltságot a Lemezek alapján adtam meg, de lehet látni nagy a különbség a két adat között okát nem tudom.
A Log könyvtárban több syslog fájl van mind nagy de egy syslog.1 8,6 GB. Mindenkinek köszönöm a válaszát.
- Szerkesztve
KiralyMarta /var/lib 22 GB
És nincs kedved a Lemezhasználat-elemzőben a kis füleket lejjebb nyitogatni, hogy mégis mi a /var/lib-ben 22 GB? (Nálam ugyanez 3,9 GB)
KiralyMarta /var/log 11.6 GB
syslog.1 8,6 GB
Én biztos vagyok benne, hogy egy 8 GB-os logfájlt nem fogsz végigolvasni, talán nem is tudja a rendszered megnyitni.
Magam ezt (meg a többi) nagy méretű logfájlt sudo rm -rf
-fel szanálnám.
Előtte persze rendszergazdai joggal szerkeszteném a /etc/systemd/journald.conf fájlt és beletenném a
SystemMaxUse=50M
sort, hogy az újonnan létrejövő logfájlok majd már ne hízhassanak 50 MB-nál nagyobbra. (Lehet, hogy utána kell egy rendszer újraindítás, ezt nem tudom biztosra megmondani.)
Ez persze csak tüneti kezelés, utána jöhet a létrejövő kezelhető méretű logfájlok megnyitása, annak megkeresése, hogy miért logol folyton a rendszer és a hiba elhárítása.
Ezt követően a rendszerpartíciód foglaltsága máris csak 36 GB körül lesz a cirka 1000 GB-ból.
Talán tudunk majd még lejjebb is menni, ha megismerjük, mi van a /var/lib alatt, de szerintem már ez is eléggé kis szám, csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.
Amikor nekem kellett átméretezést csinálni és gparteddel csináltam live-ban. Picike, de jól működő program.
50 GB-nál többet nem szoktam a rendszerpartíciónak adni, eddig mindig elég volt.
- Szerkesztve
csuhas32 hogy mégis mi a /var/lib-ben 22 GB?
Lefogadom, hogy /var/lib/snapd/ méretes lesz (oda mennek a szappan darabok).
csuhas32 /var/log 11.6 GB
Itt én is sejtek spórolási lehetőséget. Nálam 30MB most éppen...
csuhas32 csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.
Még ezt is sokallom, de nem az én rendszerem.
rapfen 50 GB-nál többet nem szoktam a rendszerpartíciónak adni,
️
Dettó. Csak tényleg indokolt esetben!
klt Még ezt is sokallom, de nem az én rendszerem.
Igazából ma nem is illik engedni a '48-ból, ha te rendszered lenne ragaszkodnék ehhez.
Itt nagyságrendileg 500 GB-ról kezdjük az alkudozást, ha 120-ra le tudunk menni, szerintem szép eredmény.
Majd egy következő lépésben megfelezi a 120-at és akkor is megmarad a működő rendszere plusz lesz egy tartalék rendszerpartíciója egy másik rendszer számra. :-)
(Nálam már az 50 GB körüli rendszerpartíció is olyan „sose telik be, ne kelljen már figyelni rá még egy kicsit se” szándékos túlzásnak számít, a 120 GB még akkor is elég lesz szerintem, ha Márta véletlenül néha félrenyúl.)
klt
Nálam a /var/log/journal mappa hízott folyamatosan.
Mígnem meguntam, és egy root script minden rendszer indításkor törli a tartalmat.
https://ibb.co/G4Xnn12r
Mivel, octet-stream fájlokról van szó, van mivel megnyitni/megnézni őket?
En nem ismerek ilyet.
- Szerkesztve
csuhas32
/var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet. Log fájlal nem tudtam mit lehet kezdeni de megcsinálom amit mondasz.
KiralyMarta Log fájlal nem tudtam mit lehet kezdeni
sudo journalctl --vacuum-time=5m
Ezt így próbaképp...
csuhas32
Mielőtt futtatnám sudo rm -rf fájlnév egyenként?n itt több log fájlból is van több darab azokat is törölhetem?
Összesen 8,3G
drwxrwxr-x 18 root syslog 4,0K márc 15 07:11 .
drwxr-xr-x 15 root root 4,0K febr 10 15:43 ..
-rw-r--r-- 1 root root 1,4K márc 11 14:02 alternatives.log
-rw-r--r-- 1 root root 3,8K febr 19 10:24 alternatives.log.1
-rw-r--r-- 1 root root 459 jan 29 06:55 alternatives.log.2.gz
-rw-r--r-- 1 root root 236 dec 22 09:05 alternatives.log.3.gz
-rw-r--r-- 1 root root 872 nov 30 07:14 alternatives.log.4.gz
-rw-r--r-- 1 root root 545 okt 24 06:01 alternatives.log.5.gz
-rw-r--r-- 1 root root 4,2K szept 30 08:37 alternatives.log.6.gz
-rw-r--r-- 1 root root 4,9K aug 29 2024 alternatives.log.7.gz
-rw-r----- 1 root adm 0 márc 13 06:54 apport.log
-rw-r----- 1 root adm 112 márc 12 16:25 apport.log.1
-rw-r----- 1 root adm 134 márc 2 13:28 apport.log.2.gz
-rw-r----- 1 root adm 116 márc 1 17:52 apport.log.3.gz
-rw-r----- 1 root adm 134 febr 23 17:55 apport.log.4.gz
-rw-r----- 1 root adm 134 febr 7 15:48 apport.log.5.gz
-rw-r----- 1 root adm 268 febr 1 11:45 apport.log.6.gz
-rw-r----- 1 root adm 215 jan 18 07:26 apport.log.7.gz
drwxr-xr-x 2 root root 4,0K márc 13 07:26 apt
-rw-r----- 1 syslog adm 150K márc 15 13:02 auth.log
-rw-r----- 1 syslog adm 257K márc 9 07:15 auth.log.1
-rw-r----- 1 syslog adm 11K márc 2 07:16 auth.log.2.gz
-rw-r----- 1 syslog adm 27K febr 23 06:54 auth.log.3.gz
-rw-r----- 1 syslog adm 27K febr 16 07:27 auth.log.4.gz
-rw------- 1 root root 5,2K márc 15 07:11 boot.log
-rw------- 1 root root 23K márc 15 07:11 boot.log.1
-rw------- 1 root root 35K márc 14 07:04 boot.log.2
-rw------- 1 root root 24K márc 13 06:54 boot.log.3
-rw------- 1 root root 22K márc 12 07:00 boot.log.4
-rw------- 1 root root 23K márc 11 07:04 boot.log.5
-rw------- 1 root root 12K márc 10 07:12 boot.log.6
-rw------- 1 root root 23K márc 9 07:15 boot.log.7
-rw-r--r-- 1 root root 106K aug 9 2022 bootstrap.log
-rw-rw---- 1 root utmp 0 márc 1 07:24 btmp
-rw-rw---- 1 root utmp 0 febr 1 07:30 btmp.1
drwxr-xr-x 2 root root 4,0K márc 15 07:11 cups
drwxr-xr-x 2 cups-browsed lpadmin 4,0K szept 22 19:01 cups-browsed
drwxr-xr-x 3 root root 4,0K szept 22 19:24 dist-upgrade
-rw-r----- 1 root adm 92K márc 15 07:11 dmesg
-rw-r----- 1 root adm 92K márc 14 18:33 dmesg.0
-rw-r----- 1 root adm 23K márc 14 07:04 dmesg.1.gz
-rw-r----- 1 root adm 22K márc 13 18:56 dmesg.2.gz
-rw-r----- 1 root adm 22K márc 13 16:04 dmesg.3.gz
-rw-r----- 1 root adm 23K márc 13 06:54 dmesg.4.gz
-rw-r--r-- 1 root root 132K márc 13 07:26 dpkg.log
-rw-r--r-- 1 root root 350K febr 23 08:14 dpkg.log.1
-rw-r--r-- 1 root root 6,8K jan 29 06:56 dpkg.log.2.gz
-rw-r--r-- 1 root root 12K dec 28 16:08 dpkg.log.3.gz
-rw-r--r-- 1 root root 16K nov 30 07:14 dpkg.log.4.gz
-rw-r--r-- 1 root root 11K okt 31 06:46 dpkg.log.5.gz
-rw-r--r-- 1 root root 174K szept 30 08:37 dpkg.log.6.gz
-rw-r--r-- 1 root root 152K aug 31 2024 dpkg.log.7.gz
-rw-r--r-- 1 root root 32K szept 22 19:25 faillog
drwxr-xr-x 2 root root 4,0K febr 9 2022 firebird
-rw-r--r-- 1 root root 15K márc 11 14:02 fontconfig.log
drwx--x--x 2 root gdm 4,0K aug 21 2024 gdm3
-rw-r--r-- 1 root root 1,9K márc 15 07:11 gpu-manager.log
-rw-r--r-- 1 root root 1,9K márc 15 12:31 gpu-manager-switch.log
drwxr-xr-x 3 root root 4,0K aug 9 2022 hp
drwxrwxr-x 2 root root 4,0K aug 21 2024 installer
drwxr-xr-x 2 root root 4,0K febr 10 15:43 ipp-usb
drwxr-sr-x+ 3 root systemd-journal 4,0K aug 21 2024 journal
-rw-r----- 1 syslog adm 2,2M márc 15 13:02 kern.log
-rw-r----- 1 syslog adm 2,9M márc 9 07:15 kern.log.1
-rw-r----- 1 syslog adm 115K márc 2 07:16 kern.log.2.gz
-rw-r----- 1 syslog adm 306K febr 23 06:54 kern.log.3.gz
-rw-r----- 1 syslog adm 308K febr 16 07:27 kern.log.4.gz
-rw-rw-r-- 1 root utmp 286K szept 22 19:25 lastlog
drwxr-xr-x 2 root root 4,0K márc 22 2022 openvpn
drwx------ 2 root root 4,0K aug 9 2022 private
lrwxrwxrwx 1 root root 39 szept 22 18:54 README -> ../../usr/share/doc/systemd/README.logs
drwx------ 2 speech-dispatcher root 4,0K júl 21 2022 speech-dispatcher
-rw-r----- 1 syslog adm 285M márc 15 13:04 syslog
-rw-r----- 1 syslog adm 8,0G márc 9 07:15 syslog.1
-rw-r----- 1 syslog adm 630K márc 2 07:16 syslog.2.gz
-rw-r----- 1 syslog adm 1,7M febr 23 06:54 syslog.3.gz
-rw-r----- 1 syslog adm 15M febr 16 07:27 syslog.4.gz
drwxr-xr-x 2 root root 4,0K jan 9 2024 sysstat
-rw-r--r-- 1 root root 0 szept 22 18:34 ubuntu-advantage-apt-hook.log
-rw-r--r-- 1 root root 0 szept 23 07:04 ubuntu-advantage.log
-rw-r--r-- 1 root root 2,7K szept 22 19:07 ubuntu-advantage.log.1
drwxr-x--- 2 root adm 4,0K márc 1 07:24 unattended-upgrades
drwxr-xr-x 2 root root 4,0K szept 22 19:07 upgrade
-rw-r--r-- 1 root root 102 márc 6 07:25 vbox-setup.log
-rw-r--r-- 1 root root 102 márc 2 12:02 vbox-setup.log.1
-rw-r--r-- 1 root root 102 febr 12 18:42 vbox-setup.log.2
-rw-r--r-- 1 root root 102 jan 29 15:32 vbox-setup.log.3
-rw-r--r-- 1 root root 102 jan 28 00:17 vbox-setup.log.4
-rw-rw-r-- 1 root utmp 650K márc 15 07:12 wtmp
root@marta-ubuntu:/var/log#
KiralyMarta A ###.szám.log és .gz simán törölheted, de szerintem nem érdemes görcsölni rajta. Alig jelent nyereséget. Neked a journal alatt lesz a sok szemét, arra meg jó a porszívózás, amit adtam.
KiralyMarta Én itt egyetlen óriási fájlt látok, csak arra adnám ki a
sudo rm -rf /var/log/syslog.1
parancsot. A kicsikkel nem kell foglalkozni, semmi jelentőségük, nem zavarnak senkit és semmit, viszont lehet van bennük értékes információ, azokat nem bántanám.
- Szerkesztve
OFF
Azért érdekes, hogy a Windows van elkönyvelve egy végletekig feleslegesen növekvő rendszerré, miközben itt mindenkinek megvan a maga trükkje, hogyan szoktassa le erről a Linuxot.
Az ok amiért én más tárhely mértekben gondolkodom, nem feltétlen a Windows-Linux eltérésekből adódik, hanem mert egy ideje rászoktam arra, hogy a rendszer és a tárhely valóban külön fizikai meghajtón van. Így rendszerre a manapság elérhető legkisebb SSD méretekben gondolkodom 128/256. Mivel ezeknek csak a rendszer futtatása a feladatuk, nincs ok a méretek csökkentésére.
Egy 2TB-os tároló ilyen felosztása azért nem egy szokványos megoldás.
ON
Ezt viszont te találtad el:
KiralyMarta var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet.
Szerintem lassan megvagyunk, most már elegendő az információ, Márta el tudja dönteni mekkorára szeretné zsugorítani a rendszerpartícióját, a módja pedig már régen nem kérdés.
A Snap és a Flatpak esetén is előfordul, hogy egy app futtatásához, egy nagyságrendileg nagyobb csomag letöltésére is szükség van (hiszen nincs benne az alaprendszerben). Miután ezt automatikusan teszi meg, okozhat meglepetést.
tenkes OFF:
Ami a Win-t illeti, hozzám csak a problémás esetek jutnak el.
A csak hízásos WibSxS valós probléma, többször nőtte ki a tárhelyet (tényleg kicsi, 128GB-os meghajtón) és csak az újratelepítés segít olyankor, nem ismerek olyan segédprogramot, ami azt lefogyasztja (a lemezkarbantartó sem).
Ezt meg tudom különböztetni attól, amikor egy Windows.old ottmarad, és az foglalja el a helyet.
Nyilván nem mindenhol okoz gondot az említett hízás, ahogy nálad sem. Az sem kizárt, hogy valamilyen fura felhasználói szokás van a háttérben.
Ami Linux trükköket illeti: feltűnt, hogy az én gépeimen (mindenhol Debian megy, 11 vagy 12, armv7l, arm64, amd64 architektúrákon) és ilyen hízásgátló izék nem sehol sem kellenek.
Szerintem ez egy Ubuntu specifikus dolog lesz.
ON
KiralyMarta Akkor én is hozzáteszek valamit a többiek válaszaihoz.
Van ez a két fájl:
-rw-r----- 1 syslog adm 285M márc 15 13:04 syslog
-rw-r----- 1 syslog adm 8,0G márc 9 07:15 syslog.1
A régi nagy, semmi nem fogja megnyitni. Töröld, ahogy csuhás barátunk javasolta.
DE!
Az aktuális syslog még kicsi (285M) ez megnyitható, megnézhető. Én azért belepislantanék, hogy miket tartalmaz.
És megtenném ezt holnap is, holnapután is (főleg, ha úgy néz ki, hogy szintén hajlamos a hízásra), hogy lássam, mi okozza.
Lehet az is, hogy amitől megnőtt az előbbi, az csak egy időlegesen bekavaró hiba volt és az aktuális syslog már nem fog nőni.
klt OFF
A WinSxS trükkös, szereti magát jóval nagyobbnak mutatni, gondolom már találkoztál vele, de itt a lényeg:
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/determine-the-actual-size-of-the-winsxs-folder?view=windows-11
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/clean-up-the-winsxs-folder?view=windows-11
ON
Htibi Nem tudom mi számít hízásnak. Megcsináltam csuha32 javaslatát kitöröltem a syslog.1-et és beírtam a fájl korlátnak az 50M, és újra indítottam a rendszert. A syslog fájl előtte: 291363K, újraindítás után: 291943K a méret. Nem tudom ez kicsi vagy nagy.