manipulating/testing file times.

[David Collier]

Thanks Jim,

I'm a real newbie to all this stuff... our real programmer has moved on
to pastures new :-)

We have a hardware watchdog, but at present it is tickled simply by a
single simple process... of course that will probably keep running even
if hell freezes over, while the comms to the box falls in a heap. And no
comms means no product.

I THINK I need to draw together a set of "heartbeats" from shepherd
processes watching OpenVPN, DHCP client, PPP-over-GPRS etc, plus our data
logging processes, and try to make a decision whether to reboot.

Fun stuff.

D

In article <F4AC465B29B61A4FA792A4E6FEA8A20201545772 at wamxm01.ciena.com>,
jcathey at ciena.com (Cathey, Jim) wrote:

> *From:* "Cathey, Jim" <jcathey at ciena.com>
> *To:* <busybox at busybox.net>
> *Date:* Mon, 29 Nov 2010 09:22:18 -0800
> 
> >mmmmm that would be nice - though it's still useful during 
> debugging to
> >be able to peer at the file times - if I used "job at" I haven't 
> looked
> >into how to get a list of future 'pending events'.
> 
> On the systems I used (SVR2-4) it was via "atq".  I think there were
> also options to "at" itself that would tell you what was scheduled.
> You could also dig it out of the files that cron left for itself in
> case of a system reboot.  (The at jobs _would_ be executed, but late
> if the system were not actually running at the scheduled time.  The
> periodic cron jobs would be skipped unless the system were running 
> at
> the scheduled time.)
> 
> >I hate polling too, but I feel the need to run shepherd and 
> watchdog
> >functions, and that is inherently a sort of polling.
> 
> It is.  The trick is to be able to combine everything down to _one_
> poll, and to keep that small.  For example, relying on an underlying
> X.25 transport's keepalive function to notify you when a connection
> goes down, which gets propagated via read/write failure to _all_ 
> clients
> using the transport, rather than burdening each and every user of 
> the
> transport with its own heartbeat, as we had to do once when we 
> moved a
> product from X.25 to IP WAN transports.  (Bitter?  Not I!)
> 
> Minimize the polling to the absolute minimum, and convert everything
> else to event-driven.  That's the secret to efficiency.
> 
> The worst crons I've seen wake up every second and run their control
> file to see if there's anything to do.  The best ones (and the 
> original
> Unix one) calculate a delay list from the control file, and go to 
> sleep
> until the next scheduled event.
> 
> -- Jim
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>