unable to open incoming connection: Bad file descriptor

[arno]

seit kurzem spammed der proftpd mir meine logfiles mit folgender meldung voll:

proftpd[1670]: [<hostname> - Fatal] unable to open incoming connection: Bad file descriptor

dabei steigt die zahl hinter proftpd (die pid ist es nicht, die bleibt laut 'ps ax' immer gleich...) einloggen kann ich mich problemlos auf den server... auch downloads sind kein problem soweit ich das testen konnte... kann mir vielleicht einer helfen die lösung zu finden?

gruß arno

[arno]

noch mehr infos:

xxx root # proftpd -n -d 9
 - parsing '/etc/proftpd/proftpd.conf' configuration
 - FS: using system open()
 - FS: using system read()
 - dispatching auth request "getpwnam" to module mod_sql
 - dispatching auth request "getpwnam" to module mod_auth_file
 - dispatching auth request "getpwnam" to module mod_auth_unix
 - dispatching auth request "getgrnam" to module mod_sql
 - dispatching auth request "getgrnam" to module mod_auth_file
 - dispatching auth request "getgrnam" to module mod_auth_unix
 - <Directory />: adding section for resolved path '/'
 - FS: using system read()
 - FS: using system close()
xxx.de -
xxx.de - Config for xxx FTP-Server:
xxx.de - /
xxx.de -  AllowOverwrite
xxx.de -  RequireValidShell
xxx.de -  Umask
xxx.de - ServerIdent
xxx.de - DefaultServer
xxx.de - IdentLookups
xxx.de - RequireValidShell
xxx.de - Umask
xxx.de - ExtendedLog
xxx.de - UserID
xxx.de - UserName
xxx.de - GroupID
xxx.de - GroupName
xxx.de - DefaultRoot
xxx.de - dispatching auth request "getgroups" to module mod_sql
xxx.de - dispatching auth request "getgroups" to module mod_auth_file
xxx.de - dispatching auth request "getgroups" to module mod_auth_unix
xxx.de - SETUP PRIVS at main.c:2711
xxx.de - ROOT PRIVS at main.c:1953
xxx.de - RELINQUISH PRIVS at main.c:1959
xxx.de - ROOT PRIVS at main.c:2320
xxx.de - opening scoreboard '/var/run/proftpd/proftpd.scoreboard'
xxx.de - RELINQUISH PRIVS at main.c:2344
xxx.de - ROOT PRIVS at inet.c:452
xxx.de - RELINQUISH PRIVS at inet.c:510
xxx.de - ProFTPD 1.2.9rc2 (devel) (built Thu Oct 30 14:30:46 CET 2003) standalone mode STARTUP
xxx.de - ROOT PRIVS at main.c:2168
xxx.de - RELINQUISH PRIVS at main.c:2174
xxx.de - FS: using system lstat()
xxx.de - FS: using system lstat()
xxx.de - ROOT PRIVS at main.c:1145
xxx.de - RELINQUISH PRIVS at main.c:1149
xxx.de - Fatal: unable to open incoming connection: Bad file descriptor
xxx.de - FS: using system lstat()
xxx.de - FS: using system lstat()
xxx.de - ROOT PRIVS at main.c:1145
xxx.de - RELINQUISH PRIVS at main.c:1149
xxx.de - Fatal: unable to open incoming connection: Bad file descriptor

usw (repeat)...

xxx root # proftpd -vv
 -          Version: 1.2.9rc2 (devel)
 - Scoreboard Version: 01040002
 -      Build Stamp: Thu Oct 30 14:30:46 CET 2003

xxx root # uname -a
Linux xxx.de 2.4.22 #8 SMP Fri Sep 19 14:22:17 CEST 2003 i686 Intel(R) Pentium(R) III CPU 1133MHz GenuineIntel GNU/Linux


brauch hier dringend hilfe!!!

[stonki]

seit kurzem spammed der proftpd mir meine logfiles mit folgender meldung voll:

proftpd[1670]: [<hostname> - Fatal] unable to open incoming connection: Bad file descriptor

dabei steigt die zahl hinter proftpd (die pid ist es nicht, die bleibt laut 'ps ax' immer gleich...) einloggen kann ich mich problemlos auf den server... auch downloads sind kein problem soweit ich das testen konnte... kann mir vielleicht einer helfen die lösung zu finden?

gruß arno

also von der meldung habe ich heute das erste mal gelesen und einmal den Entwickler direkt im IRC Chat gefragt:

<Stonki> http://www.proftpd.de/forum2/viewtopic.php?t=485
<castaglia> that sort of message can happen if something connects to proftpd, then disconnects very rapidly, while proftpd is still determining information about that connection

also im Endeffekt würde ich sagen, dass da einer Dein System scannt oder zumindest Deinen FTP, ob er eine Verbindung akzeptiert. Schaue mal nach, von welchen IP's das ausgeht....

cu
stonki

P.S. Er meinte noch, das wenn man hinter Load Balancer ist, diese ähnliche Meldungen provozieren können

[arno]

sowas hab ich auch schon vermutet, aber ich kann keine anzeichen dafür finden... der rechner steht hinter einer firewall die mehrere flood-controls hat, da kommt sowas nicht durch... ich werd morgen mal mit tcpdump der sache auf den grund gehen