I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while.
Jaap
I think what you want is a new cron feature to use criteria other than just time to decide when to run something. i.e., so you can say "every day, when idle or every week even if not idle".
On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote:
I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while.
Several things.
1. anacron(8) 2. batch(1) 3. nice(1) and renice(8) 4. xscreensaver-command(1)
With some combination of these, it is not too difficult to roll a (sub-optimal) solution using nothing more than scripting.
xscreensaver-command(1):
-watch Prints a line each time the screensaver changes state: when the screen blanks, locks, unblanks, or when the running hack is changed. This option never returns; it is intended for use by shell scripts that want to react to the screensaver in some way. An example of its output would be:
BLANK Fri Nov 5 01:57:22 1999 RUN 34 RUN 79 RUN 16 LOCK Fri Nov 5 01:57:22 1999 RUN 76 RUN 12 UNBLANK Fri Nov 5 02:05:59 1999
The above shows the screensaver activating, running three dif- ferent hacks, then locking (perhaps because the lock-timeout went off) then unblanking (because the user became active, and typed the correct password.) The hack numbers are their index in the â list (starting with 1, not 0, as for the -select command.)
For example, suppose you want to run a program that turns down the volume on your machine when the screen blanks, and turns it back up when the screen un-blanks. You could do that by run- ning a Perl program like the following in the background. The following program tracks the output of the -watch command and reacts accordingly:
#!/usr/bin/perl
my $blanked = 0; open (IN, "xscreensaver-command -watch |"); while (<IN>) { if (m/^(BLANK|LOCK)/) { if (!$blanked) { system "sound-off"; $blanked = 1; } } elsif (m/^UNBLANK/) { system "sound-on"; $blanked = 0; } }
Note that LOCK might come either with or without a preceeding BLANK (depending on whether the lock-timeout is non-zero), so the above program keeps track of both of them.
Regards,
Bill Rugolsky
Bill Rugolsky Jr. wrote:
On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote:
I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while.
Several things.
- anacron(8)
- batch(1)
- nice(1) and renice(8)
- xscreensaver-command(1)
With some combination of these, it is not too difficult to roll a (sub-optimal) solution using nothing more than scripting.
true. This reminds me, that it's seriously annoying that xscreensaver runs for vnc sessions. Seems like an easy fix.
Pádraig.
This reminds me, that it's seriously annoying that xscreensaver runs for vnc sessions. Seems like an easy fix.
How do you suggest? There are several possible approaches.
Its actually useful in a thin client environment that it does. And the user can configure blanking easily enough
Alan Cox wrote:
This reminds me, that it's seriously annoying that xscreensaver runs for vnc sessions. Seems like an easy fix.
How do you suggest? There are several possible approaches.
Its actually useful in a thin client environment that it does. And the user can configure blanking easily enough
True, though I think xcreensaver should be off by default under vnc.
Pádraig.
True, though I think xcreensaver should be off by default under vnc.
Why ?
Why send all of that traffic over a network? Even if it is local, it just seems like a waste to me...
Alan Cox wrote:
Its actually useful in a thin client environment that it does. And the user can configure blanking easily enough
True, though I think xcreensaver should be off by default under vnc.
Because to ship screensaver output over vnc takes a lot of CPU and network resources. IMHO this should not happen by default, because newly setup machine with a few users running vncserver hammers the machine. If they want to setup screensavers explicitly, fine, but at least you can lart them for that :-)
Pádraig.
Because to ship screensaver output over vnc takes a lot of CPU and network resources. IMHO this should not happen by default, because newly setup machine with a few users running vncserver hammers the machine.
Just as true for non Vnc screensavers
If they want to setup screensavers explicitly, fine, but
at least you can lart them for that :-)
It sounds to me more of an argument for using 'blank' as the default screensaver except on localhost ?
On Thu, Oct 30, 2003 at 09:58:23AM +0000, P@draigBrady.com wrote:
Bill Rugolsky Jr. wrote:
On Wed, Oct 29, 2003 at 08:26:55PM +0100, Jaap A. Haitsma wrote:
I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while.
Several things.
- anacron(8)
- batch(1)
- nice(1) and renice(8)
/etc/cron.daily/prelink starts with renice +19 -p $$ >/dev/null 2>&1
I totally agree with Roland, this should be solved in cron. When a new category for run daily when the system is most idle or something like that is added, I'll certainly move prelink to that category. (and slocate.cron should fall in exactly the same category).
But, even current prelink cron job, if there are no changes on the system it shouldn't do too many disk accesses nor take much CPU time.
Jakub