Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: Bug with cp -r and ACLs (long)
Message-ID: <1991Feb8.140323.1509@alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
References: <9102061706.aa14313@concour.cs.concordia.ca> <1991Feb7.183550.8329@alchemy.chem.utoronto.ca> <4fae2d9d.1bc5b@pisa.ifs.umich.edu>
Date: Fri, 8 Feb 1991 14:03:23 GMT

In article <4fae2d9d.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes:
>In article <1991Feb7.183550.8329@alchemy.chem.utoronto.ca>, system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:
>
>  Unfortunately I have to agree with this statement - there is however the
>  fact that HP/Apollo advertises that any/all environments can be used, where
>  there are cases where this is simply not the case. A prime example is
>  '/com/sigp', which is needed to kill processes that won't die with 'kill
>  -9' (which is the untrappable UNIX kill signal).
>
>Not a good example.  You should never blast a process unless you plan to
>shut down your node.  And if you're going to shut down, then you don't need
>to blast.

I agree that after blasting, you should shut down, but we get stuck processes
(looping in the cpu) when I am not able to reboot immediately (like
nights/weekends), but the user process must be killed so they and other users
can do useful work. There is no way that a cpu-bound process should be
able to ignore a 'kill -9' (a process hung on some non-returning system call
might be able to, but that is not my experience with other UNIXs).

>The 'cp -r' problem is just a bug.  And there is a bsd workaround (piped
>tar, which is the traditional way to copy a tree in Unix anyway).  Do you
>have other examples?

I will be posting my complete list of Apollo bugs after I figure out
which of them were fixed by SR10.3 (not many, since even some of the
ones I was told were fixed, are not, like vi in a pad).
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775
