"On UNIX systems, each system and end-user task is contained within a process. The system creates new processes all the time and processes die when a task finishes or something unexpected happens. Here, learn how to control processes and use a number of commands to peer into your system."
Post a Comment
Member since:
2007-02-26
Fans: 0
Member since:
2005-11-06
Fans: 1
Member since:2006-04-21
Fans: 14
Member since:2005-12-18
Fans: 0
Member since:2007-02-26
Fans: 0
Member since:2005-06-29
Fans: 20
Member since:2005-07-06
Fans: 6
Member since:2006-02-15
Fans: 9
Member since:
2006-11-18
Fans: 0
Member since:2006-01-04
Fans: 0
I saw a 'fg %8' somewhere in the article.
What I miss in unix shell jobs control is the ability to interupt a process with ctrl+z, and then completely detach the process from it's parent process, the shell, à la nohup..
Because screen isn't installed everywhere...
Anyway, fg/bg are still very convenient, and Unix just rocks...
Member since:2006-10-08
Fans: 6
"What I miss in unix shell jobs control is the ability to interupt a process with ctrl+z, and then completely detach the process from it's parent process, the shell, à la nohup.."
Maybe the detach auxilliary program will be your friend. I have detach-1.3 installed (/usr/local/bin/detach) which allows to start a process detached from a controlling terminal / login shell.
% detach [ command args ]
"Anyway, fg/bg are still very convenient, and Unix just rocks..."
Yes, I know it does, and it will continue doing it. :-)
Member since:
2007-03-14
Fans: 2
Member since:2006-11-18
Fans: 0
Member since:
2006-02-10
Fans: 1
Member since:
2005-12-31
Fans: 2
> One special signal, SIGKILL, can't be blocked or caught, and it kills a
> process immediately.
... and of course, pigs can fly. As with all "unblockable" actions, there is some way to block it. For example, in Linux, it's called 'D' process state (visible in ps, expected to be short for "dammit!") and means that even a kill -9 as root won't terminate the process.
I wonder if there's again some way to override *that* so you don't have to reboot...
Member since:2006-10-08
Fans: 6
"For example, in Linux, it's called 'D' process state (visible in ps, expected to be short for "dammit!") and means that even a kill -9 as root won't terminate the process."
Once I had Opera running, I encountered this problem, as well as with a XMMS from a cancelled X session (Ctrl-Alt-Bksp) or something similar unusual, which could not be killed via "kill -9 (PID)" or "killall -KILL (name)".
FreeBSD's ps knows the dammit D processes, described as follows: "D: Marks a process in disk (or other short term, uninterruptible) wait." Wow...
"I wonder if there's again some way to override *that* so you don't have to reboot..."
I'd really like to know it, maybe "dd if=/dev/zero of=/dev/mem" will work. :-)