Начало
Сообщения об ошибках в /var/log/messages
1.hostname inetd[123]: pop-3/tcp server failing(looping). Service terminated.
2. ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
3.kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT
4.kernel: 1.2.3.4 sent an invalid ICMP error to broadcast
5.19-Dec-2005 03:33:29.304 general: error: errno2result.c:109: unexpected error:
19-Dec-2005 03:33:29.304 general: error: unable to convert errno to isc_result: 14: Bad address
19-Dec-2005 03:33:29.304 client: error: UDP client handler shutting down due to fatal receive error: unexpected error
6.
1. Сообщение вида
hostname inetd[123]: pop-3/tcp server failing(looping). Service terminated.
Через 10 минут pop3-сервер сам поднимается.
Это не ошибка pop3-сервера.
Это сообщение может появится в логе в том случае, если pop3-сервер запущен через inetd(т.е.
в /etc/inetd.conf есть строка:
pop3 stream tcp nowait root /usr/sbin/tcpd pop3d
и ps auxw|egrep inetd дает положительный результат)
По умолчанию inetd допускает 40 соединений в минуту для одного сервиса. При превышении этого
значения он отключает соответствующий сервис на 10 минут.
Увеличить количество допустимых соединений, например до 100, можно так:
pop3 stream tcp nowait.100 root /usr/sbin/tcpd pop3d
После чего: /etc/rc.d/init.d/inetd restart
Кроме того можно использовать вместо inetd современный демон xinetd. Он предусматривает
ограничения по количеству одновременных соединений к определенному сервису и по количеству одновременных соединений с одного IP.
../imap/FAQ.txt:
"..7.16 What do the syslog messages:
imap/tcp server failing (looping)
pop3/tcp server failing (looping)
mean? When it happens, the listed service shuts down. How can I fix this?
The error message "server failing (looping), service
terminated" is not from either the IMAP or POP servers.
Instead, it comes from inetd, the daemon which listens for TCP
connections to a number of servers, including the IMAP and POP
servers.
inetd has a limit of 40 new server sessions per minute for any
particular service. If more than 40 sessions are initiated in a
minute, inetd will issue the "failing (looping), service
terminated" message and shut down the service for 10 minutes.
inetd does this to prevent system resource consumption by a
client which is spawning infinite numbers of servers. It should
be noted that this is a denial of service; however for some
systems the alternative is a crash which would be a worse
denial of service!
For larger server systems, the limit of 40 is much too low. The
limit was established many years ago when a system typically
only ran a few dozen servers.
On some versions of inetd, such as the one distributed with
most versions of Linux, you can modify the /etc/inetd.conf file
to have a larger number of servers by appending a period
followed by a number after the nowait word for the server
entry. For example, if your existing /etc/inetd.conf line
reads:
imap stream tcp nowait root /usr/etc/imapd imapd
try changing it to be:
imap stream tcp nowait.100 root /usr/etc/imapd imapd
Another example (using TCP wrappers):
imap stream tcp nowait root /usr/sbin/tcpd imapd
try changing it to be:
imap stream tcp nowait.100 root /usr/sbin/tcpd imapd
to increase the limit to 100 sessions/minute.
Before making this change, please read the information in "man
inetd" to determine whether or not your inetd has this feature.
If it does not, and you make this change, the likely outcome is
that you will disable IMAP service entirely.
Another way to fix this problem is to edit the inetd.c source
code (provided by your UNIX system vendor) to set higher
limits, rebuild inetd, install the new binary, and reboot your
system. This should only be done by a UNIX system expert. In
the inetd.c source code, the limits TOOMANY (normally 40) is
the maximum number of new server sessions permitted per minute,
and RETRYTIME (normally 600) is the number of seconds inetd
will shut down the server after it exceeds TOOMANY..."
_________________________________________________________________
../imap/BUILD: "...
IMPORTANT NOTE: inetd has a limit of how many new connections it will
allow in a certain interval, and when this limit is exceeded, it shuts down
the server. If you have anything beyond a small-scale server, you are
probably going to run up against this limit. You'll know when it happens;
your syslog will give the misleading message "imap/tcp server failing
(looping), service terminated" and users will complain that IMAP service is
unavailable for the next 10 minutes. Similarly with "pop3/tcp server
failing"...
It must be emphasized that this is *NOT* a bug in the IMAP or POP
servers, nor is it anything that I can "fix". It is an inetd problem, and
the only way to fix it is to change inetd's behavior.
By default, the parameters of this limit are (from inetd.c source code):
#define TOOMANY 40 /* don't start more than TOOMANY */
#define CNT_INTVL 60 /* servers in CNT_INTVL sec. */
#define RETRYTIME (60*10) /* retry after bind or server fail */
That is, no more than 40 connections (TOOMANY) in 60 seconds (CNT_INTL), and
if exceeded, shut down the server for 10 minutes (RETRYTIME). This was a
good setting in the 1980s ARPAnet, but is much too small today.
Some versions of inetd allow you to see a higher maximum in the
/etc/inetd.conf file. Read "man inetd" and see if you see something like
this in the text:
The wait/nowait entry is applicable to datagram sockets only [...]
[...] The optional ``max'' suffix (separated from
``wait'' or ``nowait'' by a dot) specifies the maximum number of server
instances that may be spawned from inetd within an interval of 60 sec-
onds. When omitted, ``max'' defaults to 40.
If you see this, then edit the /etc/inetd.conf entry for imapd to be
something like:
imap stream tcp nowait.100 root /usr/local/etc/imapd imapd
(or, if you use TCP wrappers)
imap stream tcp nowait.100 root /usr/local/etc/tcpd imapd
Otherwise, you'll need to edit the inetd source code to set TOOMANY to a
higher value, then rebuild inetd.
..."
Аналог для сервисов, запущенных через xinetd-демон - остановка сервиса на 10 секунд (по умолчанию) и сообщение вида:
"...
May 29 15:38:36 mail xinetd[777]: Deactivating service pop3 due to excessive incoming
connections. Restarting in 10 seconds.
May 29 15:38:46 mail xinetd[777]: Activating service pop3
May 29 15:39:32 mail xinetd[777]: Service pop3: server exit with 0 running servers
..."
Следует подправить параметр cps в xinetd.conf
2. Если /var/log/messages забивается сообщениями вида:
Jul 26 13:57:06 vicina kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
Jul 26 13:57:06 vicina kernel: skb: pf=2 (unowned) dev=lo len=120
Jul 26 13:57:06 vicina kernel: PROTO=6 127.0.0.1:60032 127.0.0.1:25 L=120 S=0x00 I=61031 F=0x4000 T=64
Jul 26 13:57:06 vicina kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
Jul 26 13:57:06 vicina kernel: skb: pf=2 (unowned) dev=lo len=52
Jul 26 13:57:06 vicina kernel: PROTO=6 127.0.0.1:25 127.0.0.1:60032 L=52 S=0x00 I=50973 F=0x4000 T=64
Jul 26 13:57:06 vicina kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
Jul 26 13:57:06 vicina kernel: skb: pf=2 (unowned) dev=lo len=60
Jul 26 13:57:06 vicina kernel: PROTO=17 1.2.3.152:32770 1.2.3.152:53 L=60 S=0x00 I=20340 F=0x4000 T=64
Jul 26 13:57:06 vicina kernel: ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING
Jul 26 13:57:06 vicina kernel: skb: pf=2 (unowned) dev=lo len=60
Jul 26 13:57:06 vicina kernel: PROTO=17 1.2.3.152:53 1.2.3.152:32770 L=60 S=0x00 I=0 F=0x4000 T=64
, то , значит, при копмиляции ядра вы включили опцию "CONFIG_NETFILTER_DEBUG=y"
make menuconfig
Device Drivers -> Networking support -> Networking Options -> Network packet filtering (replaces ipchains) -> Network packet filtering debugging.
В итоге в файле .config должно быть:
# CONFIG_NETFILTER_DEBUG is not set
Следует отметить, что указанные выше сообщения не появлялись при работе ядра 2.6.11.6 и при включенной опции Network packet filtering debugging.
У меня они появились при апгрейде на 2.6.12.3. Причина - в измененном файле .../linux/net/core/netfilter.c.
Подобные сообщения могли появляться и раньше, но при определенных обстоятельствах.
Сейчас же они сопровождают любую сетевую работу сервера.
Ссылки по этой проблеме - здесь, здесь и здесь.
3. Если в /var/log/messages при старте named появляются сообщения вида:
Jul 27 14:38:22 vicina kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT
- это ядро извещает о том, что named использует устаревшую опцию для системного вызова (файл ../linux/net/core/sock.c).
Разработчики ядра хотели бы, но не могут избавиться от нее, потому что ее использует neamed.
Этот файл можно подправить.
Л.Торвальдс в аннотации к 2.6.0 пишет:
"...- Some applications may trigger the kernel to spit out warnings about 'process xxx using obsolete setsockopt SO_BSDCOMPAT' .
- Bind 9.2.2 checks for #ifdef SO_BSDCOMPAT in correctly, so a recompile is all that is needed..."
Несмотря на то, что я использую bind версии 9.3.1, сообщение имеет место.
Еще несколько ссылок по этой теме: [1], [2], [3].
4. Если в /var/log/messages появляются сообщения вида: kernel: 1.2.3.4 sent an invalid ICMP error to broadcast
Это означает, что
"...You got a misconfigured tcp/ip stack on your network
somewhere which has a broken implementation of RFC 1122 (ICMP) - and that's
the IP of the machine. ICMP errors should never be sent regarding braodcast
frames - it'd just cause this traffic flood here..."
Может быть следствием arp-spoofing'a, неправильно настроенных параметров сети, неисправная сетевая карта.
Как временная мера - команды
echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 >/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
Ссылки по теме:
[1]
[2]
[3]
[4]
5. Если в /var/log/messages или в выделенном вами файле для сообщений named появляются сообщения вида: errno2result.c:109: unexpected error:
19-Dec-2005 03:33:29.304 general: error: errno2result.c:109: unexpected error:
19-Dec-2005 03:33:29.304 general: error: unable to convert errno to isc_result: 14: Bad address
19-Dec-2005 03:33:29.304 client: error: UDP client handler shutting down due to fatal receive error: unexpected error
Причина в ошибке ядер версии 2.6.14.
Исправлено в ядре 2.6.14.2. Но так как после этого были обнаружены другие баги, рекомендуется установить последнюю версию ядра.
У меня эта ошибка возникла при переходе на версию 2.6.14.1.
Ссылки по теме:
[1]
[2]
[3]
[4]