Érdekes hibák és megoldásaik

Offtopic

Bizonyára előfordult már veled, hogy belefutottál egy olyan hibajelenségbe, amelyre előtt elsőre értetlenül álltál, de később rájöttél a megoldásra. Ha volt már ilyen és van kedved hozzá, akkor írd le a hibajelenséget ebbe a témába egy újonnan indított szálba, hadd tippelgessenek mások, hogy mi lehet a megoldásuk. A felmerülő kérdésekre ha tudsz válaszolj, és néhány nap után áruld el a megoldást.

Ha van érdeklődés, akkor igyekszem felrakni pár ilyen feladványt.

  • 3639 megtekintés

( uid_4656 v | 2014. 02. 18., k – 16:33 )

Van két https-es webszerver ugyanazon a gépen, az egyik a

https://xxx.ceg.hu:4443-on, a másik pedig a
https://xxx.ceg.hu:443-on hallgatózik.

A két webszervert két, egymástól teljesen független Tomcat példány szolgálja ki. Átlagos webalkalmazások, adnak egy login formot, amelyen be lehet lépni, majd belépés után kattintgatni a rendszerben. Hosszú ideig (1 nap) tartó inaktivitás után mindkét webalkalmazás automatikusan kiléptet. Mindkét alkalmazás kizárólag Internet Explorerből működik.

A hibajelenség: a felhasználó belép a 4443-as porton futó rendszerbe, majd az azon belüli linkre kattintva (ami egy új tabot nyit az Internet Explorer böngészőjében) átmegy a 443-as porton futó rendszerbe is, és oda is belép. Kattintgat a 443-as porton futó rendszerben és működik neki, majd random, de rövid (mindgi kevesebb, mint 5 perc) idő után a 443-as porton futó rendszer kilépteti.

Mi lehet az oka?

Igen. Itt ami érdekes, az az, hogy az Internet Explorer (és csak ő, a Firefox és a Chrome nem) https esetén (és csak https esetén, http esetén nem) nem különbözteti meg a különböző portokon futó webszerverek cookie-jait. Egy lehetséges megoldás egy CNAME a szerverre és arra felvenni az egyik webszervert.

( uid_4656 v | 2014. 02. 18., k – 16:44 )

Bizonyos domainbe léptetett Windows XP kliensgépekről nem működik jól egy webes alkalmazás. Más, ugyanabba a domainbe léptetett, ugyanazon a site-on lévő Windows XP kliensgépekről jól működik. A gépek között nincs látványos különbség, és nincs rajtuk látványos hiba sem.

A hibajelenség: a loginablak (egy webform) megjelenik, majd beírod a felhasználónevet-jelszót, megnyomd a login gombot és ezután nem történik semmi. Az alkalmazás kizárólag Internet Explorer 7-essel működik a fejlesztő szerint.

Alaposabban megnézve a sikertelen esetben az történik, hogy szépen lezajlik a login, a kliens visszakap egy cookie-t, hogy akkor ő most authentikálva van egy 5 perc múlva bekövetkező időpontig, meg egy redirectet egy Location: headerben, ami visszaviszi a login oldalról az alkalmazás oldalára. Az alkalmazás oldalától kap egy redirectet a login oldalra, majd onnan az alkalmazás oldalára, majd a login oldalra...

A cookie pontosabban ez:

Set-Cookie: UserAuthenticated; Expires=Tue, 22-Jan-2013 11:15:17 GMT; path=/;

Mi lehet a hiba oka a rosszul működő kliensen?

Azzal a redirect looppal megzavartál. :)
Ugyanis olyat már láttam, hogy az elrontott időzóna beállítás következtében (ha jól emlékszem, végeredményben programhiba volt) eleve lejártként kezelt a rendszer egy cookie-t/login sessiont, de nálam a redirect loop az kb. az, amit például a... nem tudom, hogy az mno.hu vagy a nol.hu szokott előadni a letiltott cookie-k miatt. :)

( uid_4656 v | 2014. 02. 18., k – 16:53 )

Egy C-ben írt program proxyként működik egy unix domain socket és egy TCP socket között. Mindkettőt figyeli, és ha az egyiken megjelenik valamilyen bejövő üzenet, azt továbbítja a másikra.

A hibajelenség: "ethtool -K eth0 tx off" beállítás esetében a program működik. "ethtool -K eth0 tx on" beállítás esetében a program nem működik.

Várom a tippeket, hogy egyáltalán mitől lehet ez, aztán később megmutatom a releváns részt a C programból.

Nem ez a megoldás. A releváns kódrészlet:

