login
Search
This needs some tweaking, because sometimes "shutdown" really means "I want this laptop to shutdown *now* so I can put it in the padded/insulated carrycase for <insert favorite mode of transport> without the laptop overheating." or even "I want this laptop to shutdown *now* so all encrypted filesystems are unmounted and inaccessable, and all memory contents safely decayed, before I go through $COUNTRY customs." To avoid this sort of problem, IMHO we need a way for a human to tell the software that "now is an ok time to do system maintainance stuff". Perhaps a new option to /sbin/shutdown? -- -- "Jonathan Thornburg [remove -animal to reply]" <jthorn@astro.indiana-zebra.edu> Dept of Astronomy, Indiana University, Bloomington, Indiana, USA "If the triangles made a god, it would have three sides." -- Voltaire
System maintenance, IMO, should be invisible to the user unless it requires input. Shutdown is a poor time to run maintenance because it's (probably) run more often when something needs to be done to the machine or the user has to go somewhere in a hurry. I like the ideas of running it say half an hour after startup, and also on a more regular basis *if* it's not been run early during the morning and the hardware is fast enough. That covers the cases of quick information retrieval, urgent hardware swapouts and doesn't annoy users who leave the computer on when the job is normally scheduled to run. PK
Perhaps this is an application for /usr/bin/batch?
@reboot batch -f /etc/fortnightly now + 1 hour
Could it be beneficial to break up /etc/weekly into separate tasks,
where the parent script can tell when each task last completed,
and only re-run a task if it's been 6+ days since that task last
ran through to the end?
I've used $RANDOM in similar cases to what Lars Nooden discusses,
and also like his suggestion to check 'apm' and not launch housekeeping
tasks when solely on battery power.
Kevin
I fear that's not an option. The apm(8) utility uses the apm(4) device which is limited to i386, AMD64, Zaurus and MacPPC. I wouldn't like cluttering the system maintenance scripts with architecture-dependent stuff, unless there are *very* strong reasons to do so. I'm neither excited about any of the solutions proposed in this thread - perhaps except that nick@'s disknice looks attractive, but i have no idea whether and how that could be done - nor am i happy with the current situation, so i consider tedu@'s question unanswered. I'm not even sure there is a good solution at all: Jan Stary and Jonathan Thornburg have presented strong arguments indicating that "run it manually at the time you want it" might be the best answer.
So maybe what we really need is just a message at boot? Its been 824 days since? /etc/weekly was last run On Jan 28, 2010 6:09 PM, "Ingo Schwarze" <schwarze@usta.de> wrote: I fear that's not an option. The apm(8) utility uses the apm(4) device which is limited to i386, AMD64, Zaurus and MacPPC. I wouldn't like cluttering the system maintenance scripts with architecture-dependent stuff, unless there are *very* strong reasons to do so. I'm neither excited about any of the solutions proposed in this thread - perhaps except that nick@'s disknice looks attractive, but i have no idea whether and how that could be done - nor am i happy with the current situation, so i consider tedu@'s question unanswered. I'm not even sure there is a good solution at all: Jan Stary and Jonathan Thornburg have presented strong arguments indicating that "run it manually at the time you want it" might be the best answer.
On a laptop or on a desktop workstation, i would hardly see this, because these usually boot straight into X. Do you read rc(8) output on such machines? By the way, what you suggest is already logged - as opposed to rc(8) output, which is not logged: schwarze@rhea $ ll /var/log/*.out -rw------- 1 root wheel 0 Jan 31 01:30 /var/log/daily.out -rw------- 1 root wheel 0 Jun 3 2009 /var/log/monthly.out -rw------- 1 root wheel 0 Jan 31 01:30 /var/log/security.out -rw------- 1 root wheel 0 Jan 31 23:49 /var/log/weekly.out See the details? On that machine, i disabled monthly(8); daily(8) and security(8) ran automatically last night; and i just ran weekly(8) manually. On the other hand, on a server, i do read rc(8) output. But that's exactly where the proposed message would be useless. So i fear this suggestion won't help either.
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 -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
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. -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
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. -0- -- The District of Columbia has a law forbidding you to exert pressure on a balloon and thereby cause a whistling sound on the streets.
On Mon, 1 Feb 2010 13:57:09 +0000 Owain Ainsworth
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 ...For the record, i'm not against something that runs the ${INTERVAL}y
scripts in a more intelligent fashion, as long as it is simple and
non-intrusive.
I was just registering a strong dislike of making things like locate(1)
nag about old databases.
-0- - who often leaves his main laptop on overnight.
--
In the land of the dark, the Ship of the Sun
is driven by the Grateful Dead.
-- Egyptian Book of the Dead
And for my mind it is. Just don't add automatics where it's needless. Stas
What about a new script that runs daily/weekly/monthly as needed to make it a bit simpler. The user would then not have to keep track of which script to run. This script could be called manually or the user could ad it in cron or shutdown script as it suits the user/machine. ..just my $.02 /jkm
Simplifying a bit: Run weekly(8) and monthly(8) from daily(8) instead of from cron(8), but only when the last run is at least a week or a month ago, respectively. This is similar in spirit to the way security(8) is run. Main advantage: When your notebook is in use every N-th night, the weekly(8) mean period decreases from 7*N days to 7+(N-1)/2 days. Bonus: Get rid of duplicate functions in weekly(8) and monthly(8). Side effect: daily(8), weekly(8) and monthly(8) run one after the other, not in intervals of two hours. In some setups, this might be a bonus, in some others, an inconvenience. Thoughts?
but what if your machine never runs daily(8) because it's not on at the right time? isn't that the original issue? -- jakemsr@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Ok. Architecture dependent tools should probably not be in the maintenance scripts. I proposed it under the mistaken premise that apm, A stronger note for non-server systems in the post-install checklist, afterboot(8), would be one option. There are some code examples there so a one-liner with 'find' and 'at' could be suggested for use in rc.local or wherever else appropriate for desktop or laptop users. I use that method, but that may be a vote against the method. ;) If the weekly script is launched using 'at', then it will run at the first opportunity. KK's suggestion of making the weekly script modular so that specific routines can be rerun individually is useful in a lot of situations. /Lars
I looked at afterboot(8), but can't think of anything to put there. It would be bad advice to disable the daily/weekly/monthly jobs on all non-server systems. I mean, when the machine is switched off, they do no harm. When the machine is occasionally running during the night, they will at least run from time to time, which usually won't do any harm either and might even be useful. The afterboot(8) manual already encourages people to review and customize the root crontab - so if somebody has good reasons to not run daily(8) at 1:30 AM, the advice to change it is already there. Advice to run /bin/sh /etc/daily manually really doesn't fit into the afterboot(8) manual. You would do that from time to time, not after the first boot. afterboot(8) already suggests to review daily(8). And daily(8), in the very first sentence of the DESCRIPTION, tells you it's run by cron(8). So it's already obvious you need to check the crontab(5) for the scheduled time and run it in some other way if you want it but the machine is switched off at that time. If we had a good way to run daily(8) automatically on machines that are switched off when unused, we probably would not only document it, but we could enable it per default. But since nobody came up with a convincing solution so far, and i can't think of any, either, i cannot even document it. Some people might wish to do it at boot or during teatime, but that doesn't fit everyone and hardly Huh? Really? I don't see any use for it and dislike the additional complexity. By default, weekly(8) does two things: * makewhatis(8) If you want only that, well, call makewhatis(8) and be done with it. * locate.updatedb(8) Typically, this takes much longer than makewhatis(8), so even if you just want to update the locate database, skipping the makewhatis(8) call is not that important. Simply run weekly(8) as it is. You proposed using the modularity to postpone expensive maintenance when the system is under load. That ...
You must have missed my earlier message in this thread http://marc.info/?l=openbsd-misc&m=126436422607058 I argue that the daily/weekly scripts can be harmful on laptops. My laptop never runs during the middle of the night, except when I'm doing important mission-critical work. I have had two incidents where the daily/weekly scripts have interfered with that work (by removing files from /tmp and by causing a buffer underflow while CD-burning). In my case, it is best to disable the cronjobs for the daily/weekly scripts and to run them manually instead.
Hi Matthew, No doubt. I do regard that as a valid point. In fact, that message is what i had in mind when i wrote "The afterboot(8) manual already encourages people to review and customize the root crontab - so if somebody has good reasons to not My assumption was that PCs running during the night are more often used for playing, or surfing, or chatting, or were simply forgotten to be switched off. The discussion which is more common - nightly slacking or urgent nightly work - seems somewhat moot not that we have started it. ;-) Sure, so by all means, do it. Yours, Ingo
