Debian szerver Bus error

Fórumok

Sziasztok!

Van egy dedikált szerverem a Hetznernél, amin Debian 8.11 fut.

Ma délután az egyik chroot környezetből másoltam át fájlokat egy másik chroot környezet /home/webxxx/usr/lib/ könyvtárába, amikor megszakadt az SSH kapcsolatom a szerverrel. Próbáltam más felhasználókkal bejutni SSH-n, de mindig a Network error: Connection refused hibát kaptam.

A Hetzner robot felületén kértem egy újraindítást, de ezután sem sikerült elérnem a szervert. A szolgáltatások is leálltak: apache, dovecot, postfx, pure-ftp-mysql, stb.

Kértem KVM stiwch hozzáférést a debugoláshoz.

# php -v
Bus error

# /etc/init.d/apache2 start
failed
/usr/sbin/apache2ctl : line 138: 14489 Bus error $HTTPD ${APACHE_ARGUMENTS} -t

# bconsole
Bus error

Debugolás közben ilyen üzenetek jelentek meg:

server-problem-20200309

Kértem a Hetznertől merevlemez ellenőrzést. Lefuttatták, és nem találtak hibát:

"The HDD check just finished and didn't find any problems. So, we have updated both the BIOS of the server and the firmware of the HDDs and booted the system again normally."

Van valakinek tapasztalata ilyen hibában? Merre keressem a hiba forrását?

Előre is köszönöm a segítséget,

Gyula

Hozzászólások

A /var/log alatti állományok megtekintése is hasznos lehet: kern.log, syslog, messages...

A shell, ami indul, statikusan linkelt?

Ha szerencséd van, akkor fent van a smartctl és elindul. Ez esetben a lemezről is kaphatsz némi infót...

Esetleg memteszt futtatása - már ha tudsz olyat bootolni. (Ha szerncséd van, akkor telepítve lett és GRB tudja tölteni. Ha nincs szerencséd, akkor a KVM mellé kérned kell egy install image-t is, rajta memtest-tel.)

Szerkesztve: 2020. 03. 09., h – 21:58

Köszönöm a hozzászólásokat. Ezeket sikerült kigyűjtenem.

smartctl: https://pastebin.com/ie7VP8Ey

dmesg: https://pastebin.com/0xwvGUqf

kern.log: https://pastebin.com/YGFEyJyJ

messsages: https://pastebin.com/mmCXNGXJ

A syslog nagyon hosszú. Abból esetleg szűrjek rá valamire?

A shell, ami indul, statikusan linkelt?

/bin/bash-t használok. Hol tudom megnézni, hogy statikusan linkelt-e?

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

> /bin/bash-t használok. Hol tudom megnézni, hogy statikusan linkelt-e?

# file /bin/bash

Ha a kimenetben a "dynamically" szó van, akkor dinamikus, ha a "statically" akkor statikus linkelésű. Hasonlóan ha az

# ldd /bin/bash

akár egyetlen "libizé =>" kezdetű sort tartalmaz, akkor dinamikus, ha pedig "not a dynamic executable", akkor statikus.

 

Amúgy nálam a bus error hardver hibát sugall. Én memóriára gyanakodnék, de persze ahogy írták, a diszkvezérlő is lehet. (És ezek miatt egy / több sérült fájlrendszer.)

Mindkét vinyó smart-ja jó? Mert csak az egyiket linkelted...

Szerkesztve: 2020. 03. 09., h – 22:33

Igaz. Köszönöm!

Az előző a /dev/sda volt, linkelem a /dev/sdb-t: https://pastebin.com/eujWwUtb

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Hát, a bus error lehet attól is szerintem hogy már sérült a fájlrendszer.... De valami valószínűleg hardveresen is szar, ahogy mások is írták már, memtest, meg valami terheléses teszt boot cd-ről, hátha az kimutat valamit... A fájlrendszert és a raid-et meg nem kéne tovább gyalázni, amíg nem derül ki mi a rossz...

égett vas szagot érzek ...

van a fiókban 1 ugyanilyen alaplapod?

