Version: 2.2 (distributed with KDE 4.1.96) (using Devel) Compiler: gcc version 4.2.4 (Gentoo 4.2.4 p1.0) OS: Linux Installed from: Compiled sources Konsole forgets to close file descriptors before exec-ing the shell. (I am using KDE 4.1.96) xxx@desktop ~ $ ls -l /proc/$$/fd total 0 lrwx------ 1 xxx users 64 2009-01-15 02:26 0 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:26 1 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:26 10 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 11 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 12 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 13 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 14 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 2 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:26 255 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:26 4 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:26 9 -> socket:[36173] xxx@desktop ~ $ 0,1,2 are stdin/out/err, and 255 is opened by bash. The other 7 are inherited from Konsole - they should be closed. Konsole in KDE 3.5 once had the same problem (# 147508), and was later fixed.
If I run bash in gnome-terminal (still in KDE), only 4 descriptors (0,1,2,255) are there. Apparently gnome-terminal closed them between fork and exec. xxx@desktop ~ $ ls -l /proc/$$/fd total 0 lrwx------ 1 xxx users 64 2009-01-15 02:48 0 -> /dev/pts/7 lrwx------ 1 xxx users 64 2009-01-15 02:48 1 -> /dev/pts/7 lrwx------ 1 xxx users 64 2009-01-15 02:48 2 -> /dev/pts/7 lrwx------ 1 xxx users 64 2009-01-15 02:48 255 -> /dev/pts/7 xxx@desktop ~ $ ls -l /proc/`pidof gnome-terminal`/fd total 0 lrwx------ 1 xxx users 64 2009-01-15 02:48 0 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:48 1 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:48 10 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:48 11 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:48 12 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:48 13 -> socket:[36083] lrwx------ 1 xxx users 64 2009-01-15 02:48 14 -> socket:[36083] lr-x------ 1 xxx users 64 2009-01-15 02:48 15 -> pipe:[85997] l-wx------ 1 xxx users 64 2009-01-15 02:48 16 -> pipe:[85997] lrwx------ 1 xxx users 64 2009-01-15 02:48 17 -> socket:[85998] lrwx------ 1 xxx users 64 2009-01-15 02:48 18 -> socket:[86000] lrwx------ 1 xxx users 64 2009-01-15 02:48 19 -> socket:[86002] lrwx------ 1 xxx users 64 2009-01-15 02:48 2 -> /dev/pts/6 lrwx------ 1 xxx users 64 2009-01-15 02:48 20 -> socket:[86005] lrwx------ 1 xxx users 64 2009-01-15 02:48 21 -> socket:[86009] lrwx------ 1 xxx users 64 2009-01-15 02:48 22 -> socket:[86006] lrwx------ 1 xxx users 64 2009-01-15 02:48 23 -> /dev/ptmx lr-x------ 1 xxx users 64 2009-01-15 02:48 24 -> pipe:[86055] lrwx------ 1 xxx users 64 2009-01-15 02:48 25 -> socket:[86015] l-wx------ 1 xxx users 64 2009-01-15 02:48 26 -> pipe:[86055] lr-x------ 1 xxx users 64 2009-01-15 02:48 27 -> pipe:[86056] l-wx------ 1 xxx users 64 2009-01-15 02:48 28 -> pipe:[86056] lrwx------ 1 xxx users 64 2009-01-15 02:48 3 -> socket:[85993] lrwx------ 1 xxx users 64 2009-01-15 02:48 4 -> socket:[36083] lr-x------ 1 xxx users 64 2009-01-15 02:48 5 -> pipe:[85995] l-wx------ 1 xxx users 64 2009-01-15 02:48 6 -> pipe:[85995] lr-x------ 1 xxx users 64 2009-01-15 02:48 7 -> pipe:[85996] l-wx------ 1 xxx users 64 2009-01-15 02:48 8 -> pipe:[85996] lrwx------ 1 xxx users 64 2009-01-15 02:48 9 -> socket:[36173]
*** Bug 183917 has been marked as a duplicate of this bug. ***
Got ample evidence over in bug #183917 to confirm this.
This is causing a lot of pain at Fedora. It seemingly went away at one point, on F10, but came back as soon as I switched to -testing. ls -l /proc/$(pidof konsole)/fd | wc -l 34 ls -l /proc/$(pidof konsole)/fd | grep 'pipe' | wc -l 12 ls -l /proc/$(pidof konsole)/fd | grep 'socket' | wc -l 14 This causes weird SELinux errors, such as 'su -c 'service httpd start'' to fail, when you can can run 'service httpd start' if you're already root. Numerous similar bugs related to services. Any worker-bee that needs me to test--I'm good to go. I'd *really* like this fixed.
> I'd *really* like this fixed. I cannot reproduce with KDE 4.3/trunk under Kubuntu, I see only 0,1 and 255 open as expected using ls -l /proc/$$/fd. Please get in touch with other Fedorian KDE users/developers and ask them to investigate.
> It seemingly went away at one point It never did. We got a steady flow of duplicates. It's a long-standing, still unfixed problem.
I'm going to test if libutempter support plays a role here or not. Does Kubuntu use libutempter (in kdelibs)?
libutempter confirmed not relevant. Interestingly, launching konsole from yakuake (started as part of session management) -> no socket file descriptors launching konsole from kickoff or krunner or yakuake (after login, not part of session management) -> open socket file descriptors leaves me with a big wtf?
> leaves me with a big wtf? Something that may be relevant - when you start Konsole from a terminal it always starts a new process. When you start Konsole without a terminal connection (ie. from a GUI) it tries to re-use an existing Konsole process if there is one. When the first Konsole instance is started, a new process is always created. I tried again launching Konsole from the GUI and from a terminal and couldn't reproduce. > It never did. We got a steady flow of duplicates. > It's a long-standing, still unfixed problem. As I'm sure you can appreciate, the majority of KDE developers and users are running something based on Debian, most likely Ubuntu, where SELinux is not on by default - so don't wait for someone else to investigate. Assume that you're going to have to fix it yourself.
Re: comment #9, in case there is confusion, selinux is only highlighting the issue here, and is not the cause of it (at least there is no evidence of that yet)... Based on comment #8, I'm fairly certain that this issue is at a lower level than konsole. But it's unclear to me where best to reassign this (kdelibs somewhere?).
FYI, I've traced most of the open socket fd's all the way back to kdeinit4, re-assigning -> kdelibs
> Re: comment #9, in case there is confusion, selinux is only highlighting > the issue here, and is not the cause of it Yes, this is my understanding as well but as I said, I couldn't reproduce the problem where a bunch of other file descriptors were left open.
Robert, what does your system look like? I'm on Fedora 10 -testing. kdelibs-4.2.2-5.fc10.i386 An example of my typical situation would be Konsole with four tabs, all but one connected to remote systems. In that case, I find: $ ls -l /proc/$(pidof konsole)/fd | wc -l 51 If I then close down everything remote, leaving me with the original instance, I find: $ ls -l /proc/$(pidof konsole)/fd | wc -l 36 $ ls -l /proc/$(pidof konsole)/fd | grep 'pipe' | wc -l 9 $ ls -l /proc/$(pidof konsole)/fd | grep 'socket' | wc -l 21 IIRC, this is very different from what I saw on konsole startup, back when I thought the problem was fixed. The test of this might look like: Where 'characterize' means: ls -l /proc/$(pidof konsole)/fd | wc -l ls -l /proc/$(pidof konsole)/fd | grep 'pipe' | wc -l ls -l /proc/$(pidof konsole)/fd | grep 'socket' | wc -l The procedure: clean boot (no instance of konsole left running) record kdelibs, uname -r, or whatever else might be relevant. (thoughts appreciated) launch konsole characterize (1) ssh to remote system characterize (2) close remote connection characterize (3) diff characterizations 1-3, as a matrix (table). That doesn't allow for corner cases, but it should be a good starting point, and I'll summarize, which should help the coders. Thoughts? It really shouldn't be too hard to come up with a test plan for this, and put it to bed.
> Robert, what does your system look like? Stock x86 Ubuntu Intrepid with Qt and KDE taken from KDE's subversion repository. > An example of my typical situation would be Konsole with four tabs, > all but one connected to remote systems. In that case, I find: I understood that the problem isn't file descriptors open by Konsole - its file descriptors opened by Konsole still being open in the shell process after it starts. So its /proc/$$/fd that's interesting, not /proc/<pid of konsole/fd
it's not that simple ... in krunner: dash -c 'lsof $$' sh 11511 ossi 9u unix 0xe2a4f780 0t0 51387 /tmp/ksocket-ossi/kdeinit4__0 sh 11511 ossi 12u unix 0xbaace000 0t0 51686 socket sh 11511 ossi 13u unix 0xecbf0a80 0t0 115483 socket sh 11511 ossi 17u unix 0xcc56bc00 0t0 52731 socket sh 11511 ossi 19u unix 0xe0560a80 0t0 115623 socket sh 11511 ossi 21u unix 0xe2ac9600 0t0 115650 /tmp/ksocket-ossi/krunnerJ11480.slave-socket in krunner: bash -c 'lsof $$;echo' # echo, so lsof is not exec'd straight bash 11604 ossi 9u unix 0xe2a4f780 0t0 51387 /tmp/ksocket-ossi/kdeinit4__0 bash 11604 ossi 12u unix 0xbaace000 0t0 51686 socket bash 11604 ossi 13u unix 0xecbf0a80 0t0 115483 socket bash 11604 ossi 17u unix 0xcc56bc00 0t0 52731 socket bash 11604 ossi 19u unix 0xe0560a80 0t0 115623 socket in konsole started from xterm: lsof -p $$ bash 11566 ossi 9u unix 0xe2a76600 0t0 51348 socket bash 11566 ossi 13u REG 3,1 0 821664 /tmp/kde-ossi/konsoleL11564.tmp bash 11566 ossi 14u REG 3,1 0 4668737 /tmp/kde-ossi/konsoleS11564.tmp bash 11566 ossi 15u REG 3,1 0 4668748 /tmp/kde-ossi/konsolen11564.tmp bash 11566 ossi 18u unix 0xbaace480 0t0 116024 /tmp/ksocket-ossi/kdedk24096.slave-socket in konsole started from krunner: lsof -p $$ bash 11448 ossi 9u unix 0xe2a4f780 0t0 51387 /tmp/ksocket-ossi/kdeinit4__0 bash 11448 ossi 10u unix 0xecaa2300 0t0 51279 socket bash 11448 ossi 12u unix 0xecaa2300 0t0 51279 socket bash 11448 ossi 14u unix 0xecaa2300 0t0 51279 socket bash 11448 ossi 16u REG 3,1 0 3748736 /tmp/kde-ossi/konsoleT11446.tmp bash 11448 ossi 17u REG 3,1 0 4668739 /tmp/kde-ossi/konsoleZ11446.tmp bash 11448 ossi 18u unix 0xecaa2300 0t0 51279 socket bash 11448 ossi 19u REG 3,1 0 4668742 /tmp/kde-ossi/konsolew11446.tmp the outputs are filtered, obviously. specifically, fd 255 seems to be used by interactive bash. the rest goes without saying. so from the cross-section of these lists one can conclude that while there certainly is a problem in kdeinit, there is also one in konsole. i think i'll spend some time reading sources now ...
the bug in konsole is actually a bug in QTemporaryFile, which i'm about to fix.
SVN commit 955904 by ossi: make kdeinit really not leak file descriptors to child processes BUG: 180785 M +6 -0 kinit.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=955904
Many thanks!
After applying this patch, it seems to be a mixed blessing. While it does indeed fix the leaking socket fd's, I'm seeing some nasty side-effects: * kio errors from knode: Could not start process Unable to create io-slave: klauncher said: Error loading 'kio_nntp'. and from kmail: could not start process for imap * running many apps, yields: KDEInit could not launch '/usr/bin/<foo>', with <foo> being tested to include: konsole, kontact, knode, kmail
hmm, indeed, launching processes via some particular kdeinit command (probably the one that requests feedback) seems to have that effect. investigating ...
SVN commit 956037 by ossi: fix and simplify the child struct disposal the previous patch exposed this problem ... CCBUG: 180785 M +4 -13 kinit.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=956037
confirmed mm, mm good.
confirmed on mandriva, i add to revert it for now
i will test the new patch now