“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.”
Not a bad little summary from IBM. I liked the pretty graphics + CLI examples.
This is not a bad story. But it’s also not that interesting, it’s basic stuff, yet it is everywhere. I wonder how can a story like this end up gaining so much attention in most tech sites.
Is ibm paying “news” sites to run this?
Is ibm paying “news” sites to run this?
LOL.
No, its because most of current “system administrators” doesn’t know even this basic stuff. And these IBM articles are quite well done sometimes, worth read even if you already knows about it, so you can “refresh” your memory.
That’s a legitimate question. Still, I’d rather read this than another ubuntu beta announcement.
Surely some readers will learn a thing or two from this. (?)
Of course they are paying us. The money for my Aston Martin has to come from somewhere.
And I get $100 per comment I post. Doesn’t everybody?
you only get $100.
bwahahahahaha.
how about a torrent link, please
nice intro for newbies, but their forgot about fg in the end of the article, to bring back background process to front.
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…
“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. 🙂
Perhaps you should read the article again…
Yes, You are right, I must overlooked it.
Is it safe to say UNIX(R) (*) these days without getting sued? 🙂
(c) Copyright dimosd(tm) 2007. All rights reserved.
(*) All trademarks are the property of their respective owners.
> 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…
“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. 🙂