a gépemen volt 1 hasonló jellegű történet, az elmelegedett  hídvezérlő baromsággal firkálta tele a lemezt

a rendszer nem indult, az adatokat úgy kellett visszavarázsolnom, a mentett logban semmi, de a hdd fizikailag rendben volt

a lapot kukázni kellett, a lemez kibírta, ... mentés, takarítás után kiválóan működött 1 új rendszerrel 

Sajnos nincs ugyan ilyen alaplapom. Ez egy dedikált szerver németországi szerverközpontban.

Tapasztalatlan vagyok ilyen fizikai jellegű hibakeresésekben, és a Hetznertől nem kaptam eddig érdemben segítséget (a HDD ellenőrzésen kívül).

Kérek most tőlük memtest futtatására lehetőséget.

A fájlrendszer ellenőrzésének mi a pontos menete?

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Sikerült elindítani egy Rescue system módot, amiben kiadtam az alábbi parancsot:

memtester 28G

Most épp ez fut. Meglátjuk mit ad eredményül.

Ezután lefuttatnék egy fájlrendszer ellenőrzést. Milyen módszert tudtok ajánlani ehhez?

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

BUS errort úgy emlékszem utoljára akkor kaptunk amikor a vinyó vezérlő volt hibás. Nem mindig jött elő, csak néhány naponta. A gép hasonlóan kockára fagyott miközben bizonyos részei működtek: pl pingre válaszolt, de de belépni nem lehetett. A vezérlő cseréje oldotta meg a dolgot.

Kedves Darkfish,

A vinyó vezérlő hibáját ki lehet mutatni valamivel? Ha lefut a memtest és az fsck és nem javul a helyzet, akkor kérnem kellene tőlük egy ilyet, de valamivel alá kellene támasztanom a kérésemet.

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Szerkesztve: 2020. 03. 10., k – 08:17

Lefutott a memtest és nem látok benne hibát.

https://forum.hetzner.com/attachment/3892-memtester-28g-ok-png/

Az fsck -y /dev/sda azt írja, hogy
/dev/sda is in use.
e2fsck: Cannot continua, aborting.

Az fsck /dev/md2 pedig clean.

https://forum.hetzner.com/attachment/3894-fsck-md2-clean-png/

Mit tudok még csinálni?

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Kedves Zahy,

Lehet, hogy félreértek valamit az eddigi módszerben, de úgy értettem, hogy a Rescue systemben nem a működő rendszerrel dolgozok. Vagy nem tudom mire írtad ezt.

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Nem értesz félre semmit, viszont milyen rescue az, ami mégis csak használ valamit az éles rendszerből? Az a "/dev/sda in use" pedig azt jelenti, hogy használatban van.  Látatlanban azt mondanám, ez egy olyan rescue, ami az éles rendszerből indul, de pl. csak a legszükségesebb FS-eket csatolja fel (azaz szerintem valami olyasmi, amit hagyományosan single user - esetleg: maintenance, karbantartó - módnak mondtak). Tehát nem egy másik háttértárról bootol - pedig inkább olyan kellene.

Értem. Köszönöm a magyarázatot.

A Rescue system oldalon azt írják, hogy "The Hetzner Rescue System is a Linux live environment that allows you to have administrative access to your server. The environment starts from the network (PXE boot) and runs in the memory of the server. This makes it possible to carry out repairs to the installed system, to check file systems or to install a new operating system."

https://wiki.hetzner.de/index.php/Hetzner_Rescue-System/en

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

A rescue rendszerek egy része hajlamos olyan mókára, hogy az egyértelműen észlelt raid tömböt összerakja. Ilyenkor az sda nem azért lesz használatban, mert csatolták, hanem azért, mert valamely raidtömb része. Ilyen esetben roppant egészségtelen, ha bármiféle fs javítást csak a tömb egyik elemén végzünk - az öntökönszúrás minősített esete. Megjegyzem: régebbi md tömbök esetén a raidblokk info a blokkeszköz végén helyezkedik el, tehát egy fsck simán tudja olvasni a blokk eszközt mint nem raid eszköz is.

