[Users] What is this on my log???

Tue Apr 27 15:16:18 EDT 2010

Reviewing my log i see this:

Hi, im getting this log on my server

  --------------------- Kernel Begin ------------------------

  WARNING:  Kernel Errors Present
    EDAC k8 MC0: extended error code: ECC error ...:  120 Time(s)
    EDAC k8 MC0: general bus error: participating p ...:  120 Time(s)

  ---------------------- Kernel End -------------------------

Ing. Alejandro M.
-----------------------
Hospedaje Web y Servidores Dedicados
http://www.dedicados.com.mx
-----------------------
ventas at dedicados.com.mx
-----------------------

El 27/04/2010 01:22 p.m., Maxim Dolgikh escribió:
> This is high enough for most cases, but i do not have an idea if it is enough
> for your server, this depends on what the server is doing. Also it could be
> under an attack or could be compromised and doing network scan itself.
>
> You can check how many connections in ip_conntrack table with:
> wc -l /proc/net/ip_conntrack
>
> On Tuesday 27 April 2010 20:18:33 SD :: Ventas wrote:
>    
>> [root at www ~]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
>> 65536
>> [root at www ~]#
>>
>> mmm, that is a high value, maybe can be under an attack??? or is a
>> normal value????
>>
>> thanks
>>
>>
>> Ing. Alejandro M.
>> -----------------------
>> Hospedaje Web y Servidores Dedicados
>> http://www.dedicados.com.mx
>> -----------------------
>> ventas at dedicados.com.mx
>> -----------------------
>>
>> El 27/04/2010 11:36 a.m., Maxim Dolgikh escribió:
>>      
>>> Hello,
>>>
>>> "Apr 27 10:15:44 www kernel: ip_conntrack: CT 0: table full, dropping
>>> packet."
>>>
>>> This means that there are more connection then allowed by ip_conntrack
>>> module. In this case server is droping new connections. You can check how
>>> much connections are allowed with:
>>> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
>>>
>>> You can try to increase it, for example double the returned value and
>>> pass it to the module:
>>> echo N>   cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
>>>
>>> N - new connections limit.
>>>
>>> On Tuesday 27 April 2010 17:52:06 SD :: Ventas wrote:
>>>        
>>>> What is this??
>>>>
>>>> Apr 27 09:37:39 www kernel: EDAC k8 MC0: extended error code: ECC error
>>>> Apr 27 09:37:40 www kernel: EDAC k8 MC0: general bus error:
>>>> participating processor(local node response), time-out(no timeout$
>>>> Apr 27 09:37:40 www kernel: EDAC MC0: CE page 0x9d4c2, offset 0x878,
>>>> grain 8, syndrome 0x1, row 0, channel 1, label "": k8_ed$
>>>> Apr 27 09:37:40 www kernel: EDAC k8 MC0: extended error code: ECC error
>>>> Apr 27 09:37:57 www kernel: EDAC k8 MC0: general bus error:
>>>> participating processor(local node origin), time-out(no timeout) $
>>>> Apr 27 09:37:57 www kernel: EDAC MC0: CE page 0x9d4c2, offset 0x878,
>>>> grain 8, syndrome 0x1, row 0, channel 1, label "": k8_ed$
>>>> Apr 27 09:37:57 www kernel: EDAC k8 MC0: extended error code: ECC error
>>>> Apr 27 09:37:59 www kernel: EDAC k8 MC0: general bus error:
>>>> participating processor(local node response), time-out(no timeout$
>>>> Apr 27 09:37:59 www kernel: EDAC MC0: CE page 0x9d4c2, offset 0x878,
>>>> grain 8, syndrome 0x1, row 0, channel 1, label "": k8_ed$
>>>> Apr 27 09:37:59 www kernel: EDAC k8 MC0: extended error code: ECC error
>>>> Apr 27 09:38:54 www avahi-daemon[31389]: recvmsg(): Resource temporarily
>>>> unavailable
>>>> Apr 27 09:40:54 www avahi-daemon[31389]: recvmsg(): Resource temporarily
>>>> unavailable
>>>> ...
>>>> Apr 27 10:14:55 www kernel: ip_conntrack: CT 0: table full, dropping
>>>>    packet. Apr 27 10:14:57 www avahi-daemon[31389]: recvmsg(): Resource
>>>>    temporarily unavailable
>>>> Apr 27 10:14:59 www kernel: printk: 39 messages suppressed.
>>>> Apr 27 10:14:59 www kernel: ip_conntrack: CT 0: table full, dropping
>>>>    packet. Apr 27 10:15:06 www avahi-daemon[31389]: recvmsg(): Resource
>>>>    temporarily unavailable
>>>> Apr 27 10:15:26 www kernel: printk: 13 messages suppressed.
>>>> Apr 27 10:15:26 www kernel: ip_conntrack: CT 0: table full, dropping
>>>>    packet. Apr 27 10:15:30 www last message repeated 5 times
>>>> Apr 27 10:15:39 www kernel: printk: 28 messages suppressed.
>>>> Apr 27 10:15:39 www kernel: ip_conntrack: CT 0: table full, dropping
>>>>    packet. Apr 27 10:15:39 www kernel: ip_conntrack: CT 0: table full,
>>>>    dropping packet. Apr 27 10:15:44 www kernel: printk: 41 messages
>>>>    suppressed.
>>>> Apr 27 10:15:44 www kernel: ip_conntrack: CT 0: table full, dropping
>>>>    packet. Apr 27 10:15:49 www kernel: printk: 31 messages suppressed.
>>>>
>>>> I see it on the log of my server, then servers goes down, i need to
>>>> restart it.
>>>>
>>>> what can be that? and how to solve it.
>>>>
>>>>
>>>> Ing. Alejandro M.
>>>> -----------------------
>>>> Hospedaje Web y Servidores Dedicados
>>>> http://www.dedicados.com.mx
>>>> -----------------------
>>>> ventas at dedicados.com.mx
>>>> -----------------------
>>>>
>>>> El 26/04/2010 10:28 a.m., Robert Brockway escribió:
>>>>          
>>>>> Hi all.  I swear that when I first started using OpenVZ a few years
>>>>> ago that the maximum VEID was 32767.  I've just RTFMed now and can't
>>>>> find a reference.
>>>>>
>>>>> As a test I just generated a VE with a VEID over 400000.  This is
>>>>> probably the first itme I've tried to generate a VEID over 32767.
>>>>>
>>>>> So what is the maximum VEID?
>>>>>
>>>>> Are there any hidden problems if I start using VEIDs over 32767?
>>>>>
>>>>> We're running OpenVZ on Lenny (Debian 5.0) with a
>>>>> 2.6.26-2-openvz-amd64 kernel.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Rob
>>>>>            
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openvz.org
>>>> https://openvz.org/mailman/listinfo/users
>>>>          
>>      
>    