Legnagyobb UpTime amit valaha láttál

Szerverek

Kéne frissítenem egy Promox szerver 4.4-et 6.0-ra. Most nézem hogy az uptime rajta 698 day
Nincs szívem hozzányúlni :)
Ez egy HP ML150G6 Proxmox 4.4-el aktívan használt gép 9 guest-el, a BIX-ben (Victor Hugo) van, ezt csak azért írom, mert az áramellátás sem lényegtelen.
Örömmel venném, ha írnátok ilyen gépekről extrém uptime-val amivel összefutottatok, egy pár szót a vasról, meg mi van rajta.
Attól most diszkréten tekintsünk el, hogy miért nem volt frissítve, meg security veszély stb :D

  • 4924 megtekintés

( STP | 2019. 08. 27., k – 21:07 )

4 számjegy alatt nem foglalkozunk ilyennel... ;)

( ncc1701 | 2019. 08. 27., k – 21:09 )

Novell 3.1x szerver valami 1800-1900 nap körülre emlékszem. Az már alakulhat. :) Valami HP vason, de a vasat nem mi üzemeltettük, meg asszem irreleváns is.

( fsanyee | 2019. 08. 27., k – 21:23 )

nalam 2342 nap volt a max amit le kellett allitanom, mert athelyeztek a DC-n belul nemreg.
SUN FIRE X4170 M2 amin Solaris 10 fut.

( _ventura_ v | 2019. 08. 27., k – 21:29 )

Hirtelen ezt találtam :>


[ventura@node0 ~]$ who -b
system boot 2015-03-14 06:58
[ventura@node0 ~]$ uptime
21:26:11 up 1627 days, 13:27, 1 user, load average: 6.00, 6.07, 6.11

CentOS 6, dell blade pengén, van belőle még 5db azoknak is ennyi az uptime. HPC cluster condor ütemezővel.

Fedora 30, Thinkpad x220

Heh, nekem a saját asztali gépemen átlag 40-50-es a load és simán tudok dolgozni mellette (2x 2690 Xeon, 192GB DDR3).
 

$ uptime
 07:50:49 up 24 days, 22:31,  1 user,  load average: 44,93, 44,23, 43,56

Off: lehet kellene egy "legnagyobb load ami mellett még tudtál dolgozni" topic ;-)

kedz

Enyemben 72 van. Semmifele kontener vagy VM

Photoshop, Indesign. Print ready anyagokat configolok.

Ma pl az egyik master pdf majdnem 300MB-volt ( ez mar a kesz anyag ) Ezeket mozgatnj is kell. Egy ilyen file export elott tobb giga. Ha epp dolgozom valamin nem lovok ki mindent ha hirtelen hozza kell nyulni egy masikhoz.

( szilard_ v | 2019. 08. 27., k – 21:32 )

Nyáron belefutottam egy geologia kiállításba. Itt tudtam meg, hogy a Föld kora ~4,6 milliárd év.
Szóval a legnagyobb uptime körülöttem 4.6 milliárd év. :D

( Pene | 2019. 08. 27., k – 21:44 )

most épp ez a legnagyobbabb:

$ uptime
21:39:22 up 1518 days, 23:24, 1 user, load average: 0.60, 0.41, 0.37
$ who -b
system boot 2015-06-30 22:05

itt már az első oldalon is van több 3k+ napos: https://www.reddit.com/r/uptimeporn/

( ppenta | 2019. 08. 27., k – 21:44 )

Most néztem rá...
Win XP 1058 nap, 3 óra, 34 perc, 3 másodperc :-)
Win XP 1064 nap, 8 óra, 17 perc, 34 másodperc :-)

Mind a kettő hp xw4600.

----------------------------------------------------------------------------------------------------
Hármas........alá............kettes.........................egyest írtam be.

Videót digitalizál 0-24-ben. Már rég le kellett (lehetett) volna cserélni, de ha működik akkor most minek piszkáljam. Nem lélegeztető gép szóval, ha megáll akkor legfeljebb nem megy tovább.