Ilyen esetben az fsck-t ildomos a megfelelő tömbre - pl. /dev/md1 - futtatni...

Ezt a választ kaptam a Hetznertől:

We can offer you the following options for the server:

1. Exchange the server, but keep the drives:
To rule out a majority of the sources of hardware error, it is possible for us to exchange your server but keep all of your drives. The server would need to be shut down for approximately 20-30 minutes.

If you would like to take advantage of this option, please inform us which time and date would be best for us to shut down the server.

Please note: It may be necessary to make changes to the operating system after the system has been replaced. For more information see https://wiki.hetzner.de/index.php/System_adjustments_after_server_replacement

If the system is not reachable after the replacement, we can start the Rescue System and give you a temporary password. On request, we can also provide you with a KVM console.

2. Exchange the server and exchange the drives:
To rule out all sources of hardware error, there is also the option of exchanging the entire server, including the drives. After the exchange, we would start your server in the Rescue System and provide you with the temporary password, enabling you to reinstall the server. In this option, we are happy to reinstall your server for you following the exchange if you tell us what the operating system of your choice is: http://wiki.hetzner.de/index.php/Standardimages/en

Should you choose this option, please confirm that you agree to complete data loss and provide us with a date and time in CET that is convenient for you for the exchange of the server.

Please inform us of your preferred option.

Az 1. módszer szimpatikusnak tűnik, mert az adatok megvoltak amikor legutóbb normál boot volt.

Kíváncsi vagyok, hogy milyen lesz ezután.

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

As requested, we have exchanged your server ad took over the drives. Your server is now back online and booted into the installed OS. Unfortunately it is not reachable so you may have to adjust your network configuration to the new MAC address. Therefore we have connected a KVM console to your server.

KVM switch beenged, de az apache2 szolgáltatás továbbra sem indul.

https://forum.hetzner.com/attachment/3895-after-server-change-png/

"We don't stop playing because we grow old; we grow old because we stop playing." George Bernard Shaw

Ha fontosak az adatok, akkor a legjobb megoldás ha szólsz valakinek aki nagyobb tapasztalattal bír, mert elég sok buktatója van még innen a sztorinak: Ugye a kiindulás az, hogy van egy sérült fájlrendszered meg egy kitudja mennyire konzisztens raid1-ed, meg potenciálisan hibás hard diszkeid. Ha az adatok megőrzése az elsődleges, akkor le kéne mindent (mindkét vinyót külön külön) menteni image-be, és azokon (azok másolatán) próbálkozni helyreállítással. Ha ez nem praktikus, vagy nem ér ennyit, akkor is lehet próbálkozni, de lehet hogy a végén kevesebb adatod marad, mint ami ezen a ponton megmenthető lett volna.

Én lehet azt csinálnám, hogy az egyik vinyót kicseréltetném Hetznerrel (ugye nem mindegy hogy melyiket, meg kéne nézni hogy a raid tömbök konzisztensek-e a rendszer szerint, és nyilván azt kéne kivetetni, amelyiken a "régebbi" állapot van, tehát amelyik még nem szinkronizált be. Ha esetleg a rendszer szerint szinkronba vannak, akkor meg azt a vinyót kéne kivetetni, amelyik a smartnál a High_Fly_Writes hibákat írta.). Ja, és meg kéne kérni a Hetznert hogy egy ideig azért őrizze meg a kivett vinyót...

Utána rescue rendszerből nyomnék fsck -f -et az mdX eszközökön, majd utána bootolnám be az éles rendszert. Ezen a ponton ha nem megy valami, akkor az elvileg már csak attól lehet hogy megsérült maga a rendszerfájl is amit az adott program használna. Ekkor vagy újra kell rakni a rendszert, vagy megpróbálhatsz minél több csomagot újrainstallálni, talán felülírják a korrupt fájlt... Ha ezután minden megy jól, akkor van egy működő rendszered. Az üres vinyóra ekkor lehet újraépíteni a raid-eket.

Ha közbe jön valami, akkor a Hetznernél letárolt diszken még megvan elvileg az adatok többsége, akkor azzal lehet eljátszani ugyanezt...