Linked by Thom Holwerda on Mon 9th Apr 2007 17:57 UTC, submitted by BlueVoodoo
General Unix "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."
Order by: Score:
Back to basics
by anomie on Mon 9th Apr 2007 18:29 UTC
anomie
Member since:
2007-02-26

Not a bad little summary from IBM. I liked the pretty graphics + CLI examples.

Reply Score: 1

Hmm
by JohnX on Mon 9th Apr 2007 18:36 UTC
JohnX
Member since:
2005-11-06

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?

Reply Score: 3

RE: Hmm
by twenex on Mon 9th Apr 2007 18:40 UTC in reply to "Hmm"
twenex Member since:
2006-04-21

Is ibm paying "news" sites to run this?

LOL.

Reply Score: 2

RE[2]: Hmm
by CapEnt on Mon 9th Apr 2007 19:01 UTC in reply to "Hmm"
CapEnt Member since:
2005-12-18

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.

Reply Score: 4

RE: Hmm
by anomie on Mon 9th Apr 2007 19:02 UTC in reply to "Hmm"
anomie Member since:
2007-02-26

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. (?)

Reply Score: 3

RE: Hmm
by Thom_Holwerda on Mon 9th Apr 2007 20:04 UTC in reply to "Hmm"
Thom_Holwerda Member since:
2005-06-29

Of course they are paying us. The money for my Aston Martin has to come from somewhere.

Reply Score: 1

RE[2]: Hmm
by fretinator on Mon 9th Apr 2007 20:24 UTC in reply to "RE: Hmm"
fretinator Member since:
2005-07-06

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?

Reply Score: 4

RE[3]: Hmm
by Cloudy on Tue 10th Apr 2007 17:45 UTC in reply to "RE[2]: Hmm"
Cloudy Member since:
2006-02-15

you only get $100.

bwahahahahaha.

Reply Score: 2

v Hey
by SmellySnatch on Mon 9th Apr 2007 18:42 UTC
fg
by vermaden on Mon 9th Apr 2007 19:34 UTC
vermaden
Member since:
2006-11-18

nice intro for newbies, but their forgot about fg in the end of the article, to bring back background process to front.

Reply Score: 2

RE: fg
by what on Tue 10th Apr 2007 00:34 UTC in reply to "fg"
what Member since:
2006-01-04

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...

Reply Score: 1

RE[2]: fg
by Doc Pain on Tue 10th Apr 2007 01:21 UTC in reply to "RE: fg"
Doc Pain Member since:
2006-10-08

"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. :-)

Reply Score: 2

RE: fg
by BSDfan on Mon 9th Apr 2007 19:43 UTC
BSDfan
Member since:
2007-03-14

Perhaps you should read the article again...

Reply Score: 3

RE[2]: fg
by vermaden on Mon 9th Apr 2007 21:24 UTC in reply to "RE: fg"
vermaden Member since:
2006-11-18

Yes, You are right, I must overlooked it.

Reply Score: 3

UNIX (R) (*) ?
by dimosd on Mon 9th Apr 2007 19:54 UTC
dimosd
Member since:
2006-02-10

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.

Reply Score: 0

kill?
by Morin on Tue 10th Apr 2007 11:54 UTC
Morin
Member since:
2005-12-31

> 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...

Reply Score: 3

RE: kill?
by Doc Pain on Tue 10th Apr 2007 17:21 UTC in reply to "kill?"
Doc Pain Member since:
2006-10-08

"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. :-)

Reply Score: 2