/kernel: file: table is full

FreeBSD-all

/kernel: file: table is full

  • 890 megtekintés

( j_szucs | 2005. 10. 14., p – 15:11 )

Tegnap dél óta ilyen hibákat kapok a FreeBSD 4.4-stable-s szerverünkön :

Oct 14 12:22:40 castor /kernel: file: table is full

Az első ilyen hiba után sehonnan sem lehet új csatlakozást létrehozni a szerveren lévő megosztásokhoz (smbd verzió: 2.0.7)

Éppen tegnap került a hálózatra az első SuSE 10.0-ás linux kliensünk, a gépneve vov, a szerveren annak a gépnek a log fájljában (/var/log/log.vov) a következőket találtam:
... rengeteg a következő két sorból: ...
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
Rejecting user 'anonymous': authentication failed
[2005/10/14 12:22:32, 1] smbd/service.c:make_connection(550)
vov (192.168.0.99) connect to service public as user nobody (uid=65534, gid=65534) (pid 59094)
[2005/10/14 12:22:32, 1] smbd/service.c:make_connection(550)
vov (192.168.0.99) connect to service public as user nobody (uid=65534, gid=65534) (pid 59093)
[2005/10/14 12:22:32, 1] smbd/reply.c:reply_sesssetup_and_X(925)
Rejecting user 'anonymous': authentication failed
[2005/10/14 12:22:32, 1] smbd/service.c:make_connection(550)
vov (192.168.0.99) connect to service public as user nobody (uid=65534, gid=65534) (pid 59095)
[2005/10/14 12:22:32, 1] smbd/reply.c:reply_sesssetup_and_X(925)
Rejecting user 'anonymous': authentication failed
[2005/10/14 12:22:32, 1] smbd/service.c:make_connection(550)
vov (192.168.0.99) connect to service public as user nobody (uid=65534, gid=65534) (pid 59096)
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
[2005/10/14 12:28:57, 0] lib/util_sock.c:read_socket_data(480)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
[2005/10/14 12:28:57, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public
... és a fenti két sor ismétlődik a logfájl végéig ...

A tegnapi /var/log/messages fájlból (13-áról, de 14.-én is ilyenekkel van tele a fájl du. 12 után):
Oct 13 12:44:55 castor /kernel: file: table is full
Oct 13 12:45:00 castor last message repeated 658 times
Oct 13 12:45:01 castor syslogd: /dev/ttyvb: Too many open files in system: Too many open files in system

A fentiek ideje alatt a root által indított smbd daemon kilép.

Lehet összefüggés az első SuSE 10.0-ás kliensünk hálózatra kerülése és a korábban stabil FreeBSD szerverünk instabillá válása között (időben a kettő éppen egybeesik)?
Ha igen, mi lehet az oka?

( LGee | 2005. 10. 14., p – 15:17 )

Hulyeseg, de azon a SuSE-n nem fut egy masik SAMBA?

( j_szucs | 2005. 10. 14., p – 15:44 )

Hulyeseg, de azon a SuSE-n nem fut egy masik SAMBA?

A user telepítette azt a gépet, úgyhogy ezt csak hétfőn tudom megnézni. Viszont most is majdnem biztos vagyok benne, hogy nem, mert szerintem azt a SuSE 10.0 se tartalmazza alapból (csak a klienst), azaz külön kell telepíteni, amit viszont a user szerintem nem tett meg.

De mi ennek a jelentősége?

Ja, és még egy gond: a hiba napjában többször is előjön; mindannyiszor kilép a szerveren a root smbd daemonja; a hiba bekövetkezte előtt nem látok túl sok nyitott fájlt, alatta viszont nem nagyon tudok nézelődni, mert az ssh-val se nagyon tudok csatlakozni, de hamégis, akkor meg még a pipe-ok se működnek a betelt fájl tábla miatt.

Ja, és még valami amit nem értek: a /var/log könyvtárban ugye náunk minden gépnek két smbd logfájlja van: /var/log/gepnev és /var/log/gepnev.old (utóbbi a régi logfájl mentése). A gepnev.old fájlban minden gépnek több hónapra visszemenően vannak bejegyzései, de ennek az egy, vov nevű kliens gépnek csak máról van pár bejegyzése mindkét fájlban. Hová tűntek a szerverről annak a gépnek a korábbi log bejegyzései? Ha a klienst újratelepítik is, a szerverről a régi log bejegyzések nem szoktak törlődni! Lehet, hogy az ő smbd processze a root processz-el együtt akadt ki és eközben törölte a régi bejegyzéseket? A többi smbd processz viszont tovább futott, ezért mások log bejegyzései megmaradtak? Ha ez így történhetett, akkor egyértelmű, hogy annak a gépnek az smb kliensével lesz valami gond.

Mi a véleményetek?

( imp | 2005. 10. 14., p – 16:18 )

[quote:651c43eeb3="j_szucs"]
Ja, és még egy gond: a hiba napjában többször is előjön; mindannyiszor kilép a szerveren a root smbd daemonja; a hiba bekövetkezte előtt nem látok túl sok nyitott fájlt, alatta viszont nem nagyon tudok nézelődni, mert az ssh-val se nagyon tudok csatlakozni, de hamégis, akkor meg még a pipe-ok se működnek a betelt fájl tábla miatt.

Ja, és még valami amit nem értek: a /var/log könyvtárban ugye náunk minden gépnek két smbd logfájlja van: /var/log/gepnev és /var/log/gepnev.old (utóbbi a régi logfájl mentése). A gepnev.old fájlban minden gépnek több hónapra visszemenően vannak bejegyzései, de ennek az egy, vov nevű kliens gépnek csak máról van pár bejegyzése mindkét fájlban. Hová tűntek a szerverről annak a gépnek a korábbi log bejegyzései? Ha a klienst újratelepítik is, a szerverről a régi log bejegyzések nem szoktak törlődni! Lehet, hogy az ő smbd processze a root processz-el együtt akadt ki és eközben törölte a régi bejegyzéseket? A többi smbd processz viszont tovább futott, ezért mások log bejegyzései megmaradtak? Ha ez így történhetett, akkor egyértelmű, hogy annak a gépnek az smb kliensével lesz valami gond.

hogy a vov smbd logfájljai miatt telne be az `open files` tábla? hm. ulimittel nem tudod megjátszani, hogy besshzva tudj lsofolni?

( pete | 2005. 10. 14., p – 17:01 )

nem értek bsd-hez, de talán segíthet:

http://lists.mysql.com/mysql/6010

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html

http://search.yahoo.com/search?p=freebsd+kernel++file++table+is+full&prssweb=Search&ei=UTF-8&fr=FP-tab-web-t&fl=0&x=wrt

( j_szucs | 2005. 10. 14., p – 17:14 )

csak máról van pár bejegyzése mindkét fájlban

Szerinted ez azt jelenti, hogy nagy a logfájlja? Épp ellenkezőleg!
És épp ez az amit nem értek: hová tűntek a több hónapos log bejegyzései, amik pedig mindenki másnak megvannak?
Ezt csak az ő smbd vagy syslogd daemonjának a kiakadásával, tudom magyarázni - ha egyáltalán lehet valamivel is.
Mindenki más log bejegyzései viszont megvannak; hiszen az ő smbd processzeik nem akadtak ki.

Egyenlőre csak ebből., és az időbeli egybeesésből tudok arra következtetni, hogy a SuSE smbd kliense tette ennyire instabillá a FreeBSD szerverünket.

Tudtok valami ötletet adni, hogy erről hogyan bizonyosodjam meg? Esetleg lehetne a szerveren csak az ő smbd daemonját magasabb debug levellel indítani? Hogyan?

( j_szucs | 2005. 10. 14., p – 17:26 )

Tudtam, hogy a kernel fájldeszkriptor számának emelése is szóba fog kerülni, csakhogy én nem látom ennek sem szükségét, sem a lehetőségét:

- hiábavaló volna, mert, mert a fájldeszkriptorok mostani beállítása eddig 60 kliens mellett is mindig elég volt, a mai napon viszont még 10 gépnek (közte az a bizonyos) se volt elég. Ebből én arra következtetek, hogy akármennyire is emelném a fájldeszkriptorok számát, az a bizonyos hiba mindig felzabálná őket kb. délre.

- nem is lehetne, mert FreeBSD 4.4-nél még nem lehet ezt csak úgy menet közben állítgatni. Kernelt kellene újat forgatni, de azt meg nem tudok, mert nincs meg a forrás. Rendszert frissíteni sincs lehetőségem, mert nem kapok rá karbantartási időt.

Vagyis nem kerülhetem meg a problémát, hanem meg kell találnom, és meg kell szüntetnem a hiba okát. Ehhez kellene egy kis segítség.

( andrej_ v | 2005. 10. 14., p – 18:57 )

[quote:5499508f3d="j_szucs"]Tudtam, hogy a kernel fájldeszkriptor számának emelése is szóba fog kerülni, csakhogy én nem látom ennek sem szükségét, sem a lehetőségét:

- hiábavaló volna, mert, mert a fájldeszkriptorok mostani beállítása eddig 60 kliens mellett is mindig elég volt, a mai napon viszont még 10 gépnek (közte az a bizonyos) se volt elég. Ebből én arra következtetek, hogy akármennyire is emelném a fájldeszkriptorok számát, az a bizonyos hiba mindig felzabálná őket kb. délre.

- nem is lehetne, mert FreeBSD 4.4-nél még nem lehet ezt csak úgy menet közben állítgatni. Kernelt kellene újat forgatni, de azt meg nem tudok, mert nincs meg a forrás. Rendszert frissíteni sincs lehetőségem, mert nem kapok rá karbantartási időt.

Vagyis nem kerülhetem meg a problémát, hanem meg kell találnom, és meg kell szüntetnem a hiba okát. Ehhez kellene egy kis segítség.

Minden hálózati kapcsolat is egy file descriptor. Nem jön valahonnan örült nagy forgalom? Próbáld meg leállítani a nélkülözhető szervízeket vagy valamit. Egyébként ilyenkor ha "nemadnakkarbantartásiidőt" mégis mi a répát várnak? Ilyenkor mondanám azt a T. fővezető úrnak, hogy vagy megcsinálhatom normálisan (4.11 update-el együtt) vagy veszem a kalapom és szivasson mást.

A SUSE klienst próbáljátok rendesen belőni, mert szerintem nem kéne 515145453x autholnia.

( j_szucs | 2005. 10. 14., p – 21:48 )

A SUSE klienst próbáljátok rendesen belőni, mert szerintem nem kéne 515145453x autholnia.

Hétfőn megnézem.
Viszont én ezt az Anonymous felhasználónéven bejelentkezést sem értem. Ilyet eddig csak windows kliensek logfájljában láttam, mi viszont itten a kde-ben rendes felhasználónévvel csatoltuk be a hálózati megosztásokat, nem pedig ezzel az "Anonymous"-al.
Most itthonról végre nyugodt körülmények között megnézhettem a szerveren a log fájlokat, és már teljesen biztos vagyok, hogy a SuSE-s 10.0-s kliens gép okozza a hibát, annyira pontos az időbeni egybeesés. Folyamatában így néz ki a dolog:

1. A probléma azzal indul, hogy a SuSE-s kliens egy Anonymous bejelentkezést indít:
[2005/10/14 12:22:32, 1] smbd/reply.c:reply_sesssetup_and_X(925)
Rejecting user 'anonymous': authentication failed

2. Erre egy másodperccel már be is telik a fájl tábla a FreeBSD szerveren:
Oct 14 12:22:33 castor /kernel: file: table is full
Oct 14 12:22:34 castor last message repeated 1695 times
...
3. Hibaüzik garmadája percekig, mindenféle szolgáltatástól, aminek új fájlra lenne szüksége, majd végül szerencsére a SuSE-s gép feladja:
[2005/10/14 12:29:17, 1] smbd/service.c:close_cnum(583)
vov (192.168.0.99) closed connection to service public

4. Pár másodperccel ezután visszatér a szerveren a normál ügymenet; megjelenik az első szokásos log bejegyzés, és megszűnnek a "file table full" üzenetek:
Oct 14 12:29:25 castor stunnel[394]: localhost.pop3 connected from 192.168.2.71:1360

( andrej_ v | 2005. 10. 14., p – 22:10 )

Ezzel szerintem írj egy mailt a SUSE-nak is, mert igazából ledosolja a szervert, pedig csak probal "nehany" logint. A masik gond, hogy miért nem szünnek meg a TCP kapcsolatok és miért nyílik mindíg új.