Fórumok
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.
Hozzászólások
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?
Találgatás, minden alap nélkül: cookie kavarodás?
Nem rossz az irány. Hogyan szüntetnéd meg?
Erre a rendszer ismerete nélkül nem tudok válaszolni.
Talán a sütik neveit ellenőrizném, hogy pl. session adatokat nem tárol-e azonos néven a két rendszer.
Ha előttem lenne az épp döglődő kliens, valószínűleg magam wiresharkhoz nyúlnék :)
Igen, mindkét rendszerben van JSESSIONID, az alapján tartja nyilván a session-t szerver oldalon. De ez önmagában még nem magyarázza meg a dolgot, hiszen két külön webszerverről van szó...
Na itt jön az, hogy a web sohasem volt az én világom.
Úgy emlékeztem, hogy a cookie domainhez, nem alkalmazáshoz köthető.
Hiába két webszerver, de egy böngésző. Ha X szerver kiküld egy cookie-t, aztán Y is kiküld egy ugyanolyan nevűt, akkor az felülírja az előzőt. A cookie nincs porthoz kötve: http://stackoverflow.com/questions/1612177/are-http-cookies-port-specif…
--
Akkor vehetem úgy, hogy ez volt a beugratós kérdés? :)
A példádban X és Y inkább alkalmazás, mint szerver.
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.
Most megint tanultam valami újat(?).
Én úgy tudtam, hogy porttól függetlenül kezelik a böngészők a cookie-kat, kizárólag a domainhez kapcsolva.
Hát ennek utánanézek, mert valahol ez nekem nem kerek.
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?
Időzóna?
Ez megmagyarázza a redirect loopot?
Bocs, figyelmetlen voltam csak a cookie-ra figyeltem.
Egyébként igen, megmagyarázza a redirect loopot, jó a megoldás.
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. :)
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 volt adatvesztés amikor működni látszott?
Javítson ki valaki ha rosszul tudom, de mintha a tx off kikapcsolná a flow controlt.
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.
A
write(sockFD, '\n', 1);
lenne az ordas hiba a
write(sockFD, "\n", 1); helyett?
Viszont ha tényleg ez, akkor az az ethtool tx on/off mit csinál valójában? (én csak annyit értettem meg a doksiból, amire céloztam: flow controll ki-/bekapcs)
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...
Köszi. Sajnos e szerint igencsak félreértettem a doksit.
Figyelmetlenül olvastam. Nem tűnt fel, hogy tx on/off több dologra használatos.
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.
--
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)
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.
Hasonló jelenség, de nyilván más: frissült a kernel, de nem lett újraindítva a gép. Egyszer-kétszer már sikerült belefutnom.
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. ---
---
az index fájlokba kerültek kártékony kódok akár FTP-n keresztül, amiket a malware kereső kiszedett?
valami malware oldal a te oldaladra hivatkozott esetleg?
akár egy egyszerű kis képre, s emiatt téged se szeretett a google?
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.
-----
Olyat küldj inkább, amire tudod a megoldást :-)
Kihaltunk? Ráadásul válaszok nélkül? :(
Ja, nem lett nagy keletje a dolognak. Felejtős itt.
És hol nem? Én az ilyenek miatt maradtam itt... :(
-
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:
Mitől lehet?
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)
az M2 az jira acc, vagy unix/win acc a laptopon?
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
Mindegyik Jira acc volt.
Windows accountokkal nem variáltunk.
Amikor azt mondom, X laptopja, akkor X laptopja és X windows felhasználó.
ok, en azt mondanam, csak probalj meg az M laptopon egy masik win usert, azzal belepni, majd M jira acc-ot kiprobalni.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
Sajnos ez a hajó már elúszott. Tavaly júliustól októberig gondolkozott a helpdesk, hogyan lehetne megoldani a problémát, akkor M elment a cégtől.
Most már se account, se laptop.
Csak azért írtam, mert én ilyen problémát nem láttam még és fogalmam sincs, mi okozhatta.
Jira nem ismerős: flash-t nem használ? A szerver logjához gondolom, nem fértek hozzá.
Úgy látom, ez valami javas cucc. Appletet is használ?
Op.rendszer és esetleg a java verziók egyformák a laptopokon?
Appletet nem. Tudtommal. Flash-t nem.
Szerver loghoz a helpdesk valószínűleg hozzáfér, de nekem csak annyit mondtak, hogy megnéztünk mindent és minden jó.
S és M gépe ugyanolyan volt elméletileg. Adott image-ből felhúzott céges laptop.
little bit more, actually. Call it 520 miles. But no farther.
alacsony TTL és messzebbre több hop kellett volna?
Biztosan valami timeout jellegű dolog lehetett mögötte.
Hat ez gyors volt, de akkor ime a teljes story.
http://www.ibiblio.org/harris/500milemail.html
mas tollaval ekeskedsz. Sajat problemat tessek bedobni...
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
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
Valami hajszálrepedés csatlakozó, vezetékezés, akármi környékén?
Alaplapcserét nem írtál, én azt is megpróbálnám.
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
Igen, alaplapon levő szálak, illetve forrasztások.
A gond az, hogy van olyan, hogy nem látod. Akár a hely miatt (takarás), akár azért, mert mondjuk csak bizonyos esetben jelentkezik (pl. adott hőmérséklet, ez-az).