----------------------------------------------------------------------------------------------------
Hármas........alá............kettes.........................egyest írtam be.

( Elbandi v | 2019. 08. 27., k – 21:50 )

cisco 4948:
XXXXXXX uptime is 7 years, 6 weeks, 6 days, 19 hours, 6 minutes
System returned to ROM by reload
System restarted at 21:54:53 MET_DST Tue Jul 10 2012
System image file is "bootflash:cat4500-entservicesk9-mz.122-53.SG1.bin"

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mi meg azzal, hogy nem frissítettük meg nem cseréltük, hiába volt EoS a cucc... az ügyfél em akart sem leállást, sem további költségeket. Nagyvállalati hálózati környezetben simán lehet találni 7-8 éves uptime-okat, sajnos.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( sigellef | 2019. 08. 27., k – 23:22 )

Nálam az áramszolgáltató mindig gondoskodott róla, hogy az uptime ne menjen 200 nap fölé :D Amúgy 10 év lazán meglett volna. 2007-ben pakoltam össze, UHU linux volt rajta, nfs + ftp -re volt használva 2017-ig. Amíg a merevlemez ki nem fingott, addig a bekapcsológombon kívűl máshoz nem volt nyúlva.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( szazol | 2019. 08. 27., k – 23:59 )

$ uname ; uptime
Linux
23:43:16 up 3017 days, 6:10, 1 user, load average: 0.00, 0.04, 0.00

/sys/class/dmi/id/board_vendor:ASUSTeK Computer INC.
/sys/class/dmi/id/board_name:P5K PRO

Deninetnél van elhelyezve.

( BognarB v | 2019. 08. 28., sze – 00:09 )

Ismerosnel ESX 4.x (vagy 3?) cluster, 3db IBM node + storage, 25xx nap körül volt tavaly nyáron amikor ott voltam. Azóta sem állították le éles üzemből..

Személyes:
Windows 2003, HP ML110 G6-on, 900 nap, napi 200-220GB adat mozgatással.

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

( KeeF | 2019. 08. 28., sze – 00:21 )

AIX 5.3 - 3070 nap. van screenshot valahol rola, majd eloturom.

( cvk v | 2019. 08. 28., sze – 06:36 )

Egy kicsit korábbi proxmox :)

$ uptime
06:36:07 up 1581 days, 16:18, 7 users, load average: 2,49, 2,56, 1,72

( peterson v | 2019. 08. 28., sze – 06:55 )

Nem értem ezt az uptime fétist.
Ha tényleg diszkréten eltekintünk a frissítésektől (mi nem szoktunk, bár valóban nem is kapkodunk vele :) , akkor is egy server élettartama véges. Ha másért nem, a rajta futó szolgáltatás fejlődik úgy hogy másik vas kell.
Szóval a 8-10 év körüli uptime nem akorra dicsőség. Inkább az elhanyagolás jele, amit a rendszer véletlenül hosszabb távon túlélt. ;)

---
"A megoldásra kell koncentrálni nem a problémára."

Dehogynem, működhet.
Viszont ami például bindet futtat élesben azt frissíteni is illik.
Ha 8-10 éve érintetlenül fut egy névszerver, az szerintem hanyagság.

Nem vita tárgya, hogy technikailag ez lehetséges.
Csak nem feltétlenül jelent dicsőséget az, hogy nem nyúltunk hozzá évek óta.

---
"A megoldásra kell koncentrálni nem a problémára."

egy redhat lts-nek siman van 10+ supportja, ha bindben vagy a tobbi szolgaltatasban van hiba az amugy is frissul, ha a kernelben, akkor el kell donteni hogy erint-e vagy sem (pl floppy modulban, ha nincs floppy a gepben)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Kernel? BIOS?
Nem azt mondom, hogy elképzelhetetlen egy 10 éve non-stop működő rendszer, csak néha illik distupgrade-et csinálni, vagy kernelt frissíteni.

