Summary: | Long delays (blocks) with KDE 3.4.1 under Linux 2.6.12 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Santtu Pajukanta <santtu> |
Component: | [OLD] KDE | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, kde |
Priority: | High | ||
Version: | 2005.0 | ||
Hardware: | All | ||
OS: | Other | ||
URL: | http://marc.theaimsgroup.com/?t=112083152000005&r=1&w=2 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Santtu Pajukanta
2005-06-24 08:40:00 UTC
Sounds like it could be some sort of timeout. Do you have any network shares on your machines? Any special hardware attached? From the description, it sounds like after the initial long period of time, the operation then works without delay, right? Also after a machine is idle for some time? (In reply to comment #1) > Sounds like it could be some sort of timeout. Do you have any network shares on > your machines? Any special hardware attached? I don't have any NFS or SMB etc. shares mounted. The most special hardware I have might be an IEEE-1394 hard disk and an USB Bluetooth dongle (used with kdebluetooth). > From the description, it sounds like after the initial long period of time, the > operation then works without delay, right? Also after a machine is idle for some > time? Dunno, I must try that out once I get to my other machine. Very similar issues with gentoo-sources-2.6.12-r1 and kdebase-3.3.2-r3. Also, the K menu takes a long time to start first up. The K menu works without delay after the first long delay. Closing the session and reopening means the delays happen again. All filesystems on the local disk. The system hasn't been idle long enough to really see whether idle time makes a difference. During the "initializing system services" delay, netstat reports Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 1 127.0.0.1:50359 127.0.0.1:111 SYN_SENT 12523/kdesktop [kde And during the Kmenu delay tcp 0 1 127.0.0.1:48136 127.0.0.1:111 SYN_SENT 12565/kicker [kdein so I stopped init.d/iptables and the delays no longer happened. I added the following simple firewall # Generated by iptables-save v1.2.11 on Wed Jun 29 08:39:32 2005 *filter :INPUT ACCEPT [6:360] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [62:3100] :drop-invalid - [0:0] -A INPUT -m state --state INVALID -j drop-invalid -A drop-invalid -j LOG --log-prefix "invalid packet: " -A drop-invalid -j DROP COMMIT and the delays happened again with the following invalid packets detected Jun 29 08:40:22 warning [4296892.721000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=75 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:40:25 warning [4296895.721000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=76 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:40:31 warning [4296901.721000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=77 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:40:43 warning [4296913.721000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=78 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:41:07 warning [4296937.721000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=79 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:41:55 warning [4296985.722000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=80 DF PROTO=TCP SPT=111 DPT=39392 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:43:34 warning [4297084.999000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=81 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:43:37 warning [4297088.001000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=82 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:43:43 warning [4297094.001000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=83 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:43:55 warning [4297106.001000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=84 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:44:19 warning [4297130.001000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=85 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:45:07 warning [4297178.001000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=86 DF PROTO=TCP SPT=111 DPT=46785 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:51 warning [4297281.412000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=87 DF PROTO=TCP SPT=111 DPT=46786 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:52 warning [4297282.405000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=88 DF PROTO=TCP SPT=80 DPT=39197 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:52 warning [4297283.021000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=89 DF PROTO=TCP SPT=80 DPT=39198 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:54 warning [4297284.412000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=90 DF PROTO=TCP SPT=111 DPT=46786 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:55 warning [4297285.405000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=91 DF PROTO=TCP SPT=80 DPT=39197 WINDOW=0 RES=0x00 ACK RST URGP=0 Jun 29 08:46:55 warning [4297286.022000] invalid packet: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=92 DF PROTO=TCP SPT=80 DPT=39198 WINDOW=0 RES=0x00 ACK RST URGP=0 I don't really know much about tcp but it looks like the kernel thinks that its own ACK RST reply to the SYN is INVALID. (There is no service listening on 111 or 80.) So it looks like this should be reassigned to the kernel herd (unless KDE is doing something wrong in sending the SYN). A work-around might be to include "-i lo -j ACCEPT" in the INPUT chain, but I don't know what is happening with other interfaces. Hmm, I do have "-m STATE --state INVALID -j DROP" before "-i lo -j ACCEPT" in my firewall. I'll swap them as a temporary work-around. (In reply to comment #5) > Hmm, I do have "-m STATE --state INVALID -j DROP" before "-i lo -j ACCEPT" in > my firewall. I'll swap them as a temporary work-around. Having done this, KDE now works also under 2.6.12. Maybe this is a consequence of the network problem that was fixed in 2.6.12.2? (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.12.2) Have you tried with newer kernel versions? Please test with gentoo-sources-2.6.12-r4 (In reply to comment #8) > Please test with gentoo-sources-2.6.12-r4 I had the same problem with other apps (gedit, mpd, evidence and quanta). It happened with gentoo-sources-2.6.12, 2.6.12-r2 and it also happens with 2.6.12-r4. Swapping "-m STATE --state INVALID -j DROP" and "-i lo -j ACCEPT" worked here. Please apply this patch and let me know if it helps. http://linux.bkbits.net:8080/linux-2.6/gnupatch@42c1d78caIDtgsg2ML4ZtOMQrR0mIw Thanks for the suggestion, but I don't have CONFIG_BRIDGE_NETFILTER (nor CONFIG_BRIDGE) defined (and the problem still exists with gentoo-sources-2.6.12-r4), so I don't think the patch in comment #10 will help. I tried echo 255 >| /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid but I didn't find anything extra in the logs. I applied the patch from <a href="#c10">comment #10</a> to gentoo-sources-2.6.12-r4, and the problem still exist. Same as <a href="#c11">comment #11</a>, I don't have CONFIG_BRIDGE defined. I don't use KDE, but I have gedit with the same behavior (I will leave evidence aside, as it's still CVS). I did a strace on gedit, you can find it <a href="http://rue.gerin.free.fr/screenshots/strace-gedit">here</a> It takes around 6 minutes for gedit to start, and it stays blocked ad line #1501: bind(17, {sa_family=AF_INET, sin_port=htons(790), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied) connect(17, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) I'm trying to reproduce this without much luck. Can anyone confirm that I'm using the right sequence of commands? : # iptables -P INPUT ACCEPT # iptables -P OUTPUT ACCEPT # iptables -P FORWARD ACCEPT # iptables -A INPUT -m state --state INVALID -j DROP # iptables -A INPUT -i lo -j ACCEPT And I should then start seeing these hangs, right? This is probably because I'm not getting any AF_INET activity according to strace when opening gedit. Does anyone know why its trying to use sockets in this scenario? Comment #12 suggests that its trying to listen on port 790 (can't do that because you aren't root), and then tries to connect to 127.0.0.1:111. Comment #4 confirms activity on port 111. /etc/services says port 111 is sunrpc. Anyone know anything about this? Do you have CONFIG_SUNRPC enabled in your kernels? Can you use netstat to see which process is listening on port 111? The firewall in comment #13 looks like it should reproduce the problem provided the chains are flushed before you started. 111 is where portmap would be if running but its not. You can reproduce the problem by ensuring that there is no service on port 80, and use a web browser to fetch http://localhost/. It should respond immediately with "could not connect" or similar, but in fact it waits for the connection to time out. In reply to Comment #14: I do have CONFIG_SUNRPC in my kernel config, it's induced by CONFIG_NFSD. I can try to drop CONFIG_NFSD if you think it's relevant. I did "netstat -c" and then gedit, and this line appeared: tcp 0 1 ezach.right-here:46037 ezach.right-here:sunrpc SYN_SENT (ezach is my hostname) I'm not really at ease with this kind of stuff, so if you need more precise results, please let me know what I should do. In reply to Comment #15: I comfirm that connecting to http://localhost takes a long time before time out, which was not the case with 2.6.11 (In reply to comment #15) > You can reproduce the problem by ensuring that there is no service on port 80, > and use a web browser to fetch http://localhost/. > > It should respond immediately with "could not connect" or similar, > but in fact it waits for the connection to time out. Thanks, I can reproduce it like that. Investigating. Fixed in gentoo-sources-2.6.12-r5 :) Thanks for reporting and investigating. |