<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
I have run into two annoying bugs on SL6.<br>
<br>
BUG #1<br>
<br>
The first problem is with gnome terminal, which refuses to start
after a few weeks of normal gnome usage.<br>
<br>
The error it gives is "Failed to create pipe for communicating with
child process (Too many open files)":<br>
<br>
<a class="moz-txt-link-freetext" href="http://trshare.triumf.ca/~sclaret/sl6_bugs/too_many_open_files.png">http://trshare.triumf.ca/~sclaret/sl6_bugs/too_many_open_files.png</a><br>
<br>
For a frequent shell user, this is highly annoying.<br>
<br>
-----<br>
<br>
BUG #1 DIAGNOSIS<br>
<br>
I think it's this bug:<br>
<br>
<b><a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=667539">https://bugzilla.redhat.com/show_bug.cgi?id=667539</a></b><br>
<a class="moz-txt-link-freetext" href="https://bugzilla.gnome.org/show_bug.cgi?id=632257">https://bugzilla.gnome.org/show_bug.cgi?id=632257</a><br>
<br>
Since my per-process file descriptor limit is the default 1024:<br>
<br>
sclaret@neut19 /etc/security> ulimit -a | grep files<br>
open files (-n) 1024<br>
<br>
and gnome-terminal seems to be pushing that limit:<br>
<br>
sclaret@neut19 /etc/security> ps -AF | grep gnome-term<br>
sclaret 6151 1 0 124155 29860 0 Jun27 ? 00:04:40
gnome-terminal<br>
<br>
sclaret@neut19 /etc/security> ls /proc/6151/fd | wc -l<br>
1024<br>
<br>
sclaret@neut19 /proc/6151/fd> ls -alh | tail -n 4<br>
lrwx------ 1 sclaret users 64 Jul 13 14:14 996 -> /dev/pts/501<br>
lrwx------ 1 sclaret users 64 Jul 13 14:14 997 -> /dev/ptmx<br>
lrwx------ 1 sclaret users 64 Jul 13 14:14 998 -> /dev/pts/485<br>
lrwx------ 1 sclaret users 64 Jul 13 14:14 999 -> /dev/ptmx<br>
<br>
The overall number of open file descriptors on the system doesn't
seem too crazy:<br>
<br>
sclaret@neut19 /etc/security> lsof | wc -l<br>
8553<br>
<br>
-----<br>
<br>
BUG #1 WORKAROUNDS<br>
<br>
Restarting gnome fixes it (just restarting gnome-terminal may too),
but is disruptive.<br>
<br>
Using a different terminal lets you continue working (i.e. alt-f2
xterm).<br>
<br>
Hopefully, increasing the file descriptor limits and restarting
gnome will keep it at bay for longer:<br>
<br>
[root@neut19 security]# emacs -nw /etc/security/limits.conf<br>
sclaret soft nofile 8192<br>
sclaret hard nofile 10240<br>
<br>
Activating unlimited scrollback may also avoid it (though I haven't
tried, because it would require a restart). And unlimited
scrollback could be problematic in its own right, if it starts
eating a lot of memory.<br>
<br>
Presumably, Centos / Scientific Linux will patch gnome-terminal
somewhere down the line. <br>
<br>
-----<br>
<br>
BUG #2<br>
<br>
Thunderbird occasionally becomes unusable, with javascript errors
and GUI problems:<br>
<br>
<a class="moz-txt-link-freetext" href="http://trshare.triumf.ca/~sclaret/sl6_bugs/js_bug.png">http://trshare.triumf.ca/~sclaret/sl6_bugs/js_bug.png</a><br>
<a class="moz-txt-link-freetext" href="http://trshare.triumf.ca/~sclaret/sl6_bugs/gui_problem.png">http://trshare.triumf.ca/~sclaret/sl6_bugs/gui_problem.png</a><br>
<br>
It can happen 5 or 6 times in a day, and seems to have started 2-3
weeks ago.<br>
<br>
It seems to be triggered by gui interaction (i.e. composing an
email).<br>
<br>
The only way to continue using thunderbird is to kill and restart
it.<br>
<br>
Mozilla and redhat seem to have embarked on a sort of long term
support arrangement, so I'm hopeful they will patch thunderbird and
this'll disappear.<br>
<br>
One way to work around might be to delete the metadata in
~/.thunderbird or ~/.mozilla (haven't tried yet - be careful not to
delete your browser preferences).<br>
<br>
-----<br>
<br>
Cheers,<br>
<br>
Simon<br>
</body>
</html>