On Mon, 1 Feb 2010 13:57:09 +0000 Owain Ainsworth
<zer...@googlemail.com> wrote:
> On Mon, Feb 01, 2010 at 07:42:57AM +0200, Jussi Peltola wrote:
> > On Mon, Feb 01, 2010 at 04:54:49AM +0000, Jacob Meuser wrote:
> > > On Mon, Feb 01, 2010 at 05:57:11AM +0200, Jussi Peltola wrote:
> > > > On Mon, Feb 01, 2010 at 02:35:54AM +0000, Jacob Meuser wrote:
> > > > > yeah, but wasn't the original issue that started this thread
> > > > > was that the locate database was "too old"? maybe if locate,
> > > > > apropos, etc would print "databse last updated 3 weeks 2 days
> > > > > ago"?
> > > >
> > > > This should be done in any case. IMHO it's a bug if they don't
> > > > complain loudly, or even refuse to run with a stale database.
> > > > Stale caches are evil, even if the man page warns about them.
> > >
> > > yeah, but if your computer hasn't been on for 3 weeks and then
> > > locate won't work because the database is 3 weeks old, that would
> > > suck.
> >
> > Of course it would need a switch to force it to run. But I guess a
> > warning is better since locate might be used in scripts and it's not
> > good to add extra knobs to existing programs where they don't gain
> > much.
>
> Please, no.
>
> If nothing has changed on my machine in 3 weeks (say one of the
> laptops I use infrequently) I would utterly hate having locate et al.
> bitch at me continually.
>
> If *you* really want something like that, this is what shell
> functions are for, just check the database mtime, and print to stderr
> if it's too old, then run locate. Please don't try and force that on
> everyone else.
>
I agree with Owain. I mean no offense to Tedu, but there is no viable
need for serious modifications or significant changes in default
behavior... And worse, trying to "fix" this supposed problem will
most likely cause other problems.
If you need a solution for your not-always-on systems like laptops,
then just toss the following script into your /etc/rc.local or if you
prefer for it to run at login, then toss it into your ~/.profile
-----start--script---------------------------------------------------
#!/bin/ksh
sysmaint='';
if [ `find /var/log -name security -mtime +1` ]; then
sysmaint="/etc/secure";
fi
if [ `find /var/log -name daily.out -mtime +1` ]; then
sysmaint="$sysmaint /etc/daily";
fi
if [ `find /var/log -name weekly.out -mtime +7` ]; then
sysmaint="$sysmaint /etc/weekly";
fi
if [ `find /var/log -name monthly.out -mtime +31` ]; then
sysmaint="$sysmaint /etc/montly";
fi
if [ X"$sysmaint" != X"" ] ; then
echo;
echo "The Following System Maintenance Scripts Are Out Of Date";
for scrp in $sysmaint; do printf "\t%s\n" $scrp; done;
echo;
read ans?"Should we run the system maintenance scripts now? (Y/N): ";
if [ X"$ans" == X"Y" ] || [ X"$ans" == X"y" ] ; then
for scrp in $sysmaint; do
printf "\t%s\n" $scrp;
# if put in your .profile, use `sudo $scrp`
# sudo $scrp
$scrp
done;
fi
else
echo;
echo "Your System Maintenance Scripts Are Up To Date";
echo;
fi
-----end--script---------------------------------------------------
Needless to say, I very *intentionally* gave the user the choice whether
or not to run the scripts, but the important thing is this kind of
automation is dead-simple to do.
We're fighting a battle of opinions; We can all see the system
maintenance scripts need to run (even on the not-always-on systems),
there's never a "good" time to run the scripts, and there is an expected
(historic/de facto) default way it has always been done in the past
which works just fine for most systems.
For those with the desire to delay some arbitrary amount of time (as
mentioned, 30 minutes after boot up), you could easily modify the above
to use the at(1) command. Heck, the simple "Y/N" in the above could be
changed to something like "Y/N/# (of minutes)" for setting at(1).
It is best not to try to force this sort of thing on everyone,
particularly when it's so easy to do on your own. If it's something
that you think should be easily added through configuration, then the
best answer is to add a var to /etc/rc.conf and\or /etc/rc.conf.local
to trigger running it at boot with the default being not to run.
I think putting the above in /etc/rc.shutdown is overkill (and a
very bad idea), but some people have suggested running the scripts at
shutdown (while their laptop battery is potentially dying). If some
want to perforate their feet, we don't need to help them.
Please Note: Tedu previously mentioned some work he was doing to
optionally reduce the load of the various scripts (reduced coverage?),
and these options could be used along with the above approach to speed
things up.
If you think this is a fair approach and without forced or unnecessary
changes to the existing default behavior, then let me know, and I'll
start making the changes/diffs.
-jcr
