/etc/crontab not running jobs on debian lenny
in [General Linux]
|
Prev: NYC LOCAL: Friday-Sunday 16-18 July 2010 The Eighth Hackers on Planet Earth Gathering
Next: netbook as fax machine
From: JohnT on 16 Jul 2010 17:01 On Fri, 16 Jul 2010 15:17:06 +0000, J G Miller wrote: > On Fri, 16 Jul 2010 14:27:39 +0200, Aragorn wrote: > >> cron runs Bash (or whatever the default shell is) > > On legacy systems ie Unix it will be Bourne Shell, and increasingly on > Linux systems it will be Dash. > > So cron script writers should avoid using bashisms in their scripts. I don't think it is environment or shell problems. It has been intermittent for a while. Worked again this morning, after not working all week ! JohnT
From: Aragorn on 17 Jul 2010 02:09 On Friday 16 July 2010 23:01 in comp.os.linux.misc, somebody identifying as JohnT wrote... > On Fri, 16 Jul 2010 15:17:06 +0000, J G Miller wrote: > >> On Fri, 16 Jul 2010 14:27:39 +0200, Aragorn wrote: >> >>> cron runs Bash (or whatever the default shell is) >> >> On legacy systems ie Unix it will be Bourne Shell, and increasingly >> on Linux systems it will be Dash. Bash normally runs in traditional Bourne shell mode when invoked as "sh" - there should normally be a symlink "/bin/sh" pointing at "/bin/bash". >> So cron script writers should avoid using bashisms in their scripts. > > I don't think it is environment or shell problems. > It has been intermittent for a while. > Worked again this morning, after not working all week ! Software cannot "change" over time. Hardware can, e.g. a wearing-out hard disk, voltage regulation problems on the motherboard/CPU, overheating, et al. Therefore, if the problem is intermittent - and I have already mentioned this in my original reply to you - then the possibility of /some/ kind of hardware failure should to be taken into consideration. -- *Aragorn* (registered GNU/Linux user #223157)
From: The Natural Philosopher on 17 Jul 2010 05:52
Aragorn wrote: > On Friday 16 July 2010 23:01 in comp.os.linux.misc, somebody identifying > as JohnT wrote... > >> On Fri, 16 Jul 2010 15:17:06 +0000, J G Miller wrote: >> >>> On Fri, 16 Jul 2010 14:27:39 +0200, Aragorn wrote: >>> >>>> cron runs Bash (or whatever the default shell is) >>> On legacy systems ie Unix it will be Bourne Shell, and increasingly >>> on Linux systems it will be Dash. > > Bash normally runs in traditional Bourne shell mode when invoked > as "sh" - there should normally be a symlink "/bin/sh" pointing > at "/bin/bash". > >>> So cron script writers should avoid using bashisms in their scripts. >> I don't think it is environment or shell problems. >> It has been intermittent for a while. >> Worked again this morning, after not working all week ! > > Software cannot "change" over time. Hardware can, e.g. a wearing-out > hard disk, voltage regulation problems on the motherboard/CPU, > overheating, et al. > > Therefore, if the problem is intermittent - and I have already mentioned > this in my original reply to you - then the possibility of /some/ kind > of hardware failure should to be taken into consideration. > Not necessarily. I have had cron jobs fail, or daemons crash, simply because of things like a previous instance still running due to network problems for example, or some other process having a lock on a file that a cron job should have backed up. Software cease to become totally predictable at the point where multi-threading and asynchronous threads become possible As I learnt early on in my software engineering career, when a board I had written a complete OS for crashed every few hours. Essentially out of about 64k of ROM code, if a timer interrupt occurred precisely between two bytes of main code, the board would crash. The chances of that were somewhat increased by the fact that this was a non multitasking prototype, and instead of putting the foreground process to sleep, it sat in a moderately large loop waiting for keyboard input. Easy enough to find: I cranked the interrupt rate up from a millisecond to about a microsecond, put it on the hardware emulator, and zap. It failed in a couple of seconds. Asynchronous interrupts and data that may vary on I/O can render any piece of software unpredictable: In fact 100% predictable software is the exception, not the rule. A huge amount of work and thought has gone into the analysis and writing of such code, because at one time the military considered that it was an attainable goal. I haven't followed the arguments for some time, but I believe the final conclusion was that 100% predictable software could only be achieved in systems sufficiently simple to not actually do anything useful. Which is why airliners using fly by wire now carry several systems written in completely different ways on different hardware, to do the same job. It being reasonably felt that if one system fails it is unlikely that the others will. |