When I have a xterm with ufed running in it and I close the xterm, there is a process called ufed-curses shown up in top, which uses nearly 100% of the cpu. * app-portage/ufed Available versions: 0.40-r1 ~0.40-r3 Installed: 0.40-r1 hal9000 ~ # emerge --info Portage 2.1.1_pre1-r1 (default-linux/x86/no-nptl, gcc-3.4.6, glibc-2.3.6-r3, 2.6.14-gentoo-r7 i686) ================================================================= System uname: 2.6.14-gentoo-r7 i686 AMD Athlon(tm) XP 3000+ Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -pipe -O2 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=athlon-xp -pipe -O2 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer sandbox sfperms" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp/portage" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 16bit 3dnow 3dnowext 7zip X aac accessibility acpi aim aimextras alsa amarok apache apache2 apm asf avi bashlogger berkdb bitmap-fonts c++ ccache cdrom chroot cli crypt css cups dedicated dhcp dio disk-cache divx4linux double-precision dri dvd dvdr eds emboss encode fame fastcgi firefox foomaticdb fortran gatos gcj gdbm gif gimp glibc glibc-compat20 glibc-omitfp glx gnome gphoto2 gpm gstreamer gtk gtk2 icq imlib ipv6 irc isdnlog javascript jpeg kde kdeenablefinal libg++ libwww mad math md5sum mem-cache memcache memlimit mikmod mmx mmxext motif mp3 mpeg mpeg4 mplayer msn musicbrainz mysql ncurses net nls no-old-linux nowin nsplugin nvidia ogg opengl pcre pdflib perl png pppd python qt quicktime readline reflection reiserfs sdl sensord session spell spl ssl tcpd truetype truetype-fonts type1-fonts unicode userlocales utf8 vorbis win32codecs wxwindows xml xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_en linguas_de userland_GNU video_cards_nv video_cards_nvidia video_cards_vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I'm pretty sure it's ncurses issue, same problem like Bug 124404.
Disclaimer: I have very limited understanding of xterm. But, I think it's a design limitation in xterm: when closing an xterm window, xterm is responsible for killing off the running process. xterm is run as a user process, ufed is run as root. Obviously, xterm is then unable to kill ufed. Some other programs happen to not have issues with this since they exit as soon as the input stream is closed. It would be a good idea for ufed to do the same, and I will try to add this, but if it's possible to get xterm fixed too somehow, that would be great.
if dialog (or whatever ufed is using) fails to respect the return values of ncurses, i dont see how that's ncurses' fault
ufed is using ncurses directly, and ncurses (by design, as required by X/Open Curses) doesn't give different return codes for "no more input" and "no input at the moment, please wait". So yes, not an ncurses bug, but ufed does handle the ncurses return codes as can be expected. :)
Just a wild guess, since I'm absolutely not experienced with ncurses. In GTK you have to call gtk_widget_destroy() in case you get a 'delete_event' Maybe here the ncurses widget is not being destroyed when a 'delete_event' is being triggered.
(In reply to comment #5) > Just a wild guess, since I'm absolutely not experienced with ncurses. > In GTK you have to call gtk_widget_destroy() in case you get a 'delete_event' > Maybe here the ncurses widget is not being destroyed when a 'delete_event' is > being triggered. ncurses isn't event-driven. It's a good guess though, and I checked the ncurses sources to see if a signal is raised for such exceptional conditions as this, but a quick search didn't reveal anything. xterm does attempt to send ufed SIGHUP, but as noted earlier, that doesn't end it, probably because ufed is running as root and xterm isn't. It seems ncurses simply doesn't provide any way to check for this, and a quick experiment shows that aside from ufed and mc (thanks jakub), dialog, alsamixer, and mutt also suffer the exact same problem. (Even bash has problems when it's not checking for input.) I think as far as ufed is concerned, unless I stop using curses, this is a CANTFIX, sorry. To exg and seemant: I CC'ed you (as responsible for xterm) to see if you have any insights on this. It's not specific to curses, it's simply a problem exposed more easily by curses apps: closing xterm doesn't necessarily end the processes running in that xterm, since xterm doesn't necessarily have the privileges to end the processes running in that xterm. I don't think there's anything that can be done since xterm is not suid root and not supposed to be suid root, so I think this can be closed, but I would appreciate it if you took a quick look to see if I missed anything.
(In reply to comment #6) > SIGHUP, but as noted earlier, that doesn't end it, probably because ufed is > running as root and xterm isn't. Confirmed! If I run the xterm as root I don't get any problems > (Even bash has problems when it's not checking for input.) I think as far as > ufed is concerned, unless I stop using curses, this is a CANTFIX, sorry. So I don't think this is a CANTFIX, since it looks like the problem have been solved with mc. (In reply to comment #1) > I'm pretty sure it's ncurses issue, same problem like Bug 124404. Thats what I think too.
(In reply to comment #7) > So I don't think this is a CANTFIX, since it looks like the problem have been > solved with mc. Well, recompile w/ USE="-ncurses" != solution, for me at least. :) So no, mc issue hasn't been solved, and there it also happens when mc is run w/ the same user like xterm (or other terminal) - looks like a slightly different problem then. > (In reply to comment #1) > > I'm pretty sure it's ncurses issue, same problem like Bug 124404. > > Thats what I think too. Well yeah, it occurs w/ ncurses-based stuff only.
(In reply to comment #8) > > (In reply to comment #1) > > > I'm pretty sure it's ncurses issue, same problem like Bug 124404. > > > > Thats what I think too. > > Well yeah, it occurs w/ ncurses-based stuff only. No, it doesn't. I forgot that bash is linked with ncurses, but the same script can show the problem in pdksh (which doesn't use ncurses): # wait until the user types "EOF" while read X ; [ "$X" != "EOF" ] ; do : ; done > So no, mc > issue hasn't been solved, and there it also happens when mc is run w/ the same > user like xterm (or other terminal) - looks like a slightly different problem > then. The bug you referenced is specifically about mc running as root, with presumably a non-root xterm ("X--> terminal-->su-->mc"). If you also experience problems while not running mc as root, it might be a good idea to open a separate bug for that.
I also came across this issue and played a bit arround. First I found some applications that produce this behavior: mc,ufed,top. Allways open xterm->su->[app]->close. Now another strange thing is not all Terminals produce this behavior. While on xterm and konsole the processes keep running with 100%cpu, it does not happen on aterm or Eterm. Then I thougt the difference between this terminals is the $TERM variable (xterm and Konsole have $TERM=xterm while Eterm has 'Eterm' and aterm 'rxvt'). But doing an "export TERM=rxvt" in xterm before the su didnt change anything (top,mc.. goes to 100%cpu). I think we don't have to blame mc or ncurses alone because it seems also to depend on the terminal program we use.
It might be possible, to give proper permissions to kill the process with sudo in case the 'exit' button is being clicked, and only if the application has been started in the same terminal. Would that be a suitable solution?
> It might be possible, to give proper permissions to kill the process with sudo > in case the 'exit' button is being clicked, and only if the application has > been started in the same terminal. > Would that be a suitable solution? There is no magic about sudo other than that it is setuid root, which is not considered appropriate for xterm. (The ebuild specifically makes sure xterm is not setuid root.) exg, seemant: based on the fact that aterm and eterm apparently don't have this problem, just xterm (and konsole, but that's for another bug, I think), I'm assigning this to you.
afaik, none of the non-root processes can send signals to a root process. If that's true, then the differences between the different terminals would be in a different area, e.g., whether the pseudo-terminal was closed when the terminal exits, allowing the application to see an EOF. Just for comparison, I tried mc+xterm(215) on Debian/testing, but don't see the bug as described.
> afaik, none of the non-root processes can send signals to a root process. Correct. However, whatever aterm is doing must convince the kernel to handle it, because a simple test app shows SIGHUP does get sent. > If that's true, then the differences between the different terminals > would be in a different area, e.g., whether the pseudo-terminal was > closed when the terminal exits, allowing the application to see an EOF. EOF is seen with both xterm and aterm. > Just for comparison, I tried mc+xterm(215) on Debian/testing, but don't > see the bug as described. To be sure, xterm is not setuid root and was launched as a user process, and you ran mc as root? If so, it would definitely be a good idea to see what Debian does differently from Gentoo. For reference, the super simple test app: #include <stdio.h> #include <signal.h> volatile sig_atomic_t done = 0; void sighup(int signal) { done = 1; } int main(void) { setvbuf(stdout, NULL, _IOLBF, 0); signal(SIGHUP, sighup); puts("Test app"); while(getchar() != EOF) {} puts("EOF read"); while(!done) {} puts("SIGHUP sent"); } Doing 'sudo ./test > out' in xterm, and closing the xterm, shows "EOF read", and the program keeps running forever after that. Doing 'sudo ./test > out' in aterm, and closing the aterm, shows "SIGHUP sent", and the program exits afterwards.
> > Just for comparison, I tried mc+xterm(215) on Debian/testing, but don't > > see the bug as described. > > To be sure, xterm is not setuid root and was launched as a user process, and > you ran mc as root? And almost forgot, is Debian's mc built with ncurses? (mc with slang exits on EOF.)
I ran mc via a setuid wrapper (not sudo), which should have the same effect. Was in the middle of other fixes, will verify that it does the same with sudo (perhaps tonight - time's short til the weekend). xterm's installed setgid/utmp just like Eterm and aterm. mc's built with slang. As I noted in email to exg, I recall seeing more than one report regarding mc with this issue, and had the impression that the problem went away due to changes in mc.
*** Bug 124404 has been marked as a duplicate of this bug. ***
Marking this upstream. Feel free to reopen once there's a patch available at least.