errno = 0;
n = write(sockFD, msgrec->Data, msgrec->DataLen);
sprintf(line, "socket errno=%1d kiírva=%1d, kellett=%1d\n", errno, n, msgrec->DataLen);
write(sockFD, '\n', 1);
if (n != msgrec->DataLen) {
sprintf(line, "socket írási hiba kiírva=%1d, kellett volna=%1d\n", n, msgrec->DataLen);
}

Ordas hiba van benne, de a kód ismeretében triviális rájönni, hogy mi.

Nem az a hiba, hanem az, hogy a második write() visszatérési értéke nincs ellenőrizve. Az ethtool -K eth0 tx off azt csinálja, hogy a kiküldött IP-csomagok checksum számítását a CPU csinálja, az ethtool -K eth0 tx on pedig ugyanezt a hálózati kártyára delegálja.

Összességében az a baj, hogy újabb vasakon a hálózati kártyák olyan intelligensek, hogy ha van offload, akkor a \n-t kiíró write() néha nem sikerül, a write() "most épp elfoglalt vagyok, próbáld meg később" hibaüzenettel tér vissza. Mivel az alkalmazás ezt nem vette észre, így simán tovább akart működni, a túloldal meg, ahol a protokoll szerint várták volna a \n-t nem tudta, hogy mi van, ezért furcsa dolgokat művelt.

tcpdump kimenetében finoman szólva nehéz észrevenni, hogy egy \n néha hiányzik a string végéről (bár végül ezt vettem észre), mert ugye a TCP intelligens és ha sikerül, akkor a két write()-ot egy csomagban akarja elküldeni...

az egy dolog, hogy a kuldo oldal hanyag (nem nezi write visszateresi erteket), de ennek nem lenne szabad nem vart dolgokra ravenni a tuloldalt. Ami ha pufferelne, akkor ez nem is sikerulne, ill. protokoll hibaval valaszolhatna a kuldo oldalnak, ami igy ujra probalkozhat(na)... :-)

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Alapvetoen egy sortores karakter hianya nem szuksegszeruen vonja maga utan azt, hogy protokollhibarol beszelunk. Ha mondjuk egy HTTP-jellegu transfer-protokollt veszunk alapul, akkor az, hogy egy \n kimarad, az legfeljebb akkor tunhet fel, ha a kliens kuld, es a tuloldal foglalkozik is a request headerben kuldott content-length fejleccel ES hiba eseten NEM fogadja el a HTTP message-t. Mivel a requestben a content-length (amennyire tudom) nem kotelezo header, igy ha nincs jelen, akkor a HTTP message abban a formaban tekintendo validnak, ahogyan az megerkezett.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

gondold at, hogy mi az a "protokoll" (=reszletekbe meno specifikacioja annak, hogy a 2 fel hogyan es mikent beszelget egymassal), aztan ha ezt megertetted, akkor te is latni fogod, hogy ha a fogado fel egy incomplete, partial uzenetet puffereles helyett elkezd feldolgozni, az bizony a protokoll megsertese.

A http-t idecitalni, es azon elkezdeni rugozni meg a problema nem ertese, amikor le lett irva, hogy "a túloldal meg, ahol a protokoll szerint várták volna a \n-t nem tudta, hogy mi van, ezért furcsa dolgokat művelt."

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( thomasrc | 2014. 02. 18., k – 17:36 )

Tetszik a téma. Jöhetnek hardveres feladványok is?

Régi (több, mint 5 éves) asztali számítógép nem akarja felismerni az USB-be dugott eszközöket. Egyszerűen nem történik semmi, ha az user bedug egy eszközt. A telepített driverek (bár driver nélkül is működnie kell egyébként) ellenőrizve, eszközkezelőben is látszanak az USB portok, csak éppen a fenti hibajelenség áll fenn. Aztán rájön az user, hogy ha újraindítja a számítógépet, akkor a bedugott eszközöket hirtelen látni kezdi a rendszer. De mindig csak újraindítás után vagy értelemszerűen akkor, ha még bekapcsolás előtt bedugja az eszközt. Vajon mi lehet a hiba oka?

Hint: hardveres oldalról közelítsétek meg a problémát.

( bzs v | 2014. 02. 18., k – 18:28 )

Nekem az egyik honlapkámon a google azt mondta, hogy malware-gyanú miatt ő nem hajlandó a találatra irányítani a júzert. Nem tudtam, mi ez. Ma sem.

Találtam valami netes malware.keresőt, azt a manual szerint futtattam, valamit az index.html mellé kellett tenni és böngészővel elindítani.

nem tudom, mit tett.
Majd mail a google-nak, pár nap múlva reagáltak, azóta minden rendben.

És nem tudom mi történt, azt sem hogy hogyan javult meg.

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( ironcat | 2014. 02. 18., k – 18:54 )

