As we all know, disk crises are a frequent problem on Grex,
though hopefully the incidence of such problems will decrease
with the recent move to hard quotas.
I have a modest suggestion that I believe will help save some
disk space at virtually no cost in time or effort and wonder
whether other people agree that it's a good idea.
Those of you who don't use the pine mail reader may not know
this about it, but by default pine creates files in the user's
home directory containing debug output. The default debug level
is 4, meaning 4 such files are created -- when you run pine the
current .pine-debug1 becomes .pine-debug2, .pine-debug2 becomes
.pine-debug 3, etc, and the contents of .pine-debug4 are freed
up. The number of such files can be specified using the -d flag:
> -d debug-level Output diagnostic info at debug-level
> (0-9) to the current .pine-debug[1-4]
> file. A value of 0 turns debugging
> off and suppresses the .pine-debug
> file.
Now, each one of these .pine-debug? files is approximately 10kbytes
in size, each pine user typically has 4 of them (the default),
and virtually nobody ever looks at the contents.
Curious how many of these files existed, I cd'ed a couple of
levels above my home directory (to /a, I think) and did a
"find . -name .pine-debug\? -ls", which revealed 6870 such files
on what used to be the /a partition (now /grex/a) using 79,658,631
bytes of disk space, and that was in only the directories which
allowed me sufficient permissions to check to see whether the
files existed.. Across the entire system I think the total would
be pretty substantial.
What I'm recommending is:
a) change the common rc files sourced by the default .cshrc,
.bashrc, etc. scripts so that unless the user specifically
overrides the new default "pine" gets aliased to "pine -d 0"
b) after making the change above so that new files aren't
generated for people who don't want them, remove existing
files older than a certain age, e.g. one week (it seems unlikely
that someone is really going to want debug output from a program
they ran more than a week ago.) In other words, have a sysadmin
go through for each filesystem which contains user home directories
and do a "find /a -name .pine-debug\? -print -rm"
Does anyone see a problem with this? It seems like it has the potential
to free up a substantial amount of disk space, remove a bunch of useless
clutter, and have no adverse affect whatsoever.
21 responses total.
...and no adverse effect either! ;)
i have a quota :(
>disk crises are a frequent problem on Grex no, really ? I was wondering last week if some big tornado did take away the server facility hosting grex.org, throwing the disks away to Niagara Falls. And don't talk about backup, what's that: b-a-c-k-u-p ??
re #3: last weeks' outage no doubt deserves an item all its own,
if it doesn't have one already. let's reserve this one for my
suggestion of removing extraneous .pine-debug files.
Oh, and I messed up the find command in point (b) above, in two
separate ways, in fact. First, I forgot to date-limit it to older
files, and second, I invented an imaginary "-rm" flag, which isn't
supported by any find implementations I know of..
It should have been:
find /grex/a -name .pine-debug\? -mtime +7 -print -exec rm \{\} \;
or possibly a find/xargs combination.
The real thing to do is email Marc Crispin and tell him you think not having a pine.conf setting to turn off creation of debug files is a dumb idea. He'll give some ridiculously pompous response, which is usually entertaining.
That's a strategy I hadn't considered. It sounds like he's already prepared to deflect my request, but prima-donna "between me and the user, the user is always wrong" free-software project leads are easy to defeat.. I would start with a demand that he start calling his project "Pignue" to recognize the pioneering work of the GNU project and then, after his head explodes, I can campaign in favor of a more tractable project leader for Pine.
I suppose he's not that bad, he's just one of those people who can't imagine themselves being wrong about his software design descisions. I'm not sure what he thinks of Stallman, if anything. They're roughly contemporaneous.
I can't see why he wouldn't at least compress them -- I bet they compress fabulously, probably 85-95%.. Anyway, can anyone think of a downside to clearing away at least 80MB of 99.999% useless pine debugging files? From an idealistic stance, perhaps it'd be wrong to delete them without their owners' permission. In which case, possibly they could just be compressed instead, as a less intrusive but still effective solution.
I cannot imagine the owners wanting them. Can they be deleted automatically when you log out?
Put them on an automatic reap, like "core" and "cf.buffer" files.
Experimental results show that they only compress about 71%, not that it matters.. Deleting them is probably the right thing to do.
Oh yeah, one other thing.. I couldn't figure out why I was still getting these files created after I'd changed my own aliases to alias pine to "pine -d 0" It turns out that when I launch pine from Picospan my tcsh aliases are ignored (which is not surprising..) I suppose I could put a command to rm them in my .logout file, but can a more advanced Picospan user tell me how to override the "pine" alias in Picospan? Presumably there's something simple I can just put in my .cfonce, no?
/unluckyt
just turn them off, anyone having troubles can easily re-enable them if their pine is crashing and staff need more info to trace it down. this is what i ended up doing back in the nether.net days to save disk & inodes
Latest count on /grex/a: % (find . -name .pine-debug\? -ls | ~mcnally/pdb_total.pl) > & /dev/null 7078 files 82123891 bytes Latest count on /c: % (find . -name .pine-debug\? -ls | ~mcnally/pdb_total.pl) > & /dev/null 1813 files 21000101 bytes
what ! it's jared !
yup. better number: grex:~> locate pine-debug | wc -l 30740
Oh, something else to do would be tunefs -m 1 <disk> 1% is a lot these days, the orig 10% reservation was based on much older criteria.. it'd help the currently full /var/mail
I usually stick with 5%, but you're right that 10% is probably excessive unless the filesystem is known to have special needs..
The (probably dated) tunefs man page says 5% default, and not to be surprised by filesystem performance going to the dogs if you set it way down. I've heard of rumors *under FreeBSD* of filesystem corruption with below-default settings...though that may have been while there were working the bugs out of soft updates or such.
TROGG IS DAVID BLAINE
You have several choices: