Markus Koßmann wrote:
Am Dienstag, 1. November 2005 07:35 schrieben Sie: [...]
-------------------------------------------SNIP---------------------------- ----- presario:/usr/src/linux # rcnamed start Starting name server BIND named: capset failed: Operation not permitted: please ensure that the capset kernel module is loaded. see insmod(8) startproc: exit status of parent of /usr/sbin/named: 1
Is the module capability.ko loaded ? If not; does loading the module solve the problem ?
I made sure it was loaded with 'modprobe capability', but named still crashed. 'lsmod' showed that 'capabilily' was used 0 times. I have the latest version of bind from the apt-get repositories. Before that, I downgraded to the version on my 9.3 DVD and got the same results (crash, same error message). So, I begin to suspect the problem is with the '/etc/sysconfig/named' configuration script.
* On Tue, Nov 01, 2005 at 04:34 AM (-0500), Constantine 'Gus' Fantanas wrote:
I have the latest version of bind from the apt-get repositories. Before that, I downgraded to the version on my 9.3 DVD and got the same results (crash, same error message). So, I begin to suspect the problem is with the '/etc/sysconfig/named' configuration script.
Which kernel version do you use? At least, there seems to be an issue with bind and vanilla-2.6.14: http://lkml.org/lkml/2005/10/29/247 http://lkml.org/lkml/2005/10/30/32 Bye, Steffen
Steffen Moser wrote:
* On Tue, Nov 01, 2005 at 04:34 AM (-0500), Constantine 'Gus' Fantanas wrote:
I have the latest version of bind from the apt-get repositories. Before that, I downgraded to the version on my 9.3 DVD and got the same results (crash, same error message). So, I begin to suspect the problem is with the '/etc/sysconfig/named' configuration script.
Which kernel version do you use?
At least, there seems to be an issue with bind and vanilla-2.6.14:
http://lkml.org/lkml/2005/10/29/247 http://lkml.org/lkml/2005/10/30/32
--I am using SuSE's 2.6.14. Thank you!!!!! Sooooooo, it seems I need to downgrade to a 2.6.13 kernel...
Bye, Steffen
Hi Constantine, * On Tue, Nov 01, 2005 at 04:57 AM (-0500), Constantine 'Gus' Fantanas wrote:
--I am using SuSE's 2.6.14. Thank you!!!!! Sooooooo, it seems I need to downgrade to a 2.6.13 kernel...
You can also try if this patch (against 2.6.14) helps: --- a/net/core/datagram.c 2005-11-01 11:38:31.000000000 +0100 +++ b/net/core/datagram.c 2005-11-01 11:38:45.000000000 +0100 @@ -213,6 +213,10 @@ { int i, err, fraglen, end = 0; struct sk_buff *next = skb_shinfo(skb)->frag_list; + + if (!len) + return 0; + next_skb: fraglen = skb_headlen(skb); i = -1; At least it fixed a problem with "traceroute" on 2.6.14 for me. And this problem seems to be related to the "bind" problem I've told you about in my previous mail. So perhaps it may help for you, too (at least if your "bind" problem has the same origin like the one I wrote about). Bye, Steffen
Steffen Moser wrote:
Hi Constantine,
* On Tue, Nov 01, 2005 at 04:57 AM (-0500), Constantine 'Gus' Fantanas wrote:
--I am using SuSE's 2.6.14. Thank you!!!!! Sooooooo, it seems I need to downgrade to a 2.6.13 kernel...
You can also try if this patch (against 2.6.14) helps:
--- a/net/core/datagram.c 2005-11-01 11:38:31.000000000 +0100 +++ b/net/core/datagram.c 2005-11-01 11:38:45.000000000 +0100 @@ -213,6 +213,10 @@ { int i, err, fraglen, end = 0; struct sk_buff *next = skb_shinfo(skb)->frag_list; + + if (!len) + return 0; + next_skb: fraglen = skb_headlen(skb); i = -1;
At least it fixed a problem with "traceroute" on 2.6.14 for me.
And this problem seems to be related to the "bind" problem I've told you about in my previous mail. So perhaps it may help for you, too (at least if your "bind" problem has the same origin like the one I wrote about).
--Thanks a lot, Steffen! I did not patch the 2.6.14 kernel; I returned to 2.6.13 and all my problems with bind and traceroute went away. Actually, I was unaware that the traceroute problem was caused by the kernel and thought my system had been hacked! I am lucky because I am running on a laptop (AMD64-based Presario 3240); I heard the fan and realized the processor was running "pedal to the metal," which I could not explain. 'ps auxw' and 'top' revealed FOUR simultaneous traceroute jobs; after killing them one by one, the processor returned to its coasting speed. Thanks to you, now I know.
Bye, Steffen
participants (2)
-
Constantine 'Gus' Fantanas -
Steffen Moser