Hogy miért érdekelnek az áramszünetek?

Ma reggel a Spar-ban, a reggeli elemózsiámat begyűjtve várok a soromra a pénztárnál, majd a teljes áruházban hirtelen minden lámpa, kijelző, led elsötétedett nagyjából 2-3mp-re.

Az emberek nyilván megijedtek – ennek hangját is adták -, a pénztárosok meg b*zmegoltak egy jó nagyot. Félreértés ne essék, nem katasztrófatúrista vagyok az ilyen szituációkban, csak kíváncsi vagyok, hogy a jelen, modern korban

  1. hogyan képes az ember és önmagában a társadalmunk villany nélkül boldogulni
  2. milyen óvintézkedéseket tettek a hálózat kiépítésére bízott mérnökök az ilyen helyzeteket lekezelendő.

Ha arról van szó, hogy napközben, vagy este elmegy otthon a lakásban az áram alapesetben annyit érzékelünk belőle, hogy nincs lámpa, nem működik a tv, nincs wifi. Majd kis idő elteltével elkezdünk aggódni a hűtőnk tartalmáért, illetve a villanyt (is) használó kazán miatt.

A kazán dolog áramkimaradás esetén amúgy egy érdekes téma, valamiért a szerelők sosem számolnak azzal a lehetőséggel – főleg falun -, hogy mi történik ha például egy tervezett karbantartás vagy meghibásodás miatti fél napos áramkimaradás van és nincs alternatíva a fűtésre. Mert ugyebár gáz van a fűtéshez, csak villany nincs ami miatt a kazán elektronikája nem működik, keringető szivattyú nem jár, így a fűtés megáll.

Visszatérve Spar-ra.

Miután visszajött az áram – az egy dolog, hogy nem volt vészhelyzeti/tartalék világítás a sötétben – azt kezdtem el figyelni, hogy vajon mely rendszerek lesznek azok amik leálltak, lefagytak, elkezdtek éppen újraindulni.

Meglepő volt – és ahogy figyeltem a kasszás hölgynek is -, hogy a kassza gép nem állt le, el sem veszett az aktuálisan beblokkolt termékek listája, csak várt kb 10 mp-et, gondolom ennyi ideig tartott míg a monitor előtte vissza bekapcsolt és csekkolta, hogy minden ugyanaz maradt-e a képernyőn.

Az előttem lévő fizetett kp-ban, majd következtem én, aki éppen szokásához híven mobillal fizetett (volna), de már sejtettem előre, hogy ez holtbiztos nem fog működni, mert a szalagot irányító/hajtó rendszer is megállt, így kézzel pakolgattuk előrébb rajta a cuccainkat, így már én is készítettem a kp-t. A blokkolás után a terminált a hölgy fordítja elém, odaérintem a telefont és “kapcsolódási hiba”. Még kétszer újrapróbáltuk, semmi változás. Közben egyébként a húspult felől is kiabálnak előre, hogy a szalagnál működik-e a pénztárgép – valszeg hátul a mérleg és hasonló más digitális kütyü bedobta a törülközőt.

A Spar-ban ahogy figyelem a kasszásoknak nincs jogosultságuk a bankkártyás POS terminálok újraindításához, így ha az egyik soron meghibásodik akkor “nem lehet kártyával fizetni” csak a válasz. Ha egy étteremben történik ilyen akkor vagy a terminál menüjében újrakapcsolódást, újraindítást nyomnak, vagy kiveszik az akksit és visszadugják ahhoz, hogy a kütyü visszacsatlakozzon a hálózathoz.

Miért probléma legtöbb esetben az áramszünet?

A válasz banális – az eszközök hardverét és szoftverét nem ugyanaz a csoport fejleszti, így mind a két oldal csak feltételezi azt, hogy a másik megfelelően lekezeli az ilyen kimaradásokat. És ha odafigyelnek is, nem lehet/akarják/tudnak felkészülni az ilyen lehetetlen helyzetekre.

