Rejtélyes tárhelyproblémák – avagy a disk és a kernel viszonya

Az utóbbi néhány napban a szerverem lévő root partíción – ami egy 60G ssd – hirtelen a foglalt terület felkúszott átlag 55%-ról fokozatosan 100%-ig, 0b szabad, a rendszer megáll és nem értem mi történt.

Az első kör

du -sh * / --exclude <azon könyvtárak, melyekbe a diskek vannak felcsatolva>

Nem találtam semmi érdekeset. De szabad hely fokozatosan elfogyott és megszűnt.

Akkor újraindítjuk a rendszert hátha egyszerűen nincs szinkronban a disk foglalt területe a rendszer által “tudottakkal”. Tehát feltételeztem azt, hogy a rendszer valamit csinált (lehet frissítés vagy programhiba), televerte a disk-et, majd leállt, a hely felszabadult (tehát nem megszámlálható, nem látható), csak erről a kernel maga már/még nem tud.

Szóval újraindítottam. Hely ugyanúgy nincs, a szolgáltatások bő fele már el sem indult.

Töröltem a logokat, még mindig ugyanaz a helyzet. Letiltottam néhány service-t amire gyanakodtam, hogy problémázhatnak, majd újraindítottam ismét a gépet. Lett hely ismét, hurrá! Nem világos miért, de hurrá. Amúgy itt követtem el már a második bakimat.

Eltelt egy nap, majd figyelem a muninon, hogy az elmúlt napokban folyamatosan egy fűrészfog mintát sikerült rajzolni a >szépen lassan megtelik a tárhely, majd törlök valamit és újra lesz hely< alapon. És meglátom, hogy ismét ugyanabban a mértékben foly a hely.

Hogy kiderítsem mi okozza a balhét kicsit utánnakutattam és láttam példát, hogy du-t hogyan lehet hatékonyabban használni – konkrétan sorbarendezés, total számítás.

Ebből megszületett ez, amit a / helyen futtatok:

 du -sch * --exclude home --exclude disks | sort -h

És itt szembesültem vele, hogy az apache2 egy nap alatt kb 11G-nyi error.log-ot termel. Botok rátévedtek a szerveremre ahol folyamatosan olyan hívást csinálnak ami php hibát okoz ezért a hibajelentés oda bekerül.

Mit rontottam el?

Először is nem sorrendeztem így elsiklott a szemem felett a du által számolt terület kb/GB eloszlása és nem vettem elsőre észre, hogy az apache2 okozza a balhét.

Második. Ha töröltem a /var/log-ot korábban miért nem szabadult fel a hely? Az alkalmazás az access.log-ot és az error.log-ot nyitva tartja. Valami rejtélyes oknál fogva engedi az OS, hogy töröljem az appendelt fájl-t, de ennek ellenére továbbra is írja azt a kernel, tehát nincs felszabadult terület. Szerinte. Mert hogy még a fájl valószínűleg nyitva marad.

Egy egyszerű

systemctl restart apache2

után újra megjelent 55% foglalt terület és mindenki boldog.

Most már csak a php hibát kell kiküszöbölni, hogy ne legyen tele az apache error log ezekkel. 🙂

DJI + Huawei P20 Pro + Sony vegas – fix

Egy ideje felfigyeltem rá, hogy a DJI go app – ami egy elég jól sikerült darab, pacsi a fejlesztőknek, elég jól lehet használni, ha van egy osmo mobile-od – hajlamos elrontani a felvételt.

Ez abban nyilvánul meg, hogy visszanézve google photos-ra felszinkronizálva minden rendben, VLC, wmplayer is rendben játsza ellenben a Sony Vegas 15 importáláskor a fájlt elrontja/rosszul olvassa be/whatever. Ekkor a kép vagy akadozik vagy hiányzik eleje vagy vége, vagy – és ami a leggyakoribb – a kép a hangtól el-el csúszik.

Ami valljuk be rendkívül bosszantó.

Viszont ahelyett, hogy tovább hőbörögnénk és követelnénk vissza a pénzünket járjunk utána, hogy mit lehet e jelenség ellen tenni.

Lényeg, hogy kell egy ffmpeg és mondjuk egy linuxos bash és az alábbi script-et a fájlok helyén lefuttatjuk:

mkdir fixed;
for i in *.mp4 ; do
    ffmpeg -i $i -preset slow -strict experimental -c:a aac -b:a 192k -codec:v libx264 -pix_fmt yuv420p -b:v 11000k -minrate 11000k -maxrate 14000k -bufsize 14000k -vf scale=-1:1080 fixed/$i.mp4
done

Ez 1080p30 esetén – 4K vagy 1080p60 esetén valszeg magasabb bitrátát kell beállítanod – a fájl tulajdonságai között megtalálod a megfelelő értékeket!

Ekkor készül egy fixed nevezetű mappa és feldolgozás után ott fognak sorakozni a tökéletesen használható nyersanyagok 🙂

Btw ha nincs bash-ed windowson varázsolj egyet rá, vagy írd meg ennek a Windowsos változatát (ami végigiterál a mappa mp4-es elemein) és küldd el nekem és update-elem a postot 🙂

Digionline verzió: v1.0.7

Ami javításra, frissítésre került az utolsó (v1.0.3) postom óta:

v1.0.7

  • Tartalmazza az elektronikus programújság (EPG) azon javítását amikor egy-egy csatornán más csatorna műsorai jelentek meg tévesen
  • Raspberry pi és egyéb vékonyklienseken az EPG betöltése közben fellépő lassulás kiküszöbölésre került
  • EPG műsorok eltolódási javítása
  • update.sh bevezetése, melynek futtatásával nullázódik az epg cache és a legújabb digionline programverzió kerül letöltésre
  • A közszolgálati csatornák indítási problémáinak javítása
  • DIGIFILM -> FILMNOW átállás EPG-ben való átvezetése
  • Teljes telepítő melléklet OSMC rendszerre

Frissítés a legújabb verzióra

Állj a projekt mappájába, például:

cd /home/osmc/digionline

git pull origin master

További infók:

https://github.com/szabbenjamin/digionline

bash root-ként

Van néha, hogy olyan bash scriptet írunk amit mindenképpen root módban kell futtatnunk – legyen az telepítő vagy valami varázsló.

Nekünk viszont varázsolnunk nem kell csak ennyit beszúrni a kódunk elejébe:

#!/bin/bash
if [ "$EUID" -ne 0 ]
   then echo "Légyszi futass root módban! :)"
fi

Az EUID bash-ben a userid-t reprezentálja. Azért használunk euid-t uid helyett, mert nem az eredeti hanem az aktuális user id-ra van szükségünk.

És azért nézzük, hogy nulla-e, mert a root mindig nullás uid-dal jár. 🙂

Digionline servlet frissítés (v1.0.3)

Stabil ágra kikerült egy új főverzió.

v1.0.3
* 12 percenként megállásra hibajavítás
* TVHeadend támogatás
* Program indításának gyorsítása az által, hogy az EPG újratöltése 2 naponta történik és nem minden indításkor
* Minőség beállítására új struktúrájú config.js fájl
* Program stabilitás javítása

További infók: Frissítési tudnivalók

Ezúttal is köszönök minden visszajelzést! 🙂