A te logikád szerint szerint sosem szabadott volna senkinek a Zsigulit lecserélni, mert mindig is működött.

Én azt mondom, hogy haladni kell a kernel, és/vagy bios és/vagy idrac és/vagy RAID vezérlő firmware verziókkal, hogy jobb és hatékonyabb legyen a rendszer.
Attól, hogy a rendszeredre nem néztél rá sok-sok éve, és nem is kaptál hibajelentést, még lehet hogy nem optimális.
Az új verziókból te is tanulsz, a frissítés a szolgáltatás szempontjából tekinthető stressz-tesztnek.

Ezek elhanyagolása "dehát működik" alapon szerintem nem ad okot az öndícséretre, és én nem hirdetném nyilvánosan screenshotokkal hogy milyen régóta nem foglalkoztam a rám bízott rendszerrel.
Vagy tegyél mellé egy listát arról, hogy mikor mit frissítettél.
Esetleg egy apt(-get) update kimenetet.

---
"A megoldásra kell koncentrálni nem a problémára."

Minél régebben nem nyúlunk hozzá egy szerverhez, azon belül a firmware-hez, kernelhez, OS komponensekhez, alkalmazásokhoz, annál jobban gyűlnek benne a lehetséges attack vektorokat felépítő elemek, ezt tök felesleges tagadni.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Azaz a biztonsággal nem törődve, csakis a szolgáltatás hibátlan elérését tartja szem előtt? Közben meg már rég ellopták a felhasználói adatokat, amiket a hozzáférésekkel együtt a darkweben árulnak, az átjáróházként/botnet tagként üzemelő szervereiken coint bányásznak, a napi néhány millió spam kiküldése után pedig más szervereket támadnak? Úgy gondolom, hogy igen, hibás :)

Mondjuk ha ez a szolgáltatás cégen belül van, azaz a saját hálón szolgáltat és a saját háló és web közötti védelem naprakész és jól tervezett, akkor ez a patch-elési mánia többet árt, mint használ, de minimum rengeteg pénzbe kerül egy nagy cégnél. Ez tapasztalat. Ha a weben lóg a szolgáltatás, akkor igaz az állítás, hogy vétkes hanyagság a javítócsomagok azonnali felrakásának mellőzése. De az azonnali itt sem azonnali, mert láttunk már karón varnyút és olyan patch-et, ami több hibát hozott tudottan, mint amit javított. :) Tehát nem biztos, hogy hanyagság a patch-ek mellőzése. Ez a körülményektől függ.

"Ez a körülményektől függ"
Így van. Ezért nem értem, hogy miért ekkora gyönyör néhány embernek a a bazi nagy uptime.
Nekem 1,5 év körüli a legnagyobb. Ennek oka HW garanciák, a firmware verziók, a kernel verziók, stb.
Nem balesetek, hanem tarvazatt reboot-ok.

Az, hogy találtál a pincépen a salgó pocon egy 10éve futó UHU linuxot, az nem dicsőség. Sőt...
Az a lényeg, hogy ha az uptime-fetisiszák szerint az enyém kicsi (~650 nap), akkor nézzük már meg, hogy a reboot-ot mi indikálta?
És ha ebből a szempontból nézzük meg, akkor a "hozzértő odafigyelés", és "nemtörődömség" kerülhet szembe.

Másik paraméter amit figyelni lehet: downtime! Értem én, hogy 10 év alatt a tiéd nulla, de ha én az enyémnek holnap nyomok egy init 6 -ot, az 120sec-en belül szolgáltat. A 10 éve futó dinoszaurusz esetében biztos vagy benne, hogy reboot-olható?

---
"A megoldásra kell koncentrálni nem a problémára."