Az áramingadozások, rövid kimaradások terhelhetik az elektronika tápellátását. Előfordulhat az az eset, hogy nem kap rendes üzemi feszültséget a készülék, de olyan időpillanatban tér vissza még a villany, hogy a tápegység nem szűnt meg teljes mértékben működni (kondenzátor kisülés), a készülék ismét áramot kap, de részleges kihagyás miatt részegységek, vagy maga a hardver abnormális állapotba került, így jó eséllyel az eszköz lefagyott.

Ezt a problémát leggyorsabban innentől már csak egy teljes újraindítás oldhatja meg. De ha egy teljes eszközhálózatról van szó – mondjuk a POS terminálról ami internetes hálózaton van és lehet a terminál nem állt meg, de az internethez csatlakozó switch-ek, routerek, szerverek igen – akkor meg kell várni, hogy vagy a hálózat minden komponense vissza helyreáll, ha nem akkor a technikai munkatársaknak kell detektálni mely eszköz esett ki és szorul karbantartásra.

Hogyan lehet ezt a problémát orvosolni akár a saját otthonodban is?

A legtöbb esetben egy szünetmentes tápegység a te barátod. Ez az eszköz arra szolgál, hogy a biztosítandó eszköz és a dugalj (mondjuk fali konnektor) közé beiktasd – van benne egy akkumulátor, általában ezeken vagy számítógépekhez direktbe köthető “monitor tápkábel” csati van, vagy sima, hagyományos, 230V-os aljzat. Ha van “fali áram” az akku benne szépen lassan feltöltődik és közben a rákötött eszközödet is ellátja a fali árammal. Ha áramingadozás lép fel – ebbe beleérthető teljes áramszünet, ingadozás, túláram, fél fázis, sőt akár villám is – a másodperc töredéke alatt átveszi a biztosított eszközöd árammal való táplálását és a saját belső akksijáról működteti azt tovább míg a rendes fali áram helyre nem áll.

Érdemes tudni, hogy a szünetmentes tápegységek esetén árban nagyon nagy a szórás – minél olcsóbb annál rövidebb ideig bírja a saját akkuról való ellátást, illetve kisebb teljesítményű eszközöket fog csak meghajtani.

Ezenkívül azt is fontos tudni, hogy a nem ipari kategóriájú, egyszerűbb, olcsóbb szünetmentesek négyszögjelgenerátorral rendelkezdnek, így az akksiból nyert és átalakított áram nem szabályos szinuszhullám lesz, ami a nem kapcsolóüzemű tápegységekkel nem fog – vagy legalábbis nem érdemes – működni, működtetni.

Így az ilyenekre ne köss kazánszivattyút, ventilátort, hangfalat. Annál inkább köthetsz rá jellemzően olyat, aminek adaptere van, mint például a legtöbb led lámpa, router, modem, számítógép és esetleg tévé. Ez az utóbbi csak egy nagy esetleg, mert egy tévének általában igen nagy a fogyasztása, cserébe szerintem áramszünet során hiánya elviselhető.

Egy ilyen eszköz a legtöbb műszaki, informatikai boltban kapható/rendelhető, villanyszerelő a beüzemeléséhez nem szükséges, viszont érdemes észben tartani, hogy vészhelyzet esetén (például lakástűz) a hatóságokat intézkedés megkezdése előtt ennek meglétéről tájékoztatni szükséges.

Nextcloud /data mappa adatok importálása

Tegyük fel, hogy szerver költöztetés volt és álmodban sem gondoltad volna, hogy ahhoz, hogy a nextcloud fájljaid látszódjanak az új gépen nem elég csak a data mappát másolni.

Nos, van egy jó hírem: ez nem így van.

Az adatok visszamásolása után ezt kell csak lefuttatnod:

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Nyilván a /var/www/nextcloud helyére azt a path-t írod be ahol a te nextcloud appod telepítésre került.

Ekkor “újraszámolja” az adataidat és adatbázisba felvezeti őket. Ezt persze nem kellett volna futtatnod/nom ha az adatbázist is viszem magammal… 😑

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 🙂