On Tuesday 17 June 2003 09:01, Farkas Levente wrote:
> hi,
> so my biggest problem is that, when I've got these error and keep
> getting the error, than do wc -l /proc/net/ip_conntrack and it's just
> 300-400 so I assume 48632 is more than enough. am I wrong?
Hmm no not wrong, i am sure that wc -l
This is something I have been wondering about as well ...
-Original Message-
From: Maxim Koshelev [mailto:[EMAIL PROTECTED]
Sent: 17 June 2003 13:38
To: [EMAIL PROTECTED]
Subject: Re: threads problems in RedHat9??
---INTERNET EMAIL NOTIFICATION---
This email originates from the Inte
hi,
so my biggest problem is that, when I've got these error and keep
getting the error, than do wc -l /proc/net/ip_conntrack and it's just
300-400 so I assume 48632 is more than enough. am I wrong?
Balint Cristian wrote:
On Tuesday 17 June 2003 15:23, Farkas Levente wrote:
hi,
I forgot to menti
Tarhon-Onu Victor wrote:
On Tue, 17 Jun 2003, Balint Cristian wrote:
you can change it:
[EMAIL PROTECTED] root]# echo 1024000 > /proc/sys/net/ipv4/ip_conntrack_max
Be careful if increase will eat more memory
Or if you don't have {S,D}NAT rules in the nat table it would be
wise to r
Hello again,
All work fine with linking vs /lib/i686. Just one broblem left:
how to built on generic RH9 host without changing permisions on
/lib/tls or removing them...
Thanks again to Thomas.
Thomas Bailey wrote:
>Maxim,
>
>I had a similar problem - the destructors associated with thread
>spe
On Tuesday 17 June 2003 15:23, Farkas Levente wrote:
> hi,
> I forgot to mention that it can't be the reason:
> # cat /proc/sys/net/ipv4/ip_conntrack_max
> 48632
>
> Balint Cristian wrote:
> > [EMAIL PROTECTED] root]# cat /proc/sys/net/ipv4/ip_conntrack_max
> > 8184
> >
> > It is 8000 entry by defa
On Tue, 17 Jun 2003, Balint Cristian wrote:
> you can change it:
> [EMAIL PROTECTED] root]# echo 1024000 > /proc/sys/net/ipv4/ip_conntrack_max
>
> Be careful if increase will eat more memory
Or if you don't have {S,D}NAT rules in the nat table it would be
wise to rmmod ip_conntrack
hi,
I forgot to mention that it can't be the reason:
# cat /proc/sys/net/ipv4/ip_conntrack_max
48632
Balint Cristian wrote:
[EMAIL PROTECTED] root]# cat /proc/sys/net/ipv4/ip_conntrack_max
8184
It is 8000 entry by default
you can change it:
[EMAIL PROTECTED] root]# echo 1024000 > /proc/sys/net/ip
[EMAIL PROTECTED] root]# cat /proc/sys/net/ipv4/ip_conntrack_max
8184
It is 8000 entry by default
you can change it:
[EMAIL PROTECTED] root]# echo 1024000 > /proc/sys/net/ipv4/ip_conntrack_max
Be careful if increase will eat more memory
On Tuesday 17 June 2003 14:29, Farkas Levente wrot
On Tue, 17 Jun 2003, Maxim Koshelev wrote:
> Thanks Thomas,
> I'll try this workarround today.
> But why redhat team distribute such broken library?
Ah, the joys of bleeding-edge software.
--
Please, reply only to the list.
Join the "Linux Support by Small Businesses" list at
http://mail.co
Thanks Thomas,
I'll try this workarround today.
But why redhat team distribute such broken library?
Thanks again for explanation.
Maxim.
Thomas Bailey wrote:
>Maxim,
>
>I had a similar problem - the destructors associated with thread
>specific storage are not called in the RH 9 pthread library ei
hi,
we've a fully updated rh8.0 firewall with kernel-2.4.20-18.8,
iptables-1.2.6a-2. we got the following error about once a week:
-
Jun 13 05:21:41 portal kernel: ip_conntrack: table full, dropping packet.
Jun 13 05:21:47 portal last message repeated 10 time
Maxim,
I had a similar problem - the destructors associated with thread
specific storage are not called in the RH 9 pthread library either.
You can work around this by linking against the pthread and libc
libraries in /lib or /lib/i686, which seem to work. Unfortunately, the
only way I could do t
13 matches
Mail list logo
