Disk full kérdés

 ( m0csi | 2018. március 8., csütörtök - 14:43 )

Sziasztok!

Interjún futottam bele a kérdésbe:

Debian Linux / partíció megtelt, ugyanezen található a /var/*, Docroot, log stb. Apache folyamatosan üzemel, azaz a szolgáltatásnak futnia kell, FC nincs, storage csak később bővíthető. Root reserv a partíción nincs.

Ki mit látna optimálisnak a probléma megoldására? (Kérdés kb olyan volt, hogy
mit tennél meg, hogy a szolgáltatás és az adatok is elérhetőek maradjanak
a storage bővítés pillanatáig?)

Nemigazán értettem hogyan lehet olyan valamit csatolni prodba amin nincs beállítva mondjuk min 1% reserved. Ha így meg bejutnék akkor meg deb cache, meg régi logokat törölgetnék.

Javaslatokat kérnék, Ti hogyan reagálnátok erre a kérdésre?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

pl ha LVM van egyszerű a dolog :>

Fedora 26, Thinkpad x220

régi kernelek, header-fájlok le
vészhelyzetben /usr/share/doc alól kuka minden (csomagkezelő nélkül akár)

Először próbálj meg a logokból törölgetni, aztán pedig ahogy a kolléga említette régi kernelek, header-ek kuka. Illetve körül néznék a nem használt esetleg törött csomagok körül is...

Ja most nézem, hogy interjún volt kérdés... :)

Ha nincs más adat megadva, akkor a többi az én feltételem, azaz lvm-el kötetet növelnék.

Ahogy mások is mondták először körülnézni, ha lehet elmozgatni valamit másik fsre akkor azt csinálni, logot rotálni/törölni vagy nullázni ha van róla backup 2. körben, csomagkezelők mentenek le package-t is azt a helyet is fel lehet valszeg szabadítani ( yum clean cache tudom de ez debian de ezugrott be elsőre) hasonlók.

apt clean :)

Pont a napokban találkoztam egy 99%-ossal.
Magára hagyott debian, ha korábban nálam lett volna akkor a monitorozó rendszer jelzett volna már 80%-nál.
#du -hs * volt az első amit kiadtam, ennek eredménytől függ szerintem a továbblépés.
Az érdekes amúgy az volt, hogy a /etc könyvtár duzzadt meg 10 gigára.
Az etc-ben a .git/objects könyvtár volt 9.9GB, amiről hamar kiderült, hogy az etckeeper használja ami kapott gyorsan egy uninit paramétert és a 99%-ból lett is nyomban 10%.

Egy prod szolgaltatasnal miert epp a logokat?
Ez egy klasszikus csapdahelyzet.

IMHO a helyes valasz, h megnezem, mitol telt be, mennyire gyorsan kell reagalnom stb.
Szoval a hangsuly azon van, h elobb tajekozodni, aztan torolni, esetleg a lenyeg lehet epp az, h nem torolni, hanem mozgatni.

+1, logokat nem torolni. helyette mozgatni, tomoriteni. ha vegul valami torlesre kerul a sor, akkor elotte ellenorizni, hogy backupban megvan e.

backup (v. elmásolás másik gépre) + törlés.
Logok, docok, bármi ami nem létszükséglet.

Kezdhetjük úgy is a mondatot, hogy "_nyilvánvalóan_ van mentés a dolgokról, miután ezt ellenőriztem a logok egész tegnapig törölhetőek" :)

--
Gábriel Ákos

Első körben pontosítani kell, hogy mi ette meg a helyet. (Nem panaszkodunk, hogy rosszul van összerakva, panasziroda két emelettel odébb, minden hónap ötödik péntekén délután 3 és négy között üzemel) KÖzben infót gyűjteni arról, hogy mi az, ami elmozgatható, illetve törölhető a gépről? (Logok mentése megtörténik-e, vagy csak helyben léteznek?) Egy gyors lsof | grep deleted is segíthet - hátha van nyitva tartott, de törölt fájl, aminek a helye még nem szabadult fel. Ha igen, az adott processzt megnézni, hogy micsoda, és rávenni arra, hogy engedje el a törölt fájljait.
Alapvetően fájlok elmozgatásával (másik gép, usb-s meghajtó, stb.), és csak másodsorban törléssel szabadítanék fel helyet.
Amikor némi levegőhöz (szabad terület) jut a kiszolgáló, akkor jöhet a nyomozás, hogy "miért" fogyott el a hely? Rosszul tervezett méret? meguhrott logméret? Átmeneti állományok számossága/mérete változott jelentősen? Logok rotálása nem/rosszul működik? Vagy egyszerűen kinőtte a diszket a gép? - Erre válaszolva el lehet indulni a "hogyan oldjuk meg, hogy ne legyen megint ilyen?" kérdés megválaszolása felé.

Csak elméletileg, rég futottam ilyenbe: előfordulhat, hogy egy 100%-ra tömött / esetében bejelentkezni sem lehet? Mondjuk azért, mert a /var/log/wtmp-t már nem tudja írni?

És mi van, ha nincs password-je a root-nak? Pl. Ubuntun...

Más: ha netán valami túlméretes fájl foglalja a helyet és a tartalma törölhető lenne akár azért, mert már le van mentve, akár azért, mert valami debug output, ami kissé túlnőtt a várt méretén, akkor a rm erősen felejtős, helyette egy "echo >file" paranccsal lehet nullázni a file tartalmát és nullára redukálni az allokációját.

0 byte szabad bejelentkezni be lehet csak folyton warningolni fog mindenre, mert nem tud logot vagy config fájlt írni.
Ha leesik a / fájlrendszer még ssh is válaszol, de hibával el fog szállni, mert nem fog már tudni neked jó eséllyel bash-t adni (debian based). :)

Jártam már így, raspin gyakori jelenség :>

Még az is lehet, hogy engedélyezve van valamennyi reserved hely, csak az inode-ok fogytak el, akkor is azt írogatja, hogy disk full, mikor igazából ott lenne még kellő mértékű szabad hely. df -i segítségével rá lehetne nézni. Bocs, ha triviálisnak tűnik, de elég sokan megszívják, és az ember utoljára gondol ilyenre, ha még nem járt így előtte.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Az. mikor a fejlesztok elszabaditjak a jenkinst es keves a 20Mio inode.....

Egyszer egyik kollega elcseszett valamit, és egy progi másodpercenként néhány 0 byte-os file-t leszórt valami munkakönyvtárba. Még az elfogyás előtt jött róla riasztás, de egy élmény volt ezt eltakarítani.

nekem a bestof a kb 6 millio db spam torlese qmail queue-bol xfs-en 2001 korul. valami masfel napig futott :)

stop; umount; mkfs; mount; mkdir... ; start :-P

no chill


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

Köszönöm mindenkinek a hozzászólását. A felsorolt lehetőségek közül párat ki is próbálok, tesztelés képpen.

megelőzés: még mielőtt a hiba bekövetkezne(!!!), minden gépen, jól ismert helyre tenni 1-2-x Gb-os dummy fájlt, ami igazából üres / a tartalma lényegtelen, csak helyfoglalás miatt kell. Ha elfogyott az összes szabad hely, ezt gyorsan lehet törölni, és nyert vele az ember valamennyi időt.
--

"Interjún futottam..."
Szerintem ez itt nem játszik. ;)

Ez nem is az interjús kérdésre volt válasz, hanem egy tipp a nagy K. betűs életre.
--

Remek ötlet, nekem tetszik!!

-----------------------------------------
Linux parancsok, kezdőknek

És amikor átadódik valaki másnak az üzemeltetés, akkor tutira elfelejtődik az, hogy ekkora baromságot csinált valaki, és amikor ott lesz, hogy 0% reserveddel beáll a gép, mint a faszög, akkor jön az agyalás, hogy milyen "szokásos" helyekről lehetne takarítani...
Egy ilyen dummy fájl semmi ellen nem jó - ha elfogy a hely, és összeroskad a szolgáltatás, akkor hiába tudsz pitty-putty helyet felszabadítani, a magábafordulás már megtörtént. na ezért van az, hogy production-ben a korlátozott mennyiségű erőforrásokat monitorozzuk, és megfelelő határértékeknél riasztást küldünk az adminisztrátornak, hogy előzze meg a nagyobb bajt. Fejlettebb monitoring esetében van forecasting is, ami még hamarabb tud szólni, hogyha megváltozik például a szabad hely csökkenésének az üteme.

Jajj. Én csak az első mondatig jutottam. Hogy mit javasolt, az már nem tűnt fel. Viszont ha az van, amit janoszen írt, akkor a monitoringot a hajadra kenheted. :)
(Nem tudom hogy java volt-e, de volt hasonlóhoz szerencsém... és elég izzasztó dolog, hogy áll a rendszer, állnak a pénztárak, csinálj már valamit! :) )

Java-s környezetben valóban képes egy alkalmazás tetszőlegesen sok stacktrace-t tetszőlegesen rövid idő alatt kiokádni magából - ez ellen gyakorlatilag nem tudsz semmit sem tenni, ez igaz.
A rendszer nem fog megjavulni attól, hogy ideiglenesen adok még 10%-nyi helyet, rosszabb esetben úgyis fogja azt a nyavalyás logot, ergo hiába próbálom elmozgatni, a hely csak akkor szabadul fel, amikor a java processz-t agyonvágom...

Ilyen környezetben valóbannehéz nyugodtnak, higgadtnak maradni, de arra kell gondolni, hogy "jobban leállni" már nem fog a szolgáltatás, és attól, hogy kapkodva 8 perc alatt csinálsz valamit (miközben 12 perc kéne a megnyugtató megoldáshoz) nem lesz sokkal jobb. Sőt...

Szinte soha, sehol nem készítek logoknak dedikált fájlrendszert, megelégszem azzal, hogy elég alacsonyan van a zabbix ingerküszöbe a szokásos fájlrendszereken.
A kivételt a javás alkalmazásszervert futtatók jelentik: a WAS-ak saját fájlrendszerbe logolnak, így minimalizált a vész, ha egy őrült app letépi láncát.

Egyébként az eredeti kérdéshez még egy tipp.
A legtriviálisabban visszanyerhető hely _általában_ az installkor biztos, ami ziher alapon túlallokált swap. Ahol a tapasztalat az, hogy 0 vagy lófütty a használata, és tényleg elronthatja a napot a telefutott /, le lehet lopni belőle annyit - és akármilyen néven mountolni - amennyivel a korábbi logok tömöríthetők (mert ugye tele rootal a bármiZip se fog menni).

+1, nálam az a default, hogy az ilyen-olyan alkalmazások kapnak egy lv-t a datavg-ben, az megy a /srv/appneve/ alá, és a /srv/appneve/log alá logolhatna, aztán annyi. Ha telekakkantják a saját területüket, akkor így jártak :-P Zabbix megy, szépen sárgul is a 20%-nál, és pirosodik 10-nél, ez általában elég ahhoz, hogy lehessen valamit tenni a motyóval, ha megőrül :-)
A swap érdekes dolog, csinos kis oom lehet belőle, én nem igazán játszanék ilyet... Bár ha maga alá rosált a szerver, akkor úgyis mindegy... Fizikai vas esetén, ha van hozzáférés, akkor pendrive-val megdugni, és oda sutty, lehet is tolni a lomot, vm esetében meg egy independent diszket odarakni (amúgy is jó, ha van ilyen, pláne, ha gyakran jön olyan kérés, hogy sokgigányi adatot mozgassunk át az a szerverről a b szerverre...), és arra mehet a tömörítendő szemét...

A korrektseg kedveert hozzateszem, hogy bosegesen lattam pillanatok alatt betelo diskeket mas nyelven irott szoftver tevekenysegenek koszonhetoen is, itt a programozo volt a ludas, nem a nyelv. (Raadasul meg stack trace sem volt a dologban ha jol emlekszem.)

--
Pásztor János

+1, így korrekt - azért mostanában elsősorban a Java-s elszállások általi diszkelfogyás a jellemző - a többi nyelven íródott motyók vagy elfogynak lassan, vagy már kijavították, hogy ne csináljanak ilyet :-)

nem-menedzselt játszós-demo win szervereken szoktam ezt alkalmazni, amiknél se tudás, se akarat(om) nincs egy rendes System centert aláverni (igen, én volnék az illetékes), de mivel fél-évente elő szokott fordulni ez a gebasz, ez volt a legolcsóbb és leggyorsabb megoldás. Lehet fröcskölni mennyire nem enterspájz meg production-friendly trükk. Akinek viszont a pár gépes környezetében 1x megmenti a seggét egy nagyobb bajtól, annak nagyon szívesen!
--

Én inkább úgy mondanám, hogy szaxerűtlen. :)
Ahogy ezt végsősoron el is ismerted.

én nem dolgozom a szakmában, de még a saját otthoni kis rendszereimről is írok dokumentációt (már ahol ez releváns, a daily laptopomon mindig tudom mi hol van)


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

Franc tudja... ha hibaelhárítás, akkor a doksiban nem azt fogom keresni, hogy egy az életszerűtől eltérő helyzetre van-e benne megoldás.
Azt meg nehezen tudom elképzelni, hogy egy rendszergazda az utolsó bitig bemagolja az üzemeltetési doksit.

Elég szomorú elképzelés.
Átmész a piros lámpán, osztán a rendőr bácsi szitává lő. Nem tanulta meg az utolsó bitig azt a sok jogi maszlagot. :-D
Onnan tudom a dolgokat, mert írtam néhány doksit és általában kívülről tudtam. A support hívásra a válasz néha így nézett ki: Nem olvastad el a 17.3.3 pont második bekezdését. ;)
Szóval csodákat tud tenni, ha az oprendszert és az üzemeltetett rendszert is ismered. Akkor már csak az eltérést kell megkeresni!
Ha nem így van, akkor mi szükség üzemeltetőre? Próbákozhat a takarítónő is, hiszen neki is lehet szerencséje.

Nem azt mondtam, hogy egyáltalán nem ismerni, de többezer oldalas doksikat bemagolni, az finoman szólva is életszerűtlen. Életemben összesen ha egy olyan embert ismertem, akiből ezt ki is néztem volna, ő amikor utoljára hallottam felőle, a HP-nél volt valami főnökféleség. (azóta talán már nyugdíjas)
És persze a méretből következően, nem a Pistike Bt által készített, két űrlap kitöltésére készített "rendszerre" gondolok, hanem komoly cuccokra.
Te pl. tudod fejből a Windows összes registry kulcsát? (nevét, funkcióját stb.) :)

Ne gyere már hátulról a vindózzal! Azt még az MS sem tudja. :)
Üzemeltetési doksiról volt szó. Amiről meg én beszéltem, az 1500MFt árú rendszer. Ennek az üzemeltetéséhez kell ismerni az oprendszert, az adott konfigurációt és a rajta futó cuccokat. Ilyet üzemeltettem és nem hiszem, hogy bárki meg tudott volna fogni. A doksi 1000++ oldal.
A support kaland a fenti rendszerhez készült rendszerelemekről szólt.
Ennek ellenkezője a dokumentáció hiánya, hiszen linuxhoz, javahoz, stb. mindenki ért. Máris indulhat a fórum, szarköszörülés...

Bocs, sok hasonlóan eccerű rendszerrel volt dolgom. IBM Tivoli jöhet? :)
Esetleg a gondjaidra bízott DB2/Oracle/Rdb adatbázisokat ismered kívül-belül? (Ami szerintem hasznosabb lehet adott esetben)
A napi üzemhez szükséges infókat felszedi az ember a szükséges ismereteket, de ha sok rendszerrel kell dolgozni egyszerre, akkor az ilyen... khm... egyedi "megoldásokat" szerintem bárki elfelejti és borulás esetén először végigmegy azokon a procedúrákon, amiket kapásból tud, amikre számítani lehet.

Persze lehet, hogy mást értünk doksi alatt, de akkor az 1000+ oldalból 990 felesleges ábrákkal van tele.

Szerencsére a "jól temperált" sql elkerült. ;) Olyat viszont üzemeltettem, amit szakemberek terveztek. (!=ifjú titán)
Az összes RDBMS ismerete nyilvánvalóan linux rendszergazda default skill tartományába esik. Hosszabb távon megéri valamilyen irányzat mellett letenni a voksot. Bár dolgoztam olyan helyen, ahol a hatalmas gépterem beltartalmát komoly vezetöi döntések alakították: Idén zöld szervereket veszünk. ;)
Szóval értem miről beszélsz, sőt tisztában vagyok a terendekkel is. Ennek ellenére soha nem kerültem kapcsolatba mondjuk AIX üzemeltetőként MSSQL-lel. ;)
A doksi az doksi. Nem keverendő össze a pécés számítástechnika hajnala óta divatos képernyőképek gyűjteménye alapú "szakirodalommal"!

"És amikor átadódik valaki másnak az üzemeltetés, akkor tutira elfelejtődik az, hogy ekkora baromságot csinált valaki..."

Rendes rendszergazda mindent ledokumentál.
Nem tudom multiknál ez hogy működik, de én hibaelhárítási stratégiát ilyen esetben csinálnék.

Eloszor is ugye azt erdemes megnezni hogy mi eszi a helyet. Velem volt mar olyan, hogy valamelyik Javas szoftvernel elgurult a gyogyszere es gyartott hirtelen 20 giga logot. Ezen felul azt is erdemes megnezni, hogy a torolt fajlokon van-e valakinek nyitott file descriptora, mert akkor nem torlodik.

A tobbit mar fentebb leirtak.

--
Pásztor János

Jira? pont par hete futottam bele, valami napi 11gb logot termelt a draga

devnull-t ramasolni a jvm logra daily routine a fejleszto rendszereken. Amugy meg kulon filerendszerek es jo monitoring.
____________________
echo crash > /dev/kmem

sok fugg a kornyezettol, en ezt anno a mount --bind segitsegevel oldottam meg, a /home ala csinaltam egy konyvtarat, ide atmasoltam az egyik nagyobb konyvtarat, ( emlekeim szerint takaritas utan /var/cache -t ), aztan bevittem a /var ala a helyere. ket napig ment igy a gep, amig megjottek a boviteshez a diszkek.

--
HUP te Zsiga !

Javaslatokat kérnék a HUP-on.

:)

Ha van fizikai hozzáférés a géphez, akkor usb hdd-re/pendrive-ra régi logok és minden egyéb, ami mozdítható át (logokat enélkül nem szívesen törölnék prod. vason). Ha vannak nem használt, régi kernelek, akkor ezeket kukáznám, illetve az apt-al is csinálnék egy takarítást a régi, nem használt csomagok között.
Miután így nyertem egy kis időt, elkezdeném nézni, hogy mégis mi zabálta meg a helyet.


Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

Többen mondták hogy elkezdenék nézni, mi ette meg a helyet.
Jó de milyen módszerrel néznétek?
du -sh minden könyvtárban?

a gyokerben szoktam kezdeni, eloszor a var-on aztan usr, es megyek befele lepesenkent, altalaban eleg hamar megvan a bunos. esteleg ha nagyon sietos akkor az eddigi tapasztalatok alapjan megnezek par dolgot (foleg log-ok, java cuccok), esetleg egy top/iotop is adhat tippeket ha gyorsan fogy a hely

Értem, köszi!
Hirtelen a /home ugrott be, de profi helyeken az külön partición van gondolom. Vagy külön diszken.

vagy nincs :D idealis rendszerben nincsenek userek.

"idealis rendszerben nincsenek userek" ez tetszik :D


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

Pedig van benne valami :)

nalam a home mindig kulon particio, es az adatokat (atlinkelve) ott tarolom, hogy ha kell a rendszer akar ujra is huzhato adatvesztes nelkul.

Az AIX sokat kapott a linuxtól, a linux gyárosai eltanulhatnák az AIX-től - legalább szerver telepítésekor -, hogy dobozból telepítve a /usr, /var, /tmp, /home, /opt könyvtárak alapból saját fájlrendszeren ülnek.
Az AIX tekintetében ez se teljes, mert az /etc alá logszerű fájlok kerülnek (fejlövés!), de máris kisebb odsszal lehet jegyezni olyan esetet, amikor Szervertakartamdefoglalkozniveleaztnem Pistikétől tűzoltásra át kell venni a művét, amikor az a OP-ban írt tünetegyüttesben szenved.

Az AIX sokat kapott a linuxtól...
Made my day. :-D

Elég vakmerő tett egy robosztus ipari rendszert, - ami jól átgondolt elvekkel, stratégiával és optimalizált hardver platformmal rendelkezik, - összehasonlítani a mindezekkel nem rendelkezővel.
Az a baj az elgondolásoddal, hogy a diszk részekre szabdalása - bár jó ötlet - elég gyenge megoldás, ha az oprendszerből hiányzik ennek a darabolásnak az átfogó és egységes kezelése.

(Bár a /etc alatti "logszerű fájlokról" mesélhetnél valamit. :) De legalább egyet mondjál!)

Pl. tudja-e azt a linux, hogy szoftvert csak a /usr alá rakunk, és az install automatikusan növeli a /usr méretét, ha szükséges? Természetesen a rendszer részét képező LVM segítségével. Ráadásul, ha ez sérti az előre definiált stratégiát (mondjuk a /usr bővítése miatt az új partíciók a diszk "túlsó végére" kerültek), akkor a stratégiának megfelelően egy paranccsal átrendezi a diszket.

Avagy a linux kiszámolja-e a /boot (bootlv) szükséges méretét? (Ezt kifelejtetted. :))

A nagy igazság az, hogy még linuxon is lehet stabil rendszert kiépíteni. Ehhez természetesen gondos tervezés szükséges. Ezzel szemben az AIX is képes egészen a crash-ig eljutni, ha kifejezetten gondatalan az elkövető. (Komolyan mondom: Láttam már ilyet, de nem én voltam!:))

Visszakanyarodva a topicnyitóra, a fentiek alapján interjún el lehetne sütni a választ: Ezek szerint jó helyen járok! Ha felvesznek, ezt a kérdést a továbbiakban törölhetik! :-D

Ettől én is kicsit padlót fogtam... az a /etc-s kijelentés is elég merésznek tűnik, bár tíz éve nem láttam AIX-t sem, de valami rémlik, hogy nem a megszokott tartalma van/volt.

Én ilyen merész fickó vagyok:

https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/utmp.htm

keresőszó: failedlogin

Az IBM tudós mérnökei például nem értették, miért van Unixban külön /bin és /usr/bin, ezért AIX-ban a /bin egy szimlink a /usr/bin-re. Nemrég volt hír, hogy egyes Linux-disztrók is erre akarnak váltani. (Mondjuk a jövő úgyis az lesz, hogy systemd és dbus nélkül nélkül a busybox sem indul majd el, tehát ez se számít semmit.)

Az AIX _nem_ Unix, csak sok dologban hasonlít :-) Oké, SVR3-ból indult, de azért Makó-Jeruzsálem, na... És azok a tudós mérnökök elég sokat tettek hozzá ahhoz, hogy a *nix jellegű rendszerek olyanok legyenek, amilyenek mostanság.

Ez a symlink-es ki- és nya-fogás olyan, mint amit anno én az ODM-mel kapcsolatban elrebegtem, miszerint az egy Windows registry IBM-módra :-)

Az AIX az bizony UNIX.
____________________
echo crash > /dev/kmem

Iróniadetektor :-P

Eh, beneztem igy kispenteken :)
____________________
echo crash > /dev/kmem

Bizony, nem CSAK UNIX, hanem egyszerre több is. ;)

> egyes Linux-disztrók is erre akarnak váltani.
$ cat /etc/system-release && file /bin
CentOS Linux release 7.4.1708 (Core)
/bin: symbolic link to `usr/bin'

> systemd és dbus nélkül nélkül a busybox sem indul majd el
Lesz n+1. Windows :'(

____________________
echo crash > /dev/kmem

+1

+1 :-D például a bash-t onnan kapta, na... :-D

Próbáltad már megversenyeztetni a natív és a toolboxos findot? Ajánlom. És most nem a lehetséges filteropciók halmazára gondolok, hanem a keresés sebességére.

A linuxos (gnu)find-ot 1-2M fájlos könyvtárban, mtime és névre illesztett regexp alapján keresve egy jól összerakott perl script is agyonverte RHEL5/RHEL6 alatt - jó, a Perl script célzottan csak a mintára illeszkedő nevű fájlokrta indított stat()-ot, a gnufind meg mindenre, ami erősen szuboptimális ekkora darabszám esetén.

Elhiszem, az AIX-os find-nál viszont a gnu find nagyságrendekkel (nem elírás) gyorsabb. Hálistennek nem kell már sambát üzemeltetnem rajta, pedig szívesen megmutatnám, hogy mennyivel.

(Egyébként tényleg mindenki az olvasta az eredeti hozzászólásomba, hogy az AIX-ot fikázom? Visszaolvastam, nekem most sem tűnik úgy. Mindegy. És persze a fényes oldalai miatt a sötétekre nincs okom bólogatni, amit félre lehet érteni.)

Melyik gnufind? Mert abból van egy rakat, és nagyon nem mindegy, ahogy például az ls sem mindegy, hogy melyik - ott paraméterezésben is elég "szép" különbségek vannak (RHEL6/RHEL7-re fel kellett pakkolni a RHEL5-ben található ls-t, mert egy alkalmazás bedrótozott paraméterezéssel hívta meg, és megadott outputot várt el...)

Ok, tehát kapott néhány tool-t, ami akár gyorsabb is lehetett, mint a "régi" natív AIX-os verzió, de ezeket összességében a teljes rendszerhez képest én nem nevezném "sok"-nak.
Az, hogy a Linuxos disztrók tanulhatnának a nagyoktól, azt a véleményt én is osztom - de nem fognak, sajnos.

Ezt is elfogadom, de nem igazán velem van vitád: a gyártó állította, hogy a linux-kompatibilitással, és linux toolokkal az AIX használhatóbb - az csak véletlen egybeesés, hogy én ezzel egyetértek.

És az is véletlen egybeesés, hogy amikor a gyártó még nem állította ezt, a bullfreeware annyira népszerű volt, hogy az utódja (sőt, több utódja is) a mai napig létezik, a hivatalos, jobbító szándékkal fenntartott box mellett.

Ja, a find az IBM linux toolboxában szereplő findutils /opt/freeware/bin/find programja.

Ébresztő! Persze, hogy a gyártó ezt állítja, hiszen el akar adni. Ismerem a problémát már '94 óta, de ez nem azt jelenti, hogy az AIX használhatatlan lenne. Legfeljebb nem sikerül a feladatot egyszerűbben megoldani, és/vagy hiányoznak az AIX alapismeretek. ;)

Volt nálam is néhány "idegen" program: unarj (ősrégen, pc kompatibilitás miatt), majd gzip, ssh (amikor még nem volt AIX alatt), és postfix (mert a sendmail tényleg botrányos volt). Viszont StarOffice futtatási igényem soha nem támadt! Tehát a másik csoport, aki linuxról szeretne valamit költöztetni.

Már csak egy kérdés maradt: Mi a rossebnek használ valaki AIX-et, ha a linuxot jobbnak tartja? Ugyanarra a hardverre vásárolható SLES, RHEL és talán már ubuntu is.

Pótkérdés: Vajon mennyire meghatározó egy oprendszer minősége szempontjából a find?

Pót-pótkérdés: Vajon mi célból és milyen hierarchiában kell futtatni a find-ot, hogy lényeges legyen a sebessége?

Szerintem te itten találkoztál egy szalmabábbal, akivel jól elvitatkozol. Ami nem baj, hiszen javítja a vitakészséget, már általános iskolában alkalmazni kéne a módszert.

Szóval: az AIX nagyon jó, csak azon a cli-n, ami a legszűkebb keresztmetszet, amikor gyorsan kell produkálni, használhatóbb a linuxos toolokkal - szerintem, és a pénzéhes gyártó szerint, meg azok szerint, akiket a pénzéhes gyártó ezzel meg akart fogni, meg azok szerint, akik a pénzéhes gyártótól függetlenül még több linuxos toolt pakolnak fel (akár az alap OS fixelhetőségét is beáldozva... ami botorság - szerintem).

De nincs ezen semmi eredeti: a windows is nagyon jó/rossz/muszáj használni, de linuxos toolokkal használhatóbb.

/

Ez az a rész, amit fenntartok azoknak a véleményeknek, hogy de nem is, mert a win előbb volt mint a lin, és különben is jobban kezeli a grafikát, amúgy pedig aki lin akar, az ne indítson wint.

/

Akkor ide is írom köntörfalazás nélkül, mert úgy látszik a burkolt célzások nem jönnek össze. ;)

Az AIX cli csak azoknak szűk keresztmetszet, akik nem tudják használni.
(Ha meg sok-sok a cli, akkor már programot is lehetne írni!)

Tapasztalatom szerint akik "fejlettebb" tolokat szeretnek használni, azok igen gyakran rosszul, elbonyolítva fogalmazzák meg a megoldandó feladatot. Ezek után inkább a tool-ok jobbságára, mint a megoldásra tudnak csak koncentrálni.

Ez a véleményem, de bizton állítom, hogy hosszú idő tapasztalata alapján is így van.

A "fixelhetőség beáldozása" nem nagyon számít, ha pl. bash a döntésed - akkor legyen az. Inkább stabilitásnak hívom, amit mások persze elavultnak titulálnak. A gnu el is hagyta az AIX alatt megszokott dolgokat. Igaz, kellett hozzá vagy 15 év. ;) Bár a pro mellett ott a kontra: számomra néha kaotikusnak tűnik.

A win az nagyon jó, hiszen rengeteg putty ablakot tud nyitni. Ehhez viszont nem szükséges egy darab linuxos tool sem. Kb. ez az, amiben eltér a kettőnk gondolkodásmódja.

És még nem is tisztáztuk, hogy mifene az a "fixelhetőség".

Ha a bullfreeware valamelyik utódjáról telepítesz, vagy gond nélkül fel fogod tudni tenni a következő APAR-t, SP-t, TL-t, vagy megtöri a függőségeket az idegen ág, és akkor nem; vagy igen, csak az idegenből feltett program hal bele.

Mitől féljek pontosan: az 'installp' telepít bele az /opt/freeware-be, vagy a perzl.org telepít azon kívülre?

Egyébként, ha már félni akarok, itt van például az OracleClient12: a derék iparos úgy bütykölte össze az AIX-os verziót, hogy azzal szerencsésen megakadályozta még a Apache és OpenSSL együttműködését is ( https://hup.hu/node/152185 )

Tkp. C-ben minden megoldható, tehát soha sehol nem lehet semmilyen probléma.

Csak idő legyen, meg az, aki kivárja.

Annak, aki a GNU toolokat ismeri, annak azzal termelékenyebb a cli, de az AIX-et általában nem azért tartják, hogy cli-ben matassanak benne nap, mint nap, mindenféle ad-hoc dolgokat elvégezve.

A Windows-ban is vannak egészen jó dolgok: a powershell például irgalmatlanul odaver a csőben karakterek sorozatát tologató, az alapvetéseiket tekintve közel ötven éves *nix-os eszközöknek - igaz, rengeteg dolgot (mindent...) újra kell tanulni.

Egészen felcsigáztál! I-|

Egyetértek.
És közben megjegyzem azt az apróságot, hogy a PS-t úgy írták meg, hogy a gyakran használt leteknek legyen az azoknak kb. megelelő funkciójú aliasa.
Miközben a PS Get-Help parancsa sokkal többet/máshogy tud, mint a man, miért is ne használhatná a man-t az, akinek évtizedek óta az van az ujjában, csak többre, máshogy?

ezt a powershell dolgot megtennéd hogy kifejted egy kezdőnek? :) köszi


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

A unix-os filozófia ugye az, hogy a stdin/stdout az karakterek sorozata, aztán kész. Faék egyszerű, csak épp akkor nem az, ha a foo kimenetét szeretnénk a baar által értelmesnek gondolt bemeneti formára hozni. Ez kevésbé fájdalmas ps környezetben, ahol a "csőben" picit más adatszerkezetek mozognak...

# grep -v DROP kern
Binary file kern matches
....
Karakterek... :D

Ha binary-nak látja, de te tudod, hogy nem az (mert UTF-8/UTF-16 szöveg), akkor "-a", oszt' jónapot :-P Ezzel a stderr-re kibökött "bináris, de illeszkedik"-kel a másik alapelvet valósítja meg: az output humán felhasználásra alkalmas legyen :-)

Hááát... ugye volt az a bizonyos L, amit az os neve megkapott az 5-ös verziónál. Az L azóta megszűnt, viszont a linux toolbox megmaradt...
De tudod te ezt, még röhögve is, akkor is ha juszt se használod, mert csak.

https://hup.hu/node/158310#comment-2208897

Végülis Windows alatt is van cygwin... :-P Bár a natív Windows-os dolgokra inkább powershell-t fogok használni :-P

Van... de nem az MS teszi bele...

Nyertél.
De.
Az utmp nem annyira vészes, a /etc/security meg éljen csak külön életet. Az sem sokkal jobb, amikor az adatbázis kerül a /var alá. ;)
A röhögést kikérem magamnak! :) De tényleg, ha van egy oprendszer ami jó és stabil, akkor minek küzdjek olyan dolgokkal, amik nem azok.

Erről tudok néhány dolgot mesélni.
- Fiatal versenyző rakta fel a gnu date parancsot, mert az AIX-es szar. Igaz, számlázó és backup rendszert írtam a használhatatlan date használatával. Tán bennem van a hiba.
- Komoly IBM szakember az AIX install befejezésének a bash felrakását tekintette. No, ennek lett a vége a crash. Méghozzá többször, éles rendszren. Én inkább az oprendszer minimal install és finomhangolás kérdéseivel szoktam foglalkozni. Tán ezért nem sikerült ezt a fícsört soha előhozni.
Biztos huncut, aki rosszra gondol. ;)

> Fiatal versenyző rakta fel a gnu date parancsot, mert az AIX-es szar. Igaz, számlázó és backup rendszert írtam a használhatatlan date használatával. Tán bennem van a hiba.

Igen. Egyrészt mert a shell(+utils) nem programozásra való (hanem programok elindítására), másrészt mert azzal, hogy egy kész eszköz (GNU!date) telepítése helyett sk alkottál egy hasonlót, azzal a munkaidődet (vagyis a céged pénzét) pazaroltad feleslegesen.

A command.com -ról elhiszem, hogy nem programozásra való, csak olyan nincs AIX alatt :-P Szerintem nézz utána, hogy a ksh mit tud (egy csomó dolgot onnan vett át a bash...), utána gyere vissza :-)

Nem pazarolt, csak egy rendszeridegen elem helyett a beépített/támogatott eszközzel oldotta meg a feladatot, mert azzal is meg lehetett, picit másképp, mint ahogy a "fiatal versenyző" (régen volt az...) elsőre gondolta.
(ugyanez visszafelé: Linuxban lecserélték az ls parancsot, naná, hogy változott a paraméterezése. Fejlesztő nemvolt hajlandó a kódjához hozzányúlni, ergo a RHEL7 64 bites környezetbe is cipelni kellett a tán RHEL5-ös 32 bites "ls" parancsot...)

Stabil/production környezetben két, azonos nevű, azonos funkciójú, de eltérően viselkedő/máshogy paraméterezendő tool létezése nem igazán kívánatos dolog - nagyon gá, ha a $PATH beállításától függ, hogy a pimpapampa parancs hogy viselkedik...

Jesszus, visszajöttek az ötvenes évek? Rendszeridegen elemek vannak közöttünk?
Egyébként valóban, az informatika mai állapota már olyan kihívásokkal is megbirkózik, hogy ha pl. az install, date, find, make, diff stb nevű programok harminc évvel ezelőtt befagyott szolgáltatásaival nem vagyunk elégedettek, akkor telepítjük a GNU-változatot ginstall, gdate, gfind, gmake etc néven.

A rendszeridegenségről ez jut eszembe: https://hup.hu/node/106450#comment-1421142

Csitt! Csak halkan! Ha szegény shell ezt meghallja, akkor sírva fog fakadni, miközben még a belét is kikacagja ekkora marhaság hallatán. :)

Másrészt honnan veszed, hogy a kész eszköz helyett írtam egy másikat? Azt magyarázom, hogy a más által használhatatlannak minősített tool annyira volt használhatatlan, miszerint én tudtam használni, ő meg nem. ;) Amit írtam - honnan vetted, hogy shellben? - az jobbára shell, C és awk felhasználásával készült. A date alapú toolok azért készültek, mert 24 éve a gnu még a béka segge alatt sem volt, de hasonló tool ma sincsen. :-D Ennek ellenére az akkor megírt dolgokat ma is vígan, módosítás nélkül használom linux alatt is.

a munkaidődet (vagyis a céged pénzét) pazaroltad feleslegesen
Ez részben igaz. Bár a cégem pénzét (mint vállalkozó) sokkal jobban meg tudtam úgy óvni, hogy megfelelő minőségű programot szállítok a fővállalkozónak (az utolsó 8 évben mint regisztrált IBM beszállító). Már, ha garanciát kellett vállalnom a szállított szoftverért. Sőt, még határidő is volt.

mert a shell(+utils) nem programozásra való (hanem programok elindítására)
Teljes mértékben igaz. Pontosan ezért pl. az AIX jó része is script. Pl. - ha jól emléxem - a chlv, mklv is egy a low level parancsokat hívogató script. Az ilyenekben néha szerepel néhány utils is. Minden bizonnyal ők sem értenek hozzá. ;)

Nem pörögjük ezt túl? Leírom lassabban: időről-időre szükség van a tegnapi vagy holnapi vagy akármilyen dátumra. Ha valamilyen programozási nyelvet használunk, abban nyilván annak a lehetőségeit használjuk. Ha scriptelünk, akkor vagy gdate -d '-1 day' vagy pedig a helyi rockstar-coder egyéni fejlesztését használjuk, ami szinte mindig működik, kivéve a nemtesztelt eseteket.

"kivéve a nemtesztelt eseteket." :-) volt, hogy a kolléga fejlesztése hosszú ideig problémamentesen működött (n+1 forrásból érkező adatokat kellett egységes formába önteni), egyik este viszont elhasalt.
Hibakeresés végén kiderült, hogy az "és ha minden felküldött adat hibátlan, akkor..." ágra futott a program, ami valami miatt nem készült még el... :-)

olyan nincs hogy minden input rendben van, nem csodálom hogy nem lett implementálva :D


"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality

Nem tudom, hogy ez dícséret vagy sem. :)
A feladat szerint csak ellenőrizni kellett, nem egységes formátumra hozni. Az ellenrendszer folyamatosan fejlődött (35 helyen volt UGYANAZ a 20 féle szoftver:)), és vele együtt a mienk is. Mit kellett volna tennem, ha egész pontosan a "mindenki időben ÉS hibátlanul küldött" lehetőséget teszt adat híján még nem tudtam kipróbálni? ;)

De mondok jobbat. Három telephelyes migrációs projekt. Közben szólnak, hogy eztmegazt "csinád má' meg!" OK. IBM-es fiúkkal lebeszélik, hogy projekt késik, így hétvégén összecsapom, felrakom. Projekt folytatódik.
Másfél hónap múlva kiderült, hogy egy bitet odébb raktam (van ilyen is), és több mint félmillió hibás jogosultság alapján indított hívás volt. Mondtam a leányzónak, akkor számlázd ki! :D
Eddig semmi poén. A két szolgáltatónál úgy 50 ember tesztelte a rendszert. Nekem viszont szerződésem sem volt. Mi lett volna, ha tényleg kiszámlázza, de minek alapján? Nnna, ez a poén, meg a jól tesztelt rendszer. :-)

Te jobban emlékszel, hogy mi volt a feladat :-)

Egész biztosan. Hiszen Lajoskával fejenként 60.000Ft szerzői jogdíjért kellett írni egy programot, ami szintaktikai ellenőrzést végez a küldeményeken. Erről beszélgettünk december végén. Február végére a rendszer működött - a vezetőség lehidalt. Csak fel kellett ismerni, hogy a 20-30 küldeményre ki fogja lefuttatni a programot, stb. Így készült egy olyan FSM alapú vezérlés, aminek 19 év lett az életciklusa. Úgy 15 év múlva ugyan "leszerelték", ami csak annyit jelentett, hogy a megváltozott körülményekhez kellett igazítani. Tehát a leszerelés helyett is csak tovább kellet fejleszteni. Ha még emléxel, későbbiekben a FUP és LSIP-ek automatizálását is megcsináltam, és ez a rendszer lett az összes szerveren futó folyamatok automatizált vezérlő rendszere. Akkoriban + kollégával egy ciklotron becenevű feldolgozó rendszer is terveztünk, ami a több órás-napos átfutási időket effektíve 0 értékűre redukálta. (Képzeld csak el: text-stream adatbázis polárkoordinátákkal! Valószínűleg ilyen a világon nincs! ;))

A poénban nem az a poén, hogy a "jól tesztelt" szoftverből mi hiányzott, hanem az, hogy Lajoska a mai napig ronggyá röhögi magát, hogy milyen fejet vágtam a dologhoz. (Állítólag elsápadtam.)
A konstelláció pedig egyáltalán nem csoda, hiszen egy adatgyűjtő rendszer általában a felküldő szoftver(ek) tesztrendszere. Mivel a küldő szoftver is állandóan "szét volt írva", meg külön pénzért a több mint 20 felküdőhely részére más-más fícsörrel ellátva, ezért nem teljesen ISO szerint, de állandóan mentek az apróbb módosítások. Így nem csoda, ha a "végső megoldás" majdnem 2 évig váratott magára. :)
De volt aki... Szólok a Westel-nek: Igazítsátok meg a programot, mert nem tudtok adatot küldeni! - Mi nem tudunk csak úgy hozzányúlni, mert nálunk ISO ... - Akkor is, b.tok meg! A Westelt NEM esszel kell írni!

nemtom mennyire normalis az, hogy most lefordultam a szekrol a rohogestol :D)

--
HUP te Zsiga !

Ez minden bizonnyal 24 évvel ezelőtt is működött. Meg filterként is. Vagy mégse? Vagy tán abban sem vagy biztos, csak okoskodsz?
És mi az a "helyi rockstar-coder egyéni fejlesztését használjuk".
Vajon egy auditált számlázási rendszer elégé tesztelt-e?
Vagy csak akkor, ha Te programoztad?
De az is csak akkor, ha gnu tool felhasználásával?
Ezek azért eldöntendő kérdések!

Szóval a ksh-ban megírt számlázási rendszered kiváltotta a gdate használatát. Asszem ezt meg is beszéltük.

Bocs,ezt már nem bírom. Nézz már utána, hogy kivel vitatkozol ilyen arrogáns, lekezelő stílusban! Szerintem te még rövidgatyában játszottál a homokozóban, mikor ő már IBM vasakon dolgozott... :D

Pontosan nem tudom, hogy ezt kinek írtad (nem olyan nézetben vagyok), de szerintem buckó kolléga talán még régebben is dolgozik az iparban mint én (programozóként kezdtem 1992.08.17-én, AIX-szel birkózom naponta kb 2005. óta). És nem arrogáns csak egy kicsit fölényeskedő.

Ilyen kisfiú lennél? :)
Hmmm... AIX előtt nem mainframe-en dolgoztál? Nekem olyan emlékeim voltak még indexes időkből, hogy eleve IBM-en kezdtél.

2005? Én is akkor láttam először AIX-t. Pár évvel később meg utoljára. Kicsit sajnálom, helyenként tetszett. Főleg az, hogy az op.rendszert alig kellett piszkálni a telepítés után. Csak ment...

BS2000 volt az a mainframe

Én kérek elnézést :)

No, akkor én követlek meg.
Odáig tudtam, hogy AIX spiller vagy, de pont ezért nem értettem. Akkor még 4-es AIX-et sem láttál! Én meg nyomom 3.1.5/POWER 33MHz (vagy valami hasonló óta). Így nem is látthattál toolbox nélküli rendszert.
Szóval, mire megláttad a Rendszerek Rendszerét :), addigra én már túl voltam a hetedik (fajta) teljesen automatizált, esetleg egymással kommunikáló rendszeren. És egy fajta kivételével ksh-ban készült. De megy egy (utolsó) rendszerem 10 éve linuxon is. A shell - mint írtad programokat futtat. Ezis, úgy 56M darabot naponta. :-) (Az automatizált az nem a cron script, hanem FSM. ;)) Gondolom, Te meg ilyet nem láttál még, azért hiszed, hogy shellben nem lehet programot írni.
Azért viszonzom a biztosíték kicsapását! Az automatizálást kis- és nagynyomású pneumatikával és hidraulikával tanultam. A 20 éves AIX kaland előtt és utána is hardverfejlesztőkén, assembler programozókén dolzom/tam. Tehát assemblerben, de akár diszkrét hardver alapon is meg tudom csinálni, amit ksh-ban. Az elvek tökegyformák. :D

Jajjistenem, de sok minden kavarog itt;)

Ahogy már mondtam is, nem akarom a teljesítményedet és az élményeidet semmilyen módon lekicsinyellni, csak nem arról van itt szó... (Illetve persze mindenről lehet szó, már rég az off-topik off-topikjánál tartunk)

Például nem azt mondtam, hogy shell-ben nem lehet programozni, hanem azt, hogy ilyet normálisan nem csinálunk. Nem kérdezted, hogy miért, hát például azért, mert lassú: nyakra-főre forkol, hogy külső utilityket futtason. Meg azért, mert számos shell van, amik egymással semerről sem kompatibilisek (mostanában lett a dash, ami kifejezetten a minimális képességet célozta meg, épp a kompatibilis fejlesztés kedvéért). Meg azért, nagyon szűkösek a lehetőségei egy valadi programnyelvhez (pl Perl) képest. De persze lehet. Ott van a GNU-libtool -- na az szerintem a 'medveanyám' kategória.

Értem, de nem ennyre rossz a helyzet.
Egyszerűen meg kell célozni a platformot. A ksh script fut bash alatt is. Ehhez nem a dash az eszköz, mindössze nem fontos a legapróbb elborult ötletet is kiaknázni. A kódot nem kívánom mindenhova hordozni, mert mindig egyedi, egy bizonyos célra készült megoldásra volt szükség.
Forkolni tényleg forkol, a vezérlés lépeget, ráadásul rengeteg ojjektumot kell lockolni, ami shellből egy vagy két további fork is lehet.
Ettől kezdve csak méretezés kérdése: munkaterületek száma, a hálózati kapcsolat felépítése és az egyes feldolgozások futásideje alapján eldönthető mit lehet tenni.
A "valódi programnyelv", mint a perl??? Nekem eddig mindent sikerült az alap toolokkal megoldani, amit legfeljebb pár sor C-vel egészítek ki.
A sok fork egy mai gépnek meg se kottyan. Ami fölött eljárt az idő, a 25 éve készült és több ráncfelvarráson átesett Lock. Hiába cseréltem a kiváló GNU flock-ra, az meg néha nem működik.
Kíváncsi vagyok mennyi szabadul fel az 1,25 core elvesztegetett teljesítményből, ha írok egy lock szervert. Csak ahhoz sokkal több felesleges idő kellene...

Ha úgy tetszik, nem én kezdtem.
Egész konkrétan 1992-2012 intervallumban dolgoztam AIX-en. Rövidgatyában is, de már rég nem voltam pályakezdő. :)
Bár számomra ebből egyáltalán nem következik, hogy 1994-ben létezett olyan gdate, ami a mai fícsöröket tudta volna, de még ma sincs olyan, ami az általam megírtakat tudná. Ott a link, nézd meg!
Azt sem teljesen csípem, ha világosan leírom: shell, C és awk...24 éve
Amire később jön a válasz: Szóval a ksh-ban megírt számlázási rendszered kiváltotta a gdate használatát.
Nem, nem kiváltotta, hanem még a mai verziót is túlszárnyalta.

(Bizony, volt olyan is itt a hupon, aki fejemhez vágta, hogy miért nem X szabvány szerint készítettem egy rendszert. Sajnos a szabvány tizenvalahány évvel később keletkezett, de talán ez volt a legkisebb hibája. :D)

Akkor most kinek erősebb a bátyja?
Szerintem mindegy.

Nem arról van szó, hogy vitatnám az érdemeidet, isten ments. De mégsem hiszem, hogy a számlázási rendszered helyettesítené pl. az alábbi scriptet (az elmúlt hónap fájljait gyűjti, minden hónap elejetáján indítja a cron):

Gtar=/usr/local/bin/tar
Gdate=/usr/local/bin/date
EvHonap="$($Gdate '-d -27 days' '+%Y%m')"
TarOutput="prefix_${EvHonap}.tar.xz"

"$Gtar" -T <(find dir -name "PREFIX_${EvHonap}*") --remove-files -cJf "$TarOutput"

Közben itt válaszoltam.
Bár ez is script, de "csak batch". Nem akartam mindent körülírni, de az igazi script számomra a teljesen automatizált rendszert jelenti.
Az a "számlázási rendszer", amire én gondoltam, az
- összegyűjti az egyes telephelyekről a hívásrekordokat
-- szolgáltatás fajtánként
- elvégzi a jogosultságok ellenőrzését
-- amihez az adatokat az egyes szolgáltatóktól veszi át
-- és adatbázisba integrálja
- ellenőrzi a számhordozást
-- amihez az adatokat a központi rendszerből szerzi be
-- és a jogosultsági adatokhoz passzítja
-- és adatbázisba integrálja
- átadja a számlázásnak a megfelelő adatokat
- átadja a többi szolgáltatónak a megfelelő adatokat
- az egyes irányokban gyakorlatilag fault tolerant kapcsolatot tart
(pl. elviheted javításra az egyik "alállomást", vagy megszakadhat a hálózati kapcsolat, vagy le is állíthatod közben a központi szervert)
- régen tarifált is

Na, ezt értem számlázó rendszer alatt, ami teljesen automatikusan éjjel-nappal gyűjti az adatokat.
Beláthatod, hogy itt nem a date a kulcskérdés. ;)

Viszont van néhány művészi teljesítmény.
Ha az ellenfél (másik szolgáltató) nem valósítja meg a láncolt és nyugtázott adatátadáshoz szükséges szoftvert, akkor némi gondolkodás után kiszámítható mit kell tenni a helyes működéshez. :D
Ha leállítod a rendszert, akkor újrainduláskor ki kell számítani milyen nap van. Neeem, nem a date, hanem a számlázás szempontjából. Legalább egy hétig írtam, mert nem triviális az algoritmus.
A tarifálás már egyszerű: Létrehozol awk-ban egy megfelelő n dimenziós tömböt, aztán csak rá kell engedni a rekordokat.

Az egyszerűbb script pl. lista az ügyfélszolgálatnak.
- A lista típusa és intervalluma alapján egy feldolgozási lista készítése az indexből
- az adatok kifejtése után az első filter (awk) ellátja könyvelési és egyéb információval és
elvégzi a pontos intervallumra szűrést - PIPE
- következik a sort, amelyből a script a feldolgozás típusának megfelelően paraméterezettet indítja - PIPE
- a következő filter (awk) elvégzi a göngyölítést és az END ágban megcsinálja a formátumot - PIPE
- lpr
És egy vagy több ilyen scriptet futtat a vezérlés az ügyfélszolgálat kérésére - ami akkor még Clipperben készült. ;)

Ezt manapság biztosan sql-ben írnád. Az ehhez tarozó történet: Konfiguráltam nekik egy 30x nagyobb gépet+egy kisebb tartalékot cluster-be kötve. Amint elkezdték a munkát kiderült, hogy csak 2 hónap fér fel a 18+1 helyett. De nem is ezért szerelték le a rendszert, hanem azért, mert az Oracle napi 48 óra alatt rakta rendbe magát. Fatökűek. ;)

Ez is érdekes és tanulságos, köszönöm, hogy megosztottad!
Most pedig kellemes ünnepet kívánok mindannyiunknak!
Good byte.

Restart és a /tmp kiurul. :)

Elsősorban restart single-user módban, aztán nyomozás. (Megjegyzés: ezen a gépen nincs fontos rendszer, ha lenne, akkor nem hagyták volna idáig fajulni.)

Ez a beszéd, függetlenül attól, hogy mit fogalmaztak bele a kérdésbe!

Oké, de ez hol oldja meg azt, hogy Apache folyamatosan üzemel, azaz a szolgáltatásnak futnia kell ???
Az én értelmezésemben ez azt jelenti, hogy restart nélkül kell megoldani a problémát... de javítsatok ki...

Magic is always comes with a price!

Nem oldja meg - viszont miután az ember elmondta azokat a lehetőségeket, amelyeket a feladat szövege kikényszerít, hozzáteheti, hogy aki ezt a problémát meg tudja oldani, az meg is tudja előzni, ezért ilyen állat nincs.

(Az orvosnak se mondjuk azt, hogy 'Itt a beteg, az állapota alapján kórházba kellene utalni, de kérem oldja meg valahogy másképp! Persze ha nem sikerül, maga lesz a hibás!')

De... sőt... mesélhetnék :(

[Feliratkozás]

megneznem a naptarat, hogy 2001 van-e

--
NetBSD - Simplicity is prerequisite for reliability

su

- kötet méret növelés, ha van lehetőség
- rendrakás (mindenki szedje le a felesleges vackát)
- régi logok + már felesleges dolgok + temp dolgok törlése
- ha nem lehet csak úgy kötet méretet növelni, átmeneti megoldásként: ha van olyan, amit át lehet tenni másik particióra + symlink, és ez megoldást jelentene, akkor áttenném. pl képek, logok, stb...

a felhívok egy másik rendszergazdát és átadom neki a feladatot nem játszik? :)

--
ESET és Synology hivatalos viszonteladó

Ha log a nagy akkor gzip -c logfile >/tmp/logfile.gz aztan >logfile :)

lsof vagy fuser-dV vel keresni torolt filokat, es kill process ha lehet :)

LVM mindenkepp kell hogy online lehessen novelni :D

Nem kell mindenképp LVM. :)

Igaz, nem kell, de sztem jo ha van :D

Az off-topik szétoffolása során feljött a PowerShell. Sajnos nem ismerem, de aki ért hozzá, írhatna egy példát, pl. az itt felvetett kérdésre: https://prog.hu/tudastar/201635/jar-keszitese-xsd-bol