Megoldás nincs, csak a probléma:

Volt egy desktop gép (időszámítás előtt valamennyivel) egy LCD monitorral (Acer Al1714, a monitor kb. 2005-ös vásárlás. a gép régebbi). Rendben működik. Később (2007 májusában) az alaplapot kicseréltem egy egy kicsit modernebbre (GA-M59SLI-S4). Közben költöztem is (2006 ősze), és az új helyen elég gyakran volt 1-2 másodperces áramszünet, amikor a gép (és az elektronikus készülékek többsége: mikró, hálózatról működő óra, …) újraindult. Ezért aztán vettem egy UPS-t. Öröm és boldogság 2–3 napig. Aztán a gép újraindul véletlenszerű időnként. Rövid megfigyelés után kiderült, hogy a többi eszköznél nem volt áramszünet. A problémát nem sikerült megoldani. Kb. hetente egyszer-kétszer újraindult a gép. Why????
Aztán 2012-ben beruháztam egy 22"-os monitorba. Rádugtam a gépre, és azóta egyszer sem jelentkezett a probléma. Tehát a monitornak volt valami „nyűgje”. Bár azt most sem értem, hogy a legelső géppel miért nem volt gondja.

----- 

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

( uid_7086 | 2014. 02. 20., cs – 15:28 )

Kihaltunk? Ráadásul válaszok nélkül? :(

( wachag | 2014. 03. 06., cs – 09:16 )

Nekem is van egy, bár szerintem ismert a dolog (természetesen tudom a megoldást), hátha mégis lesz, akinek új.

A kérdés: mit keres az ntpdate a /etc/shadow fájlban?

A minap (példafeladatok kidolgozása közben) láttam ezt: 


lsof /etc/shadow
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
...
ntpdate 29119 root    3r   REG   8,17     1188 1312842 /etc/shadow
...

Mitől lehet?

( gee v | 2014. 03. 06., cs – 12:13 )

A következő a hibajelenség:
Van egy webes alkalmazás (Jira).
Van három laptop és három felhasználó: S, M, G.

M felhasználó M laptopjáról nem tud belépni. Hibaüzenet: your username and password are incorrect.
Új jelszót kérünk.
M a laptopjáról belép.
M kijelentkezik
M soha többé nem tud bejelentkezni arról a gépről.
M felhasználóval G és S laptopról bármikor be lehet lépni.
M laptopon S és G felhasználóval bármikor be lehet lépni.

Új felhasználót készíttettünk, M2.
M2 G laptopról be tud lépni.
M2 M laptopról nem tud belépni.

Helpdesk nem talált semmilyen problémát. M és M2 account persze nekik is működött.

Próbáltunk 3 különböző böngészőt, cookie és előzmények meg offline tárolt dolgok törlését.

Mit gondoltok, mi lehetett? (sajnos nem tudom a megoldást)

( KissT | 2014. 03. 10., h – 18:12 )

  • We're having a problem sending email out of the department.
  • What's the problem?" I asked.
  • We can't send mail more than 500 miles," the chairman explained.
  • I choked on my latte. "Come again?"
  • We can't send mail farther than 500 miles from here," he repeated. "A
    little bit more, actually. Call it 520 miles. But no farther.

( lajos22 | 2014. 03. 11., k – 01:55 )

Probléma van. A hajam hullik már tőle.

Adott egy gép 1 darab SATA HDD-vel. A probléma: 1-2 havonta a gép elhányja magát, hogy ő a HDD-t nem látja semerre. Ekkor a SATA kábelt 1-es portból a 2-es portba át téve 1-2 napig jó, mikor ismét elhányja magát a gép, és vissza kell tolni a kábelt az 1-es portba. ismét 1-2 hónapig semmi baja.

Az, hogy csak kihúzom, bedugom az 1-es porton, nem oldja meg.
Kábel csere, HDD csere is volt azóta. Nem javult. A csatlakozókat már megtisztítottam, de semmi, 1-2 hónap múlva megint...

Legutóbb belerúgtam, akkor jó volt egy órára...

Amúgy azért nem készült még 'SATA HDD "Móka"... Avagy Agyfaszt kaptam megint...' blogbejegyzés, mer fingom sincs mi a megoldás... De ha megvan, esküszöm megejtem szokás szerinti megfogalmazásban... :D

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Lapcserét én is megpróbálnám, csak nincs mire. Ilyen free meló ez, nem szívesen költenék rá, ő meg nem tud.

Vezetékezés környéke alatt a lapon lévő szálakra gondolsz? Nagyítóval ránézhetek, hátha. Ez első generációs SATA, szóval bőven lehet szar a csatlakozás a lapon.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64