task manager like tool for linux?
in [Setup]
|
Prev: Try this again: is Linux Linpus any good?
Next: which is better: mount an ext3 disk from windows, or write an NTFSdisk from Linux?
From: David Brown on 2 Jun 2010 03:59 On 01/06/2010 22:33, Nasser M. Abbasi wrote: > coming from windows to linux, I find that I miss the task-manager tool > on windows. > > I am running fedora 13, and I like the linux tools below the desktop > (shell commands) and all the other command line development tools, and > that is the main reason I am moving to linux. > > But I am finding that sometimes some desktop applications hangs and > something goes wrong. On windows, when this happens, I start the > task-manager, find the process or the application, and kill it. > > For example, now I have firefox froze on me on fedora, I was in the > middle of saving a page as web page. > > I know I can use ps -a, find the process id, and use kill, but sometimes > that does not kill the process, and now when I did ps -a, it did not > even list firefox > > ps -a | grep -i firefox > > even thought I started it, and I can see it there froze on the desktop. > > The point is, it would be much easier for new users if a task-manager > like GUI tool is there (ofcourse, one must be root to run it?). > > I also have another GUI application which is hanged. Also xsane hangs up > when coming up searching for devices, and kill does not seem to work on it. > > Is there such a thing on linux that new linux users could use? > > thanks > --Nasser Sometimes "xkill" is very convenient - it saves you figuring out which process a frozen window belongs to.
From: Aragorn on 2 Jun 2010 04:00 On Wednesday 02 June 2010 00:22 in comp.os.linux.setup, somebody identifying as Nasser M. Abbasi wrote... > On 06/01/2010 02:56 PM, Keith Keller wrote: > >> On 2010-06-01, The Natural Philosopher<tnp(a)invalid.invalid> wrote: >> >>> Keith Keller wrote: >>>> >>>> Again, a task manager won't help you with this. Have you tried >>>> kill -9? This should be considered a last resort, but if you've >>>> already tried kill (which by defaults sends SIGTERM, or kill -15) >>>> then you basically have no other real options anyway. >>> >>> Reload the GUI. >>> Or reboot the machine. >> >> Real men don't reboot! ;-) >> >> Killing X may end up simply orphaning the rogue process, making it a >> child of init. It's worth a shot, of course, but the inevitable >> question will be "what happens when the process doesn't die after I >> kill X?" At that point you consider kill -9, or if frustrated enough >> a reboot. > > humm... I had fedora 13 desktop now freeze on me. > > The whole gnome desktop froze. ctrl-alt-del does nothing like on > windows? The [Control+Alt+Delete] combination, when used inside a graphical user interface like Gnome, KDE or the likes, is trapped by that graphical user interface. In KDE (3.x.x) for instance, it is set up by default - but this is changeable - to cleanly log out of the KDE session. I suspect that it would do the same in Gnome, but I'm not sure. What you /could/ try - and *should* try first - if the entire desktop is frozen is [Control+Alt+Backspace]. This kills the X server, and if you're running in runlevel 5, it'll respawn it again, presenting you with a fresh graphical login screen. If you're running in runlevel 3, it'll just drop you back to the commandline from whence you started X. Lastly, if all else fails, try the "magic System Request" keys. This works as follows...: Press and *hold* the [Alt] and [Prtsc|SysRq] keys on your keyboard, and then while you keep holding those down, enter the following sequence of characters, leaving about 1 or 2 seconds between each press: "R S E I U B". This sends direct commands to the kernel and will safely reboot your system, provided that the kernel is still alive. The explanation of the commands (and why you need to press them in this sequence) is the following...: R : puts the keyboard in "unRaw" mode S : emergency Sync of the virtual filesystem with the physical filesystems on disk E : tErminate all running processes except for "init" I : kIll all running processes U : emergency Unmount and read-only remount of all mounted filesystems B : reBoot - same thing as pressing the reset button A funny but useful mnemonic is "Raising Skinny Elephants Is Utterly Boring". Just memorize that and use the first character of each word. ;-) > What else am i suppose to do? Had to reboot the machine. See above. ;-) > I think the problem is coming from a USB external disk I am using. It > seems to be causing hangups. This is may be why xsane hangs sometimes, > and when I did fdisk -l before the reboot, the command hanged up at > this device also. > > I also had an rsync running copying stuff to this USB disk, and that > seems to be frozen as well. All possible, but not necessarily caused by that USB disk. Overheating may also be a cause, or bad RAM, or a power supply that doesn't provide for the correct voltages consistently. > So, I had to reboot the PC. On windows, I would have done > ctrl-alt-del and found the process and killed it. Like I wrote in my other reply to you, in KDE you can use [Ctrl+Escape] - but you can assign another key combination to it - to bring up the KDE System Guard. This is a process which runs in the background, but it also has a more fully-featured variant which you can start as an independent application and which allows you to see graphs and all that. The one in the background only shows you a table of processes. > Humm.... may be I should take this disk back and get a new one (it is > a new disk, just bought it few days ago). I am not sure it is the USB > disk, but I think it is. > > What does one do on linux when the desktop freezes like this? is > there a way to avoid re powering the machine? As explained above. :-) -- *Aragorn* (registered GNU/Linux user #223157)
From: Aragorn on 2 Jun 2010 04:08 On Wednesday 02 June 2010 00:56 in comp.os.linux.setup, somebody identifying as Keith Keller wrote... > On 2010-06-01, Nasser M. Abbasi <nma(a)12000.org> wrote: >> >> The whole gnome desktop froze. ctrl-alt-del does nothing like on >> windows? What else am i suppose to do? Had to reboot the machine. > > [...] > In your hung X session, if you don't care about it you could try > ctrl-alt-backspace first, which is the keystroke to kill X. If that > doesn't work you can still try switching consoles. If *that* doesn't > work, you can try to ssh in from another computer, if you have one > available and your frozen machine is on the network. If none of those > work, I don't know any other option than to kill the power. Always try the magic System Requests first - see my second reply to Nasser. ;-) If it doesn't work, then you can always still press the reset button as a last resort, but if it does work, then at least your system will be cleanly shut down. ;-) Most distributions have the "magic SysRq" keys enabled in the kernel, but it never hurts to check "/etc/sysctl.conf" on your local system, because it may still be disabled there. Look for a line that says... kernel.sysrq = 0 "0" disables the System Requests, "1" enables them. If the line is commented out, then they will be enabled if the kernel was configured for it - if it wasn't, then enabling them in "/etc/sysctl.conf" won't make a difference. ;-) -- *Aragorn* (registered GNU/Linux user #223157)
From: Aragorn on 2 Jun 2010 04:17 On Wednesday 02 June 2010 02:07 in comp.os.linux.setup, somebody identifying as The Natural Philosopher wrote... > David W. Hodgins wrote: > >> On Tue, 01 Jun 2010 18:22:45 -0400, Nasser M. Abbasi <nma(a)12000.org> >> wrote: >> >>> What does one do on linux when the desktop freezes like this? is >>> there a way to avoid re powering the machine? >> >> On my Mandriva 2010.0 system, the following works ... >> Hold down alt+ctrl and press the backspace key twice to kill >> the X server, and any gui applications. >> >> [...] > > I have found witching to the console, logging in as root, and > rebooting from the command line also useful. If you *can* switch to another virtual console - which may not always work, e.g. if X itself is frozen - and you *must* reboot, then you don't even need to log in as root, because the [Ctrl+Alt+Del] sequence will normally perform a clean reboot from there, unless it was reassigned to another function or disabled via "/etc/inittab". ;-) The only reason why [Ctrl+Alt+Del] does not work as "expected" from within a graphical desktop environment is that when X is running, it traps all keyboard input except for the System Requests, which are sent directly to the kernel. In KDE, it is by default configured to perform a clean logout of KDE itself (as opposed to killing the X server). -- *Aragorn* (registered GNU/Linux user #223157)
From: Doug Freyburger on 2 Jun 2010 10:49
Nasser M. Abbasi wrote: > > humm... I had fedora 13 desktop now freeze on me. You're jumping to conclusions that are not supported by the evidence you have posted, and then you are trying to kill random processes and concluding it didn't work because of what you see on the screen not on the command line so again not supported by the evidence you posted. > The whole gnome desktop froze. ctrl-alt-del does nothing like on > windows? What else am i suppose to do? Had to reboot the machine. When you killed your browser and it no longer appeared in the ps -f list then it was gone. Period. If it still displayed on the screen the problem was with the background display updating not with the browser. Use the evidence at hand and try to fix the actual problem not just randomly killing the process without trying to fix the problem. > I think the problem is coming from a USB external disk I am using. It > seems to be causing hangups. This is may be why xsane hangs sometimes, > and when I did fdisk -l before the reboot, the command hanged up at this > device also. Yep. USB drives often cause hangs. Actually they cause tremendous slow downs which is not quite the same thing as a hang. It can be hard to tell a system functioning at 1/1000th its normal speed. > I also had an rsync running copying stuff to this USB disk, and that > seems to be frozen as well. My poorly supported theory on why systems slow down so much when doing traffic to USB drives is somewhere in the filesystem-or-disk driver code there is a base assumption that all drives function on the same order of magnitude speed therefore all disk requests can pass through the same queue. Fill that queue even once with a USB request and because the USB drive has no buffering and it responds so slowly the total system performance drops to 1/1000th of before the event. I'm not sure how to confirm the theory but I've it happen - Walk away and wait over night for the transfers to the USB drive to complete and the system proceeds along as if nothing ever happened. > So, I had to reboot the PC. Which by definition never ever solves the problem. It only helps if what caused the problem does not happen again. Since you have a repeatable problem here you already know that rebooting is gauranteed to not help. > On windows, I would have done ctrl-alt-del > and found the process and killed it. If the process you have selected is the one causing the problem. Your posts on the matter show you have not been following a chain of evidence to give any confidence that you are in fact selecting the problem process. You thought that your browser was still running when ps -f says it was not just because the pixels of the background had not been updated after all. > Humm.... may be I should take this disk back and get a new one (it is a > new disk, just bought it few days ago). I am not sure it is the USB > disk, but I think it is. I am far from convinced replacing the USB drive will help. I've seen too many large transfers to too many USB drives trigger this sort of slow down. > What does one do on linux when the desktop freezes like this? is there > a way to avoid re powering the machine? Check the Red Hat Fedora site for patches to the USB driver that causes it to buffer its traffic differently if my theory is correct. |