Get your free disk space! Eliminating .pine-debug[1234] files.

Apr 19 17:08 UTC 2005

  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.

response 2 of 21:

Apr 19 18:05 UTC 2005

i have a quota :(

response 4 of 21:

Apr 19 18:42 UTC 2005

 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.

response 6 of 21:

Apr 19 20:54 UTC 2005

  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.

response 8 of 21:

Apr 19 21:30 UTC 2005

  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.

response 10 of 21:

Apr 20 04:14 UTC 2005

Put them on an automatic reap, like "core" and "cf.buffer" files.

response 12 of 21:

Apr 20 18:01 UTC 2005

  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?

response 14 of 21:

Apr 22 19:06 UTC 2005

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

response 16 of 21:

Apr 23 00:59 UTC 2005

what !

it's jared !

response 18 of 21:

Apr 23 18:55 UTC 2005

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

response 20 of 21:

Apr 25 01:57 UTC 2005

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.