According to the dictionary, the number 1 definition of ‘fatal’ is…
There are other definitons, but the overriding one is that a fatal event is one where death has occured.
When did this start being used in computing? and by whom?
It amuses me to think when I see a ‘fatal error has occured’ message to think that something has just died! :eek:
It’s basically used in the sence of unrecoverable error, so in that sence the Program execution has “died”
Some errors can be ‘handled’ or worked around. Or the program execution can recover, and continue on in some fashion, if not the desired one.
Not sure exactly when this terminology came into use, but Unix systems use the term “kill” to indicate signaling processes (including but not limited to forcibly shutting down the other process) “zombie” in reference to a specific process state, “daemon” similarly, and “children” and “parent” as descriptions of relations between processes, leading to such lovely questions as kill parent and child
A zombie is a child process whose parent has died. A parent should wait for its child to die (or kill it outright) so it can collect its exit status.
Daemons are useful. They’re processes that do something automatically in response to external conditions (a file being copied to a sacred directory is a common one) and are commonly used to handle system tasks like printing.
Any process can become a parent by spawning children. Then the cautions about zombies apply.
Indeed.
Similarly, ‘illegal’ means that the program has done something to violate the protection régime implemented by the operating system. Illegal errors are commonly fatal.
I suspect this arose by association with the word “terminal” in the sense that the error could not be dealt with and the program would have to be terminated. It’s easy to see how this could turn into a variety of slang terms that have more to do with death and dying than with ending a program.
To me, that’s not an appropriate metaphor. A child process whose parent has died should be an orphan process.
A zombie might be a process that isn’t responding to a kill command (you can kill it but it won’t die. :D)
Actually, a zombie is a process that has died but nobody’s bothered to clean up after it (yet). Still not completely appropriate, though.
I was doing software engineering for about a year, and there was an ongoing debate in our group about error/warning messages, and whether there should be three (warning, error, fatal error) or just two (warning and error). Some in the group couldn’t understand how error and fatal error could be different. It seemed obvious to me, but I wasn’t really much of a software engineer, so I never said anything.
Well, it is dead but still looks like it is living; that seems appropriate to me. Also, a process who has lost its parent is an orphan. When it loses its parent, it becomes the ward of god, er… make that PID 1.
he, he… about ten years ago I witnessed a guy who was a lawyer, an idiot and totally ignorant of computers come face to face with the message “the system has performed an illegal operation…” and the guy went bonkers and wanted to argue with the computer: "What do you mean illegal? " He could not imagine another meaning for the word “illegal”.
I think “kill” has a long history before computing. On boats I have always said and heard “kill the engine”. I am sure that predates computers and probably fountain pens.
Windows actually tracks parent and child processes too, but Windows doesn’t care if a process is orphaned. In fact, I’m not sure that the parent process PID pointer (Peter picked a peck of…) is actually used for anything in Windows except for the task manager. The “End Process Tree” option is supposed to kill a process and all of its descendants.
It kind of gives an interesting look into Windows, though:
“System” begat smss.exe,
smss.exe begat csrss.exe,
csrss.exe begat winlogon.exe,
winlogon.exe begat services.exe and lsass.exe
The children of services.exe:
svchost.exe, whose children were browser.dll, cryptsvc.dll, srvsvc.dll, wkssvc.dll, …
svchost.exe, whose children were w32time.dll, lmhsvc.dll, alrsvc.dll, …
svchost.exe, whose children were …
svchost.exe, whose children were …
…
spoolsv.exe, whose womb was barren,
…
The children of lsass.exe:
lsass.exe begat userinit.exe,
userinit.exe begat explorer.exe
Now userinit.exe was a righteous process who walked with the kernel; then he was no more, because the kernel took him away.
(The shell instance of explorer.exe always shows up as an orphaned process because it is spawned by userinit.exe, which always terminates before the user interface becomes available).
The term was used in error messages in the first version of OS/360, BOS/360 (both the 4K and 8K versions), announced with the IBM System 360 in 1964. (Though I don’t think any were actually shipped until early 1965.)
So it was in use at least 45 years ago.
I think Derleth is confused, as others pointed out: a zombie is a process (or thread) that has stopped responding and has to be “forcefully” stopped. Superfluous Parentheses’ definition is correct as far as it goes, but I’m having trouble imagining one of the modern OSes not cleaning up a process that had exited cleanly and wasn’t blocked on some resource.
I am confused, in a generalized philosophical sense, but I’ve never heard ‘zombie’ used with that meaning before. I’d call such a process ‘catatonic’ or ‘hung’, not a zombie.
Here is a cite supporting my position. This concurs. So does everyone else.
This is the statement folks are taking issue with, and your cites indicate that it is incorrect. An orphan (not a zombie) is a process whose parent has died. A zombie is a process whose parent (usually) continues to live but hasn’t asked for the exit status of the child. The child process has exited, but it remains in the list of processes.
The following is also not really right:
The apparent non-responsiveness is an aspect of zombie-ness, but it is not the definition. You cannot stop or suspend or kill a zombie because there is nothing actually executing. The “process” is just an entry in a table. Thus, it appears like a non-responsive process.
OK, perhaps I was more confused than I thought.