Re: way to help: laptops and weekly
On Mon, 1 Feb 2010 13:57:09 + 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 +, 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 +, 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 == XY ] || [ X$ans == Xy ] ; 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
Re: way to help: laptops and weekly
On Wed, Feb 03, 2010 at 07:00:56AM -0800, J.C. Roberts wrote:
On Mon, 1 Feb 2010 13:57:09 + 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 +, 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 +, 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.
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
Re: way to help: laptops and weekly
Hi, On Tue, Feb 2, 2010 at 1:08 AM, Ingo Schwarze schwa...@usta.de wrote: [...] Some time ago, we discussed a potential maintenance(8) utility and decided to postpone the idea until we find more uses. Right here, maintenance(8) might help: 1. At 1:30 AM daily, run maintenance without any arguments, which will - run daily(8) unless it ran today - run security(8) in any case - run weekly(8)unless it ran this week - run monthly(8) unless it ran this month I very like the idea of your maintenance, just wanted to add a thought: for all the people that don't use their pcs so many hours every day, how about counting the uptime (and saving its value at shutdown) so that daily is run every 24 hours _of_use_, and so on for the others? One doesn't need a locate rebuild every week if he didn't use the system, right? My 2 eurocents. :-) Ciao, D.
Re: way to help: laptops and weekly
Maybe this can be an idea: http://xyne.archlinux.ca/manpages/cronwhip cheers -dav
Re: way to help: laptops and weekly
David Coppa wrote on Tue, Feb 02, 2010 at 04:19:07PM +0100: Maybe this can be an idea: http://xyne.archlinux.ca/manpages/cronwhip Citing from that page: :: DESCRIPTION :: Cronwhip runs cronjobs that would have been run in the time since the :: last system shutdown. Cronwhip can be run at startup on systems that :: are not constantly up to make sure that all cronjobs get run regularly. I think that solves the wrong part of the problem. Running jobs at boot time (or half an hour later) has been proposed before, and the problem with that is: it might overload the system exactly when you want to use it for some real work. The maintenance(8) proposal solves this by only running the cheap parts half an hour after boot, such that maintenance doesn't seriously slow down your work. In that scenario, skipping the cheap part in case it ran the day before is hardly worth the effort.
Re: way to help: laptops and weekly
Ingo Schwarze wrote: David Coppa wrote on Tue, Feb 02, 2010 at 04:19:07PM +0100: Maybe this can be an idea: http://xyne.archlinux.ca/manpages/cronwhip Citing from that page: :: DESCRIPTION :: Cronwhip runs cronjobs that would have been run in the time since the :: last system shutdown. Cronwhip can be run at startup on systems that :: are not constantly up to make sure that all cronjobs get run regularly. I think that solves the wrong part of the problem. at, which is already in base, also runs overdue jobs upon startup. Running jobs at boot time (or half an hour later) has been proposed before, and the problem with that is: it might overload the system exactly when you want to use it for some real work. That's well recognized. Some have first hand experience of the problem, too. The maintenance(8) proposal solves this by only running the cheap parts half an hour after boot, such that maintenance doesn't seriously slow down your work. In that scenario, skipping the cheap part in case it ran the day before is hardly worth the effort. Running at any fixed interval after boot, 30 min above there, risks shifting the problem a bit later. Even with the random interval from an earlier message, there is the risk of the administrative load coming at a bad time or too much at the same time. /Lars
Re: way to help: laptops and weekly
Lars Nooden wrote: Ingo Schwarze wrote: David Coppa wrote on Tue, Feb 02, 2010 at 04:19:07PM +0100: Maybe this can be an idea: http://xyne.archlinux.ca/manpages/cronwhip Citing from that page: :: DESCRIPTION :: Cronwhip runs cronjobs that would have been run in the time since the :: last system shutdown. Cronwhip can be run at startup on systems that :: are not constantly up to make sure that all cronjobs get run regularly. I think that solves the wrong part of the problem. at, which is already in base, also runs overdue jobs upon startup. Running jobs at boot time (or half an hour later) has been proposed before, and the problem with that is: it might overload the system exactly when you want to use it for some real work. That's well recognized. Some have first hand experience of the problem, too. The maintenance(8) proposal solves this by only running the cheap parts half an hour after boot, such that maintenance doesn't seriously slow down your work. In that scenario, skipping the cheap part in case it ran the day before is hardly worth the effort. Running at any fixed interval after boot, 30 min above there, risks shifting the problem a bit later. Even with the random interval from an earlier message, there is the risk of the administrative load coming at a bad time or too much at the same time. /Lars Well, it seems clear that everyone agrees on two things 1. These scripts need to be run. 2. Pretty much anytime they are run, the will cause problems for the users. Therefore , we need a new solution to correct problem #2 I propose a new function be added: $ sleepuser This new command will temporarily sleep all users until scripts complete. This will prevent any apparent loss of productivity for the users -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
Re: way to help: laptops and weekly
On Sun, 24 Jan 2010 14:48:35 -0500 Ted Unangst ted.unan...@gmail.com wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. Script called from cron via @reboot or rc.shutdown . By default commented out. Mentioned in afterboot. Check if daily, weekly or monthly need to be executed. If nessasary the script asks if it should do its stuff, warns it might take some time. Default answer No, so a quick Enter resumes shutdown/reboot. If no button has been pressed after $timeout (knob in script), resume shutdown/reboot. If user wants to do stuff, do what needs to be done and resume shutdown/reboot. Should take care of all the on shutdown/reboot scenarios; like battery low or the mentioned unmount crytpo-fs clean now. Impact can be minimized by lowering $timeout. Default timeout should be long enough to read and understand the message. Problem: Shutdown on systems where powerdown doesn't work and the user would have to wait for the script to finish, to turn his system off. Thoughts? - Robert
Re: way to help: laptops and weekly
yeah, leave your laptop on overnight. I do it... On Tue, Feb 02, 2010 at 09:40:17PM +0100, Robert wrote: On Sun, 24 Jan 2010 14:48:35 -0500 Ted Unangst ted.unan...@gmail.com wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. Script called from cron via @reboot or rc.shutdown . By default commented out. Mentioned in afterboot. Check if daily, weekly or monthly need to be executed. If nessasary the script asks if it should do its stuff, warns it might take some time. Default answer No, so a quick Enter resumes shutdown/reboot. If no button has been pressed after $timeout (knob in script), resume shutdown/reboot. If user wants to do stuff, do what needs to be done and resume shutdown/reboot. Should take care of all the on shutdown/reboot scenarios; like battery low or the mentioned unmount crytpo-fs clean now. Impact can be minimized by lowering $timeout. Default timeout should be long enough to read and understand the message. Problem: Shutdown on systems where powerdown doesn't work and the user would have to wait for the script to finish, to turn his system off. Thoughts? - Robert
Re: way to help: laptops and weekly
On Tue, Feb 2, 2010 at 3:04 PM, Chris Bennett ch...@bennettconstruction.biz wrote: Well, it seems clear that everyone agrees on two things 1. These scripts need to be run. 2. Pretty much anytime they are run, the will cause problems for the users. Therefore , we need a new solution to correct problem #2 Indeed. I'm actually about halfway through solving this problem. There's no requirement that updatedb cripple system performance while it's running. I'm going to totally ignore the problem of omg, you can't run updatedb, I routinely give presentations to the TSA in the security line with no battery left exactly 45 minutes after booting by running it all the time. :)
Re: way to help: laptops and weekly
On Tue, 2 Feb 2010 14:53:23 -0600 Marco Peereboom sl...@peereboom.us wrote: yeah, leave your laptop on overnight. I do it... Duh, so the way it is now works fine for you. I don't have it on that late every night, but have changed the times in crontab... So we are both not really affected, yippy ki yay. On Tue, Feb 02, 2010 at 09:40:17PM +0100, Robert wrote: On Sun, 24 Jan 2010 14:48:35 -0500 Ted Unangst ted.unan...@gmail.com wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. Script called from cron via @reboot or rc.shutdown . By default commented out. Mentioned in afterboot. Check if daily, weekly or monthly need to be executed. If nessasary the script asks if it should do its stuff, warns it might take some time. Default answer No, so a quick Enter resumes shutdown/reboot. If no button has been pressed after $timeout (knob in script), resume shutdown/reboot. If user wants to do stuff, do what needs to be done and resume shutdown/reboot. Should take care of all the on shutdown/reboot scenarios; like battery low or the mentioned unmount crytpo-fs clean now. Impact can be minimized by lowering $timeout. Default timeout should be long enough to read and understand the message. Problem: Shutdown on systems where powerdown doesn't work and the user would have to wait for the script to finish, to turn his system off. Thoughts? - Robert
Re: way to help: laptops and weekly
On 3/02/2010, at 9:40 AM, Robert wrote: On Sun, 24 Jan 2010 14:48:35 -0500 Ted Unangst ted.unan...@gmail.com wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. Script called from cron via @reboot or rc.shutdown . By default commented out. Mentioned in afterboot. Check if daily, weekly or monthly need to be executed. If nessasary the script asks if it should do its stuff, warns it might take some time. Default answer No, so a quick Enter resumes shutdown/reboot. If no button has been pressed after $timeout (knob in script), resume shutdown/reboot. If user wants to do stuff, do what needs to be done and resume shutdown/reboot. Should take care of all the on shutdown/reboot scenarios; like battery low or the mentioned unmount crytpo-fs clean now. Impact can be minimized by lowering $timeout. Default timeout should be long enough to read and understand the message. Problem: Shutdown on systems where powerdown doesn't work and the user would have to wait for the script to finish, to turn his system off. Thoughts? - Robert This senario could easily be implimented by those that need/want it. My view is that anything added to base as the default setup should be: 1) pretty much invisible 2) Just Works 3) doesnt interfere with work in any pracical way I realize this is a very tall ask and will require some effort - hence the problem, but I do believe if it's going to be fixed, it should be fixed properly. That is the OpenBSD philosophy after all. Ingos' suggestions have been pretty close. paulm
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 07:42:57AM +0200, Jussi Peltola wrote: On Mon, Feb 01, 2010 at 04:54:49AM +, 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 +, 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. -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.
Re: way to help: laptops and weekly
Jacob Meuser wrote on Mon, Feb 01, 2010 at 05:55:28AM +: how about if cron keeps track of the time it was last able to successfully run a job. then when cron starts, send an email for all jobs missed since that time? or maybe just send an email to remind that daily/weekly/ monthly was missed? I don't think missing one job, or even missing a few, is a problem. It's good enough to have the maintenance jobs running now and then. But your idea to send reminders might help, let's tweak it a bit. Some time ago, we discussed a potential maintenance(8) utility and decided to postpone the idea until we find more uses. Right here, maintenance(8) might help: 1. At 1:30 AM daily, run maintenance without any arguments, which will - run daily(8) unless it ran today - run security(8) in any case - run weekly(8)unless it ran this week - run monthly(8) unless it ran this month 2. Thirty minutes after reboot, run maintenance quick, which will - run the cheap parts of security(8), maybe everything except the SUID checks - check whether weekly(8) is massively overdue, say last run more than three weeks ago - if it is, produce output asking to run maintenance manually, but do not suggest this more than once every ten days Item 1 takes care of servers such that very little changes for them and they almost never run into 2 (unless you reboot your server on Saturday, January 1, at 1:00 AM). On your notebook, if you are in the habit of running weekly(8) manually once a week, very little changes for you - except that you now type maintenance instead of sh /etc/weekly, which will cover daily(8) and monthly(8), too, and that you get daily security(8) checks. In case you dislike the latter, just remove the respective line from the crontab(5). On the other hand, in case you keep forgetting weekly(8), it will remind you after three weeks, and then every ten days, until you come round to running maintenance. Maybe some people will develop a habit of typing sudo maintenance on their workstation just before leaving for lunch. When passing an argument to maintenance(8), it will run just that single script unconditionally, e.g. maintenance weekly. As discussed previously, this will also support running local maintenance scripts either manually or from cron(8), using the daily(8) shell functions, mailing output when there is any. Some people liked the idea and looked forward to using it. Except honouring a new a MAILTO environment variable (default: root), I don't think maintenance(8) needs any other options: KISS. As a bonus, this will reduce code duplication and shorten the scripts. P.S. I agree with Owain to not teach apropos(1) and locate(1) any nagging.
Re: way to help: laptops and weekly
Ingo Schwarze wrote: Kevin Kadow wrote on Tue, Jan 26, 2010 at 04:40:13PM -0600: and also like his suggestion to check 'apm' and not launch housekeeping tasks when solely on battery power. 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. Ok. Architecture dependent tools should probably not be in the maintenance scripts. I proposed it under the mistaken premise that apm, being in base, was on all architectures not just the ones on my desk. 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. 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. http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot 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. 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
Re: way to help: laptops and weekly
Lars Nooden wrote on Sun, Jan 31, 2010 at 09:04:19PM +0200: Ingo Schwarze wrote: 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. A stronger note for non-server systems in the post-install checklist, afterboot(8), would be one option. 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 needs documenting... 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. Huh? Sorry, no idea what you are talking about. KK's suggestion of making the weekly script modular so that specific routines can be rerun individually is useful in a lot of situations. 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 is error-prone in both directions. On a machine doing 24/7 number-crunching, you probably want the system maintenance to take precendence over the production jobs - delay maintenance when there is load, and it will never get done. On a notebook carried to a conference, there is no load indicator for: I am in the middle of a talk and need CPU and disk IO for a demo starting 30 seconds from now.
Re: way to help: laptops and weekly
Kevin Kadow wrote on Thu, Jan 28, 2010 at 06:28:13PM -0600: So maybe what we really need is just a message at boot? Its been 824 days since? /etc/weekly was last run 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: schwa...@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.
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 12:24:15AM +0100, Ingo Schwarze wrote: 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. You must have missed my earlier message in this thread http://marc.info/?l=openbsd-miscm=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.
Re: way to help: laptops and weekly
Joakim Aronius wrote on Fri, Jan 29, 2010 at 09:32:05AM +0100: * Ingo Schwarze (schwa...@usta.de) wrote: 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. 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. 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?
Re: way to help: laptops and weekly
Hi Matthew, Matthew Szudzik wrote on Sun, Jan 31, 2010 at 11:46:38PM +: On Mon, Feb 01, 2010 at 12:24:15AM +0100, Ingo Schwarze wrote: 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. You must have missed my earlier message in this thread http://marc.info/?l=openbsd-miscm=126436422607058 I argue that the daily/weekly scripts can be harmful on laptops. 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 run daily(8) at 1:30 AM, the advice to change it is already there. My laptop never runs during the middle of the night, except when I'm doing important mission-critical work. 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. ;-) [...] In my case, it is best to disable the cronjobs for the daily/weekly scripts and to run them manually instead. Sure, so by all means, do it. Yours, Ingo
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 12:53:24AM +0100, Ingo Schwarze wrote: Joakim Aronius wrote on Fri, Jan 29, 2010 at 09:32:05AM +0100: * Ingo Schwarze (schwa...@usta.de) wrote: 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. 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. 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? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 12:36:45AM +0100, Ingo Schwarze wrote: Kevin Kadow wrote on Thu, Jan 28, 2010 at 06:28:13PM -0600: So maybe what we really need is just a message at boot? Its been 824 days since? /etc/weekly was last run 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: schwa...@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? 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? 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. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 05:57:11AM +0200, Jussi Peltola wrote: On Mon, Feb 01, 2010 at 02:35:54AM +, 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. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 04:54:49AM +, 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 +, 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.
Re: way to help: laptops and weekly
On Mon, Jan 25, 2010 at 10:30:32AM +0100, Joakim Aronius wrote: * Steve Shockley (steve.shock...@shockley.net) wrote: On 1/24/2010 2:48 PM, Ted Unangst wrote: Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. Perhaps run a script via cron occasionally, maybe every six hours where six hours corresponds to 3:30. If /var/log/weekly.out is more than, or exactly, a week old, run weekly. if /var/log/weekly.out is less than a week old, only run /var/log/weekly if it's 3:30am on Saturday. +1. Cron jobs could be run more frequently IMHO, i.e. every 2-3 hrs, as cron is cheap and to make this work on infrequently used machines. /jkm how about if cron keeps track of the time it was last able to successfully run a job. then when cron starts, send an email for all jobs missed since that time? or maybe just send an email to remind that daily/weekly/ monthly was missed? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: way to help: laptops and weekly
On Mon, Feb 01, 2010 at 07:42:57AM +0200, Jussi Peltola wrote: On Mon, Feb 01, 2010 at 04:54:49AM +, 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 +, 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. God, that would be annoying. You're essentially asking for a damned talking paperclip: OMG a potential error I haven't the ability to diagnose may or may not have occurred! I am refusing to do the thing you just specifically asked me to do! Would you like some help drafting a suicide note?
Re: way to help: laptops and weekly
* Ingo Schwarze (schwa...@usta.de) wrote: 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. 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
Re: way to help: laptops and weekly
Jonathan Thornburg wrote: ... Some of the /etc/weekly stuff (eg rebuilding locatedb) involves walking all (non-NFS) mounted filesystems, so it really eats disk seek bandwidth, i.e., it makes the machine painfully slow for most other use while it's running. So, only a human can decide when a good quiet time is to run the disk-cruncher. No automatic scheme can avoid being at a bad time occasionally for some users. There are a lot of things I'd love to have a disknice command for. When you have a process that chews disk but not processor, and you want it to be the last priority when multiple tasks want the disk at the same time, disknice /usr/local/bin/thrash... This would be one of them. Just one of them. however, maybe locate.updatedb could be adjusted to put an optional delay between disk queries... not sure if that would have the intended effect, however. Would probably have to be optional...not sure I'd want to slow down the rebuild process on some of my machines. On the other hand...if they took several days, not sure that would be bad for something that only runs once a week anyway. just what this thread needed. more ill-considered babble without code. Nick.
Re: way to help: laptops and weekly
Ingo Schwarze wrote: Kevin Kadow wrote on Tue, Jan 26, 2010 at 04:40:13PM -0600: and also like his suggestion to check 'apm' and not launch housekeeping tasks when solely on battery power. 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. And for my mind it is. Just don't add automatics where it's needless. Stas
Re: way to help: laptops and weekly
Bofh (Peter Kay) syllopsium () syllopsium ! com suggested 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, You mean right in the middle of an hour-long presentation whose movies don't really play fast enough as it is? Ick. A few days ago I had to give a presentation using a laptop running Windows 95 (my OpenBSD laptop can't seem to do external video output properly, and I've been too busy to track down the problem or file a proper bug report). Every 10-15 minutes during the talk, a window would pop up saying that the system was about to update virus definitions, and giving me 15 seconds or so to click the go away, don't bother me now button. This sort of experience is *not* one that I'd like to repeat under OpenBSD... Some of the /etc/weekly stuff (eg rebuilding locatedb) involves walking all (non-NFS) mounted filesystems, so it really eats disk seek bandwidth, i.e., it makes the machine painfully slow for most other use while it's running. So, only a human can decide when a good quiet time is to run the disk-cruncher. No automatic scheme can avoid being at a bad time occasionally for some users. So, what's needed is a cron with flexible-enough specification semantics (a.k.a. crontab on steroids) so a human can tell cron what the ok-to-run times are. Alas, I am *not* vounteering to write such a program at this time (way too much life happening already), so in the OpenBSD spirit, I hereby forfeit any rights-to-complain-loudly that I might otherwise have had. ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA If the triangles made a god, it would have three sides. -- Voltaire
Re: way to help: laptops and weekly
Ted Unangst wrote: Since we have to roll our own because #1, may as well fix #2. I think a better solution is something that runs weekly from shutdown. I hit the power button, I walk away, and the next time I use it everything is up to date. It never interrupts my work or slows down startup. 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] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA If the triangles made a god, it would have three sides. -- Voltaire
Re: way to help: laptops and weekly
On 26/01/2010 20:03, Jonathan Thornburg wrote: 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 forinsert 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? 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
Re: way to help: laptops and weekly
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
Re: way to help: laptops and weekly
* Steve Shockley (steve.shock...@shockley.net) wrote: On 1/24/2010 2:48 PM, Ted Unangst wrote: Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. Perhaps run a script via cron occasionally, maybe every six hours where six hours corresponds to 3:30. If /var/log/weekly.out is more than, or exactly, a week old, run weekly. if /var/log/weekly.out is less than a week old, only run /var/log/weekly if it's 3:30am on Saturday. +1. Cron jobs could be run more frequently IMHO, i.e. every 2-3 hrs, as cron is cheap and to make this work on infrequently used machines. /jkm
Re: way to help: laptops and weekly
On Jan 24 13:32:43, joshua stein wrote: Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. So do you mean laptops or desktops? There's a difference; namely, laptops run on batteries, and laptops move around. On my desktop, which is usually down at the daily(8) time, I just run 'sh /etc/daily ; shutdown -h -p now' at the end of the day. On a Sunday, I also put /etc/weekly in there. On my laptop, I do the same, _except_ sometimes shuting down a laptop can mean I have 3 minutes of battery remaining, in which case I obviously do not run daily. Also, am I in my home network where there is nfs:/backup to mount? Run the backups then (via daily.local. Otherwise, don't. The other possibilities I thought of (rc.shutdown, @reboot, other cron job) collide with one of the above. daily(8) puts quite a load on (some of) my systems, and ultimately, I want to decide myself, at the given moment, whether to run it or not. Do I need to shutdown quickly? Do I need to boot up quickly to a not-much-loaded system? Do I walk away for a cup of coffee-that-lasts-exactly-`time sh/etc/daily` anyway? (That would be an example of daily(8) being run at a time completely unrelated to booting, halting, or any other time. How do I say that in cron?) So I do it manualy, because having 'sh /etc/daily' somewhere at the back of my head and typing the 13 chars is less of a burden than introducing things into shutdown/boot/cron in a way I know of.
Re: way to help: laptops and weekly
I used to run into problems on old equipment (old in 1997 already) running the daily and weekly scripts early in the morning around the time I was arriving at work. find and conditional execution are one method available of checking the age of the database. #!/bin/ksh /usr/bin/find /var/db/ \ -name locate.database \ ! -ctime 7 \ \ echo nice /usr/libexec/locate.updatedb \ | /usr/bin/at now +1$(($RANDOM % 10)) minutes I'm guessing that desktops stay on for a while. One possible option is that the installation script asks IF /etc/rc.local should also run the daily or weekly scripts if overdue then, if yes, asks how long after startup the refreshing should begin. Netbooks and notebooks are subject to too many strange situations to be able to generalize a script that won't offend large numbers of users. apm is in base and could keep the refresher script from running if there is no battery #!/bin/ksh test 1 -eq `/usr/sbin/apm -a` \ /usr/bin/find /var/db/ \ -name locate.database \ ! -ctime 7 \ \ echo nice /usr/libexec/locate.updatedb \ | /usr/bin/at now +1$(($RANDOM % 10)) minutes /Lars
Re: way to help: laptops and weekly
On Sun, 24 Jan 2010, Ted Unangst wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. sysutils/anacron -- Antoine
Re: way to help: laptops and weekly
On Sun, Jan 24, 2010 at 02:48:35PM -0500, Ted Unangst wrote: Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. I run the daily and weekly scripts by hand on my laptop, and I think that that's the way it should be. If your laptop is on at 3:30am, then you're probably doing something important and don't want to be bothered by the daily or weekly security scripts. For example, if you've placed files in /tmp then the daily script might erase them (and you'll be left wondering where did my files go?). I've also had an incident where the security script ran while I was burning a CD and it caused a buffer underflow. For that reason, I've disabled the cronjobs. I run /etc/weekly every time I install new software (to update the whatis database). I run /etc/daily once a week when I backup my hard drive.
Re: way to help: laptops and weekly
On Sun, Jan 24, 2010 at 3:00 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Sun, 24 Jan 2010, Ted Unangst wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. sysutils/anacron Right, but I think this is something base should handle more gracefully. The locate database is part of the OS, therefore the OS should take the necessary steps to maintain it. Drawbacks of anacron: 1. GPL. Can't import in base. 2. Doesn't run things at a set time. You probably don't want weekly running when you're actually using the system. Since we have to roll our own because #1, may as well fix #2. I think a better solution is something that runs weekly from shutdown. I hit the power button, I walk away, and the next time I use it everything is up to date. It never interrupts my work or slows down startup.
Re: way to help: laptops and weekly
Cron runs the weekly update script every Saturday at 3:30am. If you
use a laptop or other desktop, your computer probably isn't on then.
So the locate and whatis databases never get updated unless you run it
by hand.
So somebody should figure out a way to handle this for desktop machines.
a combination of calling {daily,weekly,monthly} from @reboot crontab
entries, and those scripts recording their last run date in
timestamp files somewhere.
when they get called at a reboot or at the normally scheduled time,
if they haven't run in x days, then do stuff. similarly if you
leave your laptop off for a week, boot it up at midnight and it runs
daily and weekly right away, it shouldn't run them again at 1:30 and
3:30.
Re: way to help: laptops and weekly
On Jan 24, 2010, at 12:15 PM, Ted Unangst wrote: Since we have to roll our own because #1, may as well fix #2. I think a better solution is something that runs weekly from shutdown. I hit the power button, I walk away, and the next time I use it everything is up to date. It never interrupts my work or slows down startup. I have to vote against this. on my laptop, shutdown needs to happen _now_. running a disk intensive operation sporadically at shutdown when my battery is at 10% is a guaranteed way to trash my filesystems. and leave the job half finished. a couple of options occur to me: 1. introducing something like anacron to base ( maybe stealing features from fcron ) 2. setting weekly to start at boot with a high nice level 3. adding a FAQ section for workstations/laptops telling people to use anacron
Re: way to help: laptops and weekly
Ted Unangst wrote: On Sun, Jan 24, 2010 at 3:00 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Sun, 24 Jan 2010, Ted Unangst wrote: Are you sitting around feeling bored because you don't know how to help out OpenBSD? Did your requests for info on where to start come back with unhelpful responses? I've got just the thing for you: an idea! Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. So somebody should figure out a way to handle this for desktop machines. sysutils/anacron Right, but I think this is something base should handle more gracefully. The locate database is part of the OS, therefore the OS should take the necessary steps to maintain it. Drawbacks of anacron: 1. GPL. Can't import in base. 2. Doesn't run things at a set time. You probably don't want weekly running when you're actually using the system. Since we have to roll our own because #1, may as well fix #2. I think a better solution is something that runs weekly from shutdown. I hit the power button, I walk away, and the next time I use it everything is up to date. This seems like a good and bad idea. I would want something more optional. How about a message at shutdown : Press d to run daily, w to run weekly, b for both. wait a few seconds then continue with shutdown. If I am about to leave for all day, I don't really want something still running. It never interrupts my work or slows down startup. Both of these are a must. Running daily and weekly really dog down old systems -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein
Re: way to help: laptops and weekly
On Sun, Jan 24, 2010 at 3:15 PM, Ted Unangst ted.unan...@gmail.com wrote: On Sun, Jan 24, 2010 at 3:00 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote: On Sun, 24 Jan 2010, Ted Unangst wrote: sysutils/anacron Right, but I think this is something base should handle more gracefully. The locate database is part of the OS, therefore the OS should take the necessary steps to maintain it. Drawbacks of anacron: 1. GPL. Can't import in base. 2. Doesn't run things at a set time. You probably don't want weekly running when you're actually using the system. 'runwhen' is very good: http://code.dogmap.org/runwhen/ , but sigh it's GPL v.2, and the author is anal-retentive about distribution of modified versions. It probably has no chances of being in the base, but it is hopeful someone here could learn from its design and other tools from code.dogmap.org and related sites. Or maybe rewrite it under the BSD license... Yeah right! I wish I could, but again I am not a C or system hacker. Excerpt from http://code.dogmap.org/runwhen/overview/ But actually, there are some things runwhen does that at doesn't. You can interrupt its sleep and execute the job early by sending SIGALRM. You can have it wait indefinitely until SIGALRM. For cron-like jobs that run repeatedly, you can place an upper bound on the amount of time between runs, in case the system was off during the last scheduled run time, like anacron. If a job takes longer to run than the period between scheduled run times, then you can control on a per-job basis whether to wait for the previous run to finish or to run multiple instances concurrently. You can schedule as many jobs as you like, up to the kernel's maximum number of processes, instead of an arbitrary limit compiled into the scheduler. You can develop and use your own tools to modify the sleep duration, based on criteria I haven't thought of. An example of a 'runwhen' script: http://code.dogmap.org/runwhen/example/ No, you don't need 'daemontools' to run it, you can use 'runit' http://smarden.org/runit , It's under a BSD-like license, but sigh you guys probably have an aversion to the design as well since it's related to the 'daemontools' design... You can use 'runwhen' one-time jobs without 'daemontools' or 'runit'. 'sysutils/runit' is in ports. It's daemontools-compatible and more feature-rich. Other smarden.org tools are great too - socklog (also in ports) for example. It's really, what a surprise! MUCH better than syslog.
Re: way to help: laptops and weekly
On 1/24/2010 2:48 PM, Ted Unangst wrote: Cron runs the weekly update script every Saturday at 3:30am. If you use a laptop or other desktop, your computer probably isn't on then. So the locate and whatis databases never get updated unless you run it by hand. Perhaps run a script via cron occasionally, maybe every six hours where six hours corresponds to 3:30. If /var/log/weekly.out is more than, or exactly, a week old, run weekly. if /var/log/weekly.out is less than a week old, only run /var/log/weekly if it's 3:30am on Saturday.
