chin@hscfvax.UUCP (08/12/83)
#N:hscfvax:400002:000:771 hscfvax!chin Aug 12 10:52:00 1983 A most bizarre phenomonon was witnessed on our vax 11/750 running 4.1bsd last night. It involved a runaway process in the background. The process was shown to be "(grep)" as revealed by a "ps alx" (by the way, what do the parentheses mean?) with no arguments. What it was doing was taking up all the disk space on one of our user pseudo-disk. It was active in that any space we freed up would *slowly* be eaten up. The clincher is that when the process was killed with a "kill -9 [pid]", instead of space usage stabilizing (at 99%) it dropped dramatically back to 70% where it should be. Does anybody know what could be happening? It was a process probably called by csh, but that's all we know about it. Thanks, Ken Chin ...!linus!genrad!wjh12!n44a!hscfvax!kchin
dmmartindale@watcgl.UUCP (Dave Martindale) (08/14/83)
A runaway process that slowly eats space and suddenly releases it when it is killed does this because its output file has already been rm'ed. When a file is unlinked in UNIX, the directory entry vanishes immediately but the file still exists in its entirety, and can even continue to grow, as long as some process still has it open. Once the last process which has it open exits or otherwise closes it, the inode is deallocated and all its disk blocks freed, thus instantly releasing all that space.
lee@unm-ivax.UUCP (08/15/83)
One of the questions was answered. The other's answer is: A process name parenthesized by 'ps' means that is the name that will be entered into system accounting. Thus, an exec like: execl (name, arg0, arg1, arg2, ..., 0); would have the command 'name' stripped of path entered into system accounting, irregardless of arg0 which a program could check and interpret to be the name it was invoked as. --Lee (Ward) ...!ucbvax!unmvax!lee