KP Kirchdörfer wrote:
> 
> Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif:
> > KP Kirchdörfer wrote:
> > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif:
> > > > >
> > > > > I'll probably try to get the script to check *ALL* currently
> > > > > mounted, writable file-systems...maybe with an exclude
> > > > > variable in lrp.conf.  If this doesn't work, I can fallback
> > > > > to the Enhanced solution, above.
> > > >
> > > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES,
> > > > then -- and, only then -- /etc/cron.daily/multicron-d and its
> > > > links can run checkfreespace(), which calls updatefree(), &c.
> > >
> > > There is also mailadmin(), so if /var/something is on the list
> > > and checked, it will send a mail to mailadmin.
> > >
> > > > Suppose, updatefree() returns a value for which ckfree()
> > > > returns 0, then -- and, only then -- cleanlevel() runs and
> > > > prunes applicable files that match the filter:
> > > > $lrp_SC_DEL_L$cklevel
> > > >
> > > > But, *what* files can these be?  In /etc/lrp.conf -- by default
> > > > -- we see exclusively this:
> > > >
> > > >       lrp_SC_DEL_L1="/var/log/*[4-9].gz"
> > > >       lrp_SC_DEL_L2="/var/log/*[1-3].gz"
> > > >       lrp_SC_DEL_L3="/var/log/*.gz"
> > > >       lrp_SC_DEL_L4="/var/log/*.0"
> > > >       lrp_SC_DEL_L5="/var/log/wtmp"
> > > >
> > > > Notice, *ALL* of these files -- by default -- reside in
> > > > /var/log !!!
> > > >
> > > > Since *only* files under /var/log can be pruned -- by default
> > > > -- then, why not modify updatefree() to say this:
> > > >
> > > >       set -- $(df /var/log | sed -n 2p)
> > >
> > > lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well.
> > >
> > > updatefree() isn't the place to determine the dir's, that's what
> > > I think.
> >
> > Agreed, this is not the ultimate solution.  However, it does
> > completely address DCD defaults!
> >
> > Nevertheless, `df /path/to/dir' *always* returns _only_ that
> > information particular to that filesystem on which /path/to/dir
> > resides; therefore, it would be a simple matter to test any variety
> > of applicable dir/filesystem combinations.
> >
> > The truly hard part is, what to do with the information returned?
> > Email somebody is straightforward; but, the complexities in
> > deciding which files to purge becomes exceedingly complex !?!?
> >
> > Besides logfiles, what else on DCD can grow out-of-hand?
> 
> On a common DCD I don't know. On my own /var/logs and /var/cache for
> squid.
> It's easy to decide that a cache can be flushed.

Yes, of course, in and of itself, it is easy to decide whether or not to
purge files in /var/cache.

It is also easy enough to put several df's in a loop in order to analyze
several filesystems.

However, it is not as easy, once a filesystem is found that requires
purging, for the dumb shell script to decide *which* files to purge ;<

For instance, just because your /var/cache maybe full, do you want to
arbitrarily purge /var/log files?

Not for an instant do I suggest that such complexity is insurmountable;
rather, it should be clear that this is far more involved and requires a
new paradigm, other than:

        lrp_SC_DEL_L1="/var/log/*[4-9].gz"
        lrp_SC_DEL_L2="/var/log/*[1-3].gz"
        lrp_SC_DEL_L3="/var/log/*.gz"
        lrp_SC_DEL_L4="/var/log/*.0"
        lrp_SC_DEL_L5="/var/log/wtmp"

Also, do not forget, I do not recommend my solution for its
completeness; rather, I recommend it because it more accurately
addresses the *default* DCD distribution, can be done by changing one
(1) line in the current distribution and does *not* require considerable
development and testing time.

Enough said . . .

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .

_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to