[1877] in Release_7.7_team
Re: Unstripped binaries and .deleted
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jul 27 09:39:53 1999
Message-Id: <199907271339.JAA07127@rcn-sucks.fsck.com>
To: Matt Braun <matt@MIT.EDU>
cc: release-team@MIT.EDU, ops@MIT.EDU
In-reply-to: Your message of "Tue, 27 Jul 1999 00:42:41 EDT."
<199907270442.AAA00649@forever.mit.edu>
Date: Tue, 27 Jul 1999 09:39:41 EDT
From: Greg Hudson <ghudson@MIT.EDU>
> 1) There is 28 Meg of .unstripped programs. It might be prudent
> (especially if the amount of unstripped programs for debugging will
> grow) to make a seperate section of the srvd in subvolume for these
> files. This way we don't need to replicate the unstripped versions
> of things all over, but they are available in an 'obvious' place if
> needed.
It's not necessary to move them to a separate location not to copy
them. You can make a .rconf rule to ignore *.unstripped files.
Also, we're not going to get some huge growth in .unstripped programs.
They're only there in the Solaris srvd for programs tracked onto the
local disk, which is a small subset of the programs we install.
> 2) What is the criteria for things in .deleted? I thought it was
> because long running programs (like emacs, zwgc, etc) tended to die
> when the binaries changed out from under them. If that is the case
> why are the lp* commands there? They are not exactly 'persistant'
> commands and in the case of lpq and lprm there is no danger of
> losing data if they crash.
For the athena cell release, I consider it sufficiently likely that an
lpr/lprm/lpq command will dump core that I generally instruct ops to
copy them into .deleted when I change them. It's certainly more
likely for long-running processes, but it could happen to any command.
