KP Kirchdörfer wrote: > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: > > Charles Steinkuehler wrote: > > > > Following problem: > > > > Using Dachstein and creating a separate ramdisk /dev/ram1 for > > > > /var/log malfunctions lrp.conf spacecheck. > > > > I think the spacecheck intention is to monitor /var/log, cause > > > > there are the most changes in file size during the routers > > > > lifetime and running out of space in /var/log causes several > > > > errors - sshd won't start, pppoe connections won't be > > > > established after disconnection etc. - all leading to router > > > > which can't be controlled remotely. > > > > > > > > Further investigation showed that multicron-p only looks for / > > > > when checking free space - which is useless, once you have a > > > > separate ramdisk for /var/log. > > > > > > > > Dummy solution, and this is what I did: > > > > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p > > > > to use $lrp_CHK_PART in lrp.conf updatefree() > > > > > > > > Enhanced solution: > > > > lrp_CHK_PART should allow several partitions which will be > > > > checked and free'ed or at least a sending a mail with > > > > mailadmin(). > > > > > > Added to the list of things to fix for Dachstein 1.0.3 > > > > > > 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. > > > > Correct me, if I'm wrong -- it won't be the first time today ;> > > > > /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) > > > > What do you think? > > 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. > > sorry kp
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? -- 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