Magam sem értem. Messze a legstabilabb szerver volt. Semmi rejtélyes reboot, logban hiba. Ezt bekapcsoltad bármikor, ment. Előtte 2, azelőtt 1 éves uptime-ja volt, 3 év volt a max. Mondom lefrissítem és ahogy hozzányúltam, rebootoltam, egyre xarabb lett. Legvégül egy debian netinstall is 1 óra alatt mászott fel. Én még linuxot olyan lassan települni sosem láttam. Ja, debiant kellett rátenni, mert az xcp-ng elhasalt. Előtte xenserver volt rajta, megnéztem ismét azzal. Az a telepítő is elhasalt. Teljesen rommá zuhant a gép. Ki kellett kukázni. Oké, 10+ éves volt. De ezen 10 év alatt, amíg nem buzeráltam sokat, ment és csak ment 0-24.
Volt, hogy egyszerre 150db linux VM futott róla opensource XEN-nel virtualizálva. Sosem kellett félnem attól, hogy túlterhelem, ledobja a diszkeket a RAID kártya, mint a 3ware kártya csinálta másik gépben. Egy öszvér volt. 10+ év alatt 16-ból 3db SAS diszket kellett cserélni, a többi a lekapcsolás napjáig pörgött 0-24. Hjaj, kicsit a szivemhez is nőtt :)

Igen, így érhet a legnagyobb meglepetés, mikor valaki bentről támad, vagy csak véletlenül viszi be kintről a jóságot. A belső hálózaton sem lehet megúszni a javítások telepítését. Nyilván mindig lehet mérlegelni, de ahhoz követni kell minden javítás megjelenésekor a changelogot, a hibák súlyosságát, kihasználhatóságuk nehézségét. Belső hálózaton mellőznéd pl. a windows frissítéseket? Végeztek mellette rendszeres sérülékenység-vizsgálatokat? Jelzést kaptok arról, ha valaki scanneli a hálózatot? Aztán majd egy reggel a jól védett belső hálózaton ott figyel majd minden gépen egy zsarolóvírus üzenete...gondolom az nem hiányozna senkinek.

Tagadni valóban felesleges - vitatni azért lehet.
Volt már olyan frissítés, amely sajnálatos módon a frissüléssel együtt bugot is csempészett a kódba - nem szándékosan. Az így sérülékennyé vált program korábbi változata ezzel a támadással szemben rezisztens maradt. (A nehezebben értők kedvéért: nem a frissítés ellen akarok beszélni, csak rámutatni arra, hogy az sem csodaszer és nem garancia semmire.)

A biztonság kapcsán azt is érdemes lehet megemlíteni, hogy ez nem kizárólag a programon múlik.
Sok disztró alapban bekapcsolt tűzfallal érkezik - na de ez a tűzfal a befelé forgalmat korlátozza csak! De ha egy porton eleve nincs szolgáltatás, akkor ott nincs törhető program sem! Ezen a ponton az, hogy egy icmp reject helyett nem megy vissza válasz, mert a tűzfal DROP policy érvényesül, nem nagy védelem. Ugyanakkor a törhető szolgáltatáshoz a forgalom be van engedve, hiszen ha nem lenne, a szolgáltatás se lenne nyújtható. Viszont ugyanezen tűzfal output policy ACCEPT, azaz sikeres törés után a gépről a garázda program bárhova kimehet! Sokat ér egy ilyen tűzfal... Nyilván az output ágat is illik finomítani: a szolgáltatás válasz csomagjai kimehetnek, kérhetünk névfeloldást (a reolv.conf-beli DNS-ektől), elérhetünk ntp szervereket (az ntpd.conf-ban felsoroltakat) - slussz! Innen kezdve esélytelen a kapcsolódás botvezérlőhöz, kriptovaluta bányászat se megy, stb. (Igen, ebben az esetben a program törése sikeres, de a kívánt cél elérése ennek ellenére sem sikerült.)
Emellett érdemes magát a programot is védedni - AppArmor, de pláne: SeLinux. Amikor a program nem tudja kiírni a futtatandó rossz indulatú kódot, de a mondjuk pont olyan helyre ír, ahova üzemszerűen teszi, akkor sincs joga futtatni a kódot - innen kezdve a sebezhető, sérülékeny program sem nagyon vehető rá nem kívánatos működésre...

Mivel az uptime növekedése kontra biztonsági kockázat a frissítés elmaradása témakörben sikerült egy kis kitérőt tenni, nézzük meg jobban az uptime-t:
* egy szolgáltatás frissítése, majd a frissítés érvényre juttatásához egy szolgáltatás újraindítása nincs hatással az uptime-ra,
* egy kernel frissítés már izgalmasabb téma, ám nem napjaink találmánya a kernel csere on-the-fly. Így viszont akár kernel is frissíthető úgy, hogy nem nullázódik az uptime.

Tehát egy magas uptime nem szükségszerűen indikálja a frissítések hiányát.

"Tehát egy magas uptime nem szükségszerűen indikálja a frissítések hiányát."
Ez ebben formában igaz.

Viszont az is igaz, hogy a sudo joggal rendelkező userek száma, és az uptime napjainak szorzata nagyjából annak a mérőszáma, hogy mennyire rettegünk egy init 6 -tól. (gondolok itt a röptiben belőtt iptables sorokra, vagy a kézzel indított szarságokra, esetleg a hálózati cstoló on-the-fly piszkálása, persistent config piszkálás nélkül)

Jelenleg minden általam üzemeltetett rendszeren nyomhatnék reboot-ot, úgy hogy induláskor működik és szolgáltat. (Bár a szolgáltatás kiesés 2perce, és a kapcsolódó serverek döccenése, helyreállása lehet az állásomba kerülne, ezért nem fogadok ;) )
Az on-the-fly kernelfrissítések, és sok-sok éves uptime, valamint 1-nél több sudo-joggal megáldott user mellett, tegye fel a kezét aki nyugodt szívvel nyomna reboot-ot. :D

---
"A megoldásra kell koncentrálni nem a problémára."

Ez általában a kisebbik probléma, a nagyobbik baj fizikai gép esetén, hogy ha N év után bármiért újra kell indítani, akkor hatványozott az esély valamilyen hw hibára a mozgó alkatrészek környékén.

Sok esetben az üzemeltető maga nem dönthet, hogy "márpedig most rebutálok", vagy egyszerűen csak elborult időpontokra lehetne szervezni. Az "ez egy ilyen szakma" nem hat meg, mert visszafelé kevés esetben megy a "jó akkor fizesd ki az éjjeli műszakot", csak a "dehát aszittük...". Csak jön az ekézés a hozzáállásról, meg a zsetonmániáról.

Részben egyetértek de vegyük észre hogy mennyire lelassult a hardverfejlődés (elsősorban a CPU-k fejlődése). Ha a 10 évet nézzük, az Intel már a Core i7-nél járt. Ha ezt a 10 évet visszadatáljuk a Pentium2-esek környékére, sokkal nagyobb ugrásokat láthatunk. Szóval az hogy 3-5 évente komplett gépeket kell kidobni, "merlassúaproci", már eléggé a múlté (igaz a saját hardver is, de most tekintsünk el ettől).

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

( davebacsi | 2019. 08. 28., sze – 07:26 )

[xxx-prod: root@xxxxxxxx-appl01 ~]# ssh xxxxxxxx-sig02
Password:
Last login: Wed Aug 28 05:22:02 2019 from xxxxxxxx-appl01
Oracle Corporation SunOS 5.10 Generic Patch January 2005
root@xxxxxxxx-sig02#uptime
5:22DE up 7179 day(s), 4:33, 2 users, load average: 0,99, 0,88, 0,87
root@xxxxxxxx-sig02#uname -a
SunOS xxxxxxxx-sig02 5.10 Generic_147440-05 sun4v sparc SUNW,Sun-Fire-T200

( Proci85 v | 2019. 08. 28., sze – 09:31 )

Szép eredmények vannak. Nálam ~1400 nap volt a max.
Ugyanakkor elgondolkodtató, hogy ezeken a helyeken mennyire számítana a kernel frissen tartása? Mindig jönnek ki újabb kernel security bugok. Egy netre kötött gép esetén nem hangzanak jól ezek magas uptime értékek.

( uid_4263 v | 2019. 08. 28., sze – 09:24 )

Service uptime sokkal érdekesebb mint valamelyik random szerver uptime-ja :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

( Zsugabubus | 2019. 08. 28., sze – 16:23 )

Még csak ennyi:

16:21:47 up 1426 days, 23:14, load average: 0.00, 0.01, 0.04

Egy szerver processz rajta:
-r--r--r-- 1 root root 0 Jun 13 2017 /proc/3090/cmdline
Még alig múlt 2 éves.

( E-Medve v | 2019. 08. 28., sze – 19:29 )

Egy első generációs Banana Pi:
19:26:44 up 1274 days, 19:43, 1 user, load average: 0.03, 0.02, 0.05

( coptair | 2019. 08. 28., sze – 21:52 )

Most épp ennyi...

$ uptime
21:38:15 up 1816 days, 10:42, 1 user, load average: 0.55, 0.66, 0.70

$ who -b
system boot 2014-09-07 10:56

( SchTamas | 2019. 08. 29., cs – 07:11 )

Nekem 19 359 nap, 7 óra 10 perc 05 másodperc az uptime-om! :D Ennek kb. 2/3-át végig láttam és kb. csak az 1/3-át aludtam át. Bocs!

( kisg v | 2019. 08. 29., cs – 10:54 )

Linuxos szervernél (on the fly kernel patching esetén is) én inkább gáznak, a karbantartás hiányának érzem a nagy uptime-ot. Ti mit gondoltok erről?

( junior013 | 2019. 08. 29., cs – 11:50 )

Ugyan nem szerver:

Cisco IOS Software...
uptime is 10 years, 27 weeks, 6 days, 20 hours, 25 minutes

(de lehet, hogy szervert is találnék mellette, ha hozzájuk férnék - akkor épült az épület :) )

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( _ventura_ v | 2020. 09. 03., cs – 21:11 )

Szerkesztve: 2020. 09. 03., cs – 21:12

Pont a mai nap lett szép kerek szám:

 21:09:57 up 2000 days, 13:11,  1 user,  load average: 0.00, 0.01, 0.00

system boot  2015-03-14 06:58

Fedora 42, Thinkpad x280

Nálam rpi-k mennek 24/7 minimális load-al, de nem mondanám feleslegesnek. Gépek backupjai, pihole, network share az alapvető dolguk, ezekből egyik sem ipari load mégis azonnal észrevenném ha 5 percnél tovább kiesne.

Illetve ha filmezünk akkor arról megy a plex, ilyenkor megugrik a load rendesen ha transcodeolni kell, ettől függetlenül ha most megnézem szintén ilyen nullás loadok lennének rajta.

( oszfer | 2020. 09. 03., cs – 22:28 )

Szerkesztve: 2020. 09. 03., cs – 22:28

egy Dell szerverem

 22:26:48 up 1937 days, 14:19,  1 user,  load average: 0.36, 0.23, 0.24

de ez itt csak helyezésre jó :-)

Azért meg lehetne próbálni különválasztani a gép, az OS és az infrastruktúra (villany, hűtés) dicséretét a rendszergazda hanyagságától. Az, hogy valami ennyit elment, a mai vasak és OS-sek minősége mellett mégiscsak egy teljesítmény.

trey @ gépház

Az, hogy valami ennyit elment, a mai vasak és OS-sek minősége mellett mégiscsak egy teljesítmény.

Ez igaz. De az init 6 kérdés még áll.
A nagy uptime önmagában akkor sem dicsőség.

Szerintem az uptime nagysága, és a reboot-ban rejlő kockázat mértéke mutat némi korrelációt. :)

Illetve a firmware frissítés sem ördögtől való dolog. Hogy hanyagság-e a hiánya? Éles szolgáltatás esetén alapvetően az. Izolált helyen egy static html kiszolgálásáhz nyilván nem kell lehozni a csillagokat, de a nagy uptime akkor sem dicsőség.
Ha olyan öreg a vas, hogy már nem kap firmware frissítést, akkor a reboot a vas kora miatt már kockázat, és a nem elköltözés a hanyagság. (Ami lehet, hogy a vezetés hanyagsága, mert nem ad másik vasat)

"A megoldásra kell koncentrálni nem a problémára."

Az éremnek két oldala van. Láttam én már olyan firmware frissítést, amit úgy baszott el valamit, hogy nem volt visszaút. A jó rendszergazda ismérve az is, hogy mielőtt egy ilyet meglép, mérlegeli, hogy mekkora lehet az impact-je, ha rosszul sül el. Mert bizony a büdzsé tervezése nem az ő feladata. Sokszor azzal dolgozik, ami van. Nem azzal, amivel szeretne.

trey @ gépház

Valóban, de igaz fordítva is. Amikor a gyári firmware a szar, és egy bios frissítés javít egy HW hibának tűnő rendszeres dmesg jelzést.

14. generációs Dell-eknél már többször belefutottam. :( Új generáció, modern, de a firmware-eket mintha elkapkodták volna. Tudnék mesélni... ;)

Kiforrott szériánál évente jön ki 1-2 FW frissítés, ami talán nem is érint. Új szériánál szinte hetente, és leginkább bugfix.

Kicsit csalódás volt 5+ év dell használat után. :(

De pl idrac esetén a frissítés szükséges volt mikor bejött a html5 konzol a java fos konzol mellé. Bár az nem igényel reboot-ot.

Mindegy, értelek. Csak te is érts meg engem. :)

"A megoldásra kell koncentrálni nem a problémára."

Azt gondolom, hogy a kulcsszó a _döntés_.

Ha az üzemeltető tisztában van a frissítés létezésével, megnézte mit tartalmaz, és azt a döntést hozta, hogy nem frissít, akkor nem vitatkozom, ez rendben van. (A döntés oka lehetne egy külön topic, de azt most ne feszegessük. :) 

De ha nem is nézi meg a gyártó oldalát, fogalma sincs róla hogy van frissítés, pláne arról hogy miért, az hanyagság. És így uptime-ra mellet döngetni. ...

"A megoldásra kell koncentrálni nem a problémára."

Jó, de ha többéves uptime-od van, akkor azért már eléggé biztos lehetsz benne, hogy az a firmware alkalmas volt az oprendszer bootolására... Biztonsági javításon kívül más okod nem nagyon lehet frissíteni. De belső hálón egy soha újra nem bootolt gép esetén a biztonsági javítás sem biztos, hogy olyan nagyon érdekes...

( dyra | 2020. 09. 04., p – 13:56 )

Szerkesztve: 2020. 09. 04., p – 13:58

2004 körül az egyik első melóim során csináltam egy SAMBA, FTP, MAIL szervert. Egy kis egyházi szervezetnek. Hárman dolgoztak az irodában. Az átlagosnál minőségibb alkatrészek kerültek bele pl olyan táp, alaplap és RAM ami 24 órás folyamatos működést is bírja és egy komolyabb APC szünetmentes (amit lehet passzivban találtam ki). Többi cucc mezei. Nem volt drága két vinyó szoftveres RAID. Az összerakás után munkahelyet váltottam majd évekig nem is halottam felőlük.

2015 körül csöngött a telefon, a fickó hívott azt mondja jó nehéz volt kinyomozni a számom de valami baj van a szerverrel mert mostanában kicsit lassú. Meg kellene hogy nézzem :D 

Bakker kimentem a gépen már csak a tápventi megyegetett a CPU venti néha forgott de inkább nem. Kiló por. A problem az volt, hogy az egyik vinyó megdöglött :D

Kifújtam a port kerestem bele egy másik vinyót (használtat) nyomtam rá egy frissítést a szar ventiket is kidobtam majd azóta is megy :D Bár kb 2016 óta nem hívtak. Szóval kitudja?

( Mcsiv v | 2020. 09. 04., p – 18:41 )

Ez volt hirtelen a legoregebb amit talaltam, de tuti van 2000+ -os is

18:40:12 up 1302 days, 18:05,  1 user,  load average: 0.01, 0.03, 0.05

// Happy debugging, suckers
#define true (rand() > 10)

( salaud v | 2020. 09. 05., szo – 07:07 )

Egyik budapesti egyetemen egy selejtezési maradékból összetákolt P3-as gép suse linuxszal közel nyolc évet ment folyamatosan egy kis laborban az A3-as scanner mögé rejtve, amíg ki nem halt belőle a slim IDE maxtor hdd. Annyi dolga volt, hogy ha scanneltek, a képet feltolta a belső netware szerverre automatikusan. A szoba közel pormentes volt, túlméretes apc volt előtte, de én is meglepődtem, amikor egy látogatás alkalmával szóltak, hogy nézzek már rá, mert nem kerülnek fel a képek a belső hálóra.

Eleve szivességből raktam össze anno, mondtam bocsi, mintha lenne helyi rendszergazda, oldja már meg. Legyintettek, úgymaradt. Féltek a rendszergizda elrontja a scannert... 😃

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

( _Gabor_ | 2020. 09. 29., k – 16:33 )

$ uptime
 16:30:00 up 3470 days, 17:20,

:(

Az igen. Szerintem az ilyen hosszú uptime max. cirkuszi mutatványnak jó, nem fokmérője semmilyen stabilitásnak meg rendelkezésre állásnak. Ugyanis attól, hogy x ezer napja megy, az nem azt jelenti, hogy pl. net nem esett ki mögüle, RAID tömb nem lett rajta újraépítve, beragadt processzek, betelt log nem volt rajta takarítva valami probléma miatt, vagy beragadt service nem lett újraindítva rajta. Sokkal inkább ma már a túl hosszú uptime gáz szerintem, mert azt jelenti, hogy rég nem volt frissítve, ami biztonsági kockázat. Inkább legyen 60-180 naponta frissítve, karbantartva, újraindítva, essen csak ki előre tervezhetően maintenance okán idle-időszakokban 1-2 percre. Az sokkal jobb, mintha 3000+ nap után esik ki, de váratlanul, és hosszabb ideig megy a vergődés, hogy nem lehet pótolni, időben talpra állítani.

Ez a hosszú uptime még a DOS-os meg Win9x-es, kora NT-s időkben volt szó.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( athila v | 2020. 09. 29., k – 17:14 )

Cisco 7206VXR (NPE-G1)
uptime is 9 years, 6 weeks, 3 days, 16 hours, 14 minutes

Összehasonlítod az almát a körtével. A Voyager brothers-t arra tervezték, hogy ne álljon le amíg van energia. 

Egy server hw-t a 7/24-es üzemelésre terveztek, kb 2-5 évre, de sem a firmware, sem az os, sem az egyes alkalmazások specifikációjában nem szokott benne leni, hogy soha ne induljon újra.

Frissíteni kell. Vannak frissítések, amik restartot igényelnek. Ennyi. 

"A megoldásra kell koncentrálni nem a problémára."

( gretipapa | 2020. 10. 05., h – 10:35 )

AIX 5.3

# uptime

  09:33AM   up 3053 days,   7:23,  5 users,  load average: 3.25, 2.90, 2.75