This involves code breaking ONLY with this (presently known) combination: perl5.8.7 using BerkeleyDB as a cron job.
There is no problem when it is not run as a cron job, nor when the perl5.8.0 interpreter is used and it is a cron job, nor when some other installed modules (besides BerkeleyDB) are USE'd with 5.8.7 under cron.
Is anyone aware of this conflict? I cannot say whether or not there are other modules besides BerkeleyDB which run foul of the 5.8.7 interpreter under cron. It is awkward for me to test because this vixie-cron has a bug requiring both stdout and stderr be redirected to null. But I do know, for instance, that there is no problem with the combination when some other modules (like Cwd) are alone used.
If anyone could point to other references touching on this idiosyncracy it would be appreciated.
Cheers
Pstack
Edited 1 Jan 2006, by footpad: Added basic formatting tags.
-imran
Generally speaking, it's a poor worksmith that blames his tools. And here, as in most languages, the reasonable approach is to assume that it is your code at fault, not perl or BerkeleyDB. That's not to say the perl interpreter is bug free (it isn't). Just that in programming in various languages since about '93, I've only happened upon one provable, verifiable compiler bug (MSVC - verified it by checking the assembly output which was wrong), and a couple of probable compiler/interpreter bugs (which I worked around by upgrading).
The rest of the time, however, and there are a lot of these, it's my code that is at fault. Most of these result in a "well, duh, of course it's going to go wrong!" when I realise the source of my error. Even then, the rest of these are just esoteric uses of code.
You may already know all of this. I can't tell as this was your first post here, and because you didn't post any code from which we could duplicate and cause the same problem with.
Thus, as CountOrlok asks, some example code would help. As would the error messaage. Yes, I know that you said vixie-cron has a bug here. So the question is - why can't you use a different cron? There are a few available. Or you could just use a wrapper script which reopens its stdout and stderr to a file and then runs your failing script.
The first thing that really hits me in the head is that it's the redirection, not cron, that is confusing some code, whether that's yours or BerkeleyDB's. And that it has nothing to do with the 5.8.7 interpreter, but the newer version of the BerkeleyDB module(s) that would come with the newer interpreter.
My apologies for taking the shortcut of looking only for a shared experience here (as clue) rather than a solution. The complexity of the problem etc!
(runme.sh): exec perl5.8.7 cronmgr.pl # always succeeds for 5.8.0
(cronmgr.pl): use Carp; print "ok done\n";
#non-cron> runme.sh # ==> "ok done"
#cronuser> runme.sh # ==> "ok done"
(cronmgr.pl): use BerkeleyDB; print "ok done\n";
#non-cron> runme.sh # ==> "ok done"
#cronuser> runme.sh # ==> FAIL
Let $bdbpath = `find / -name BerkeleyDB` # result(s)
(cronmgr.pl): use lib $bdbpath; use BerkeleyDB; print "ok done\n";
#non-cron> runme.sh # ==> "ok done"
#cronuser> runme.sh # ==> FAIL
The actual wrapper code in cronmgr.pl uses eval and logs custom messages from the results (but no captured meta output). The primary suspect is the cron environment, of course. But one would expect a targetted "use lib" to counter that surely? I have yet to try if Carp will be more informative. I will also try rolling out a newer cron, as suggested, seeing there are no similar experiences out there!
cheers Pstack
You seem to rely on perl5.8.7 to be found via $ENV{PATH} - I would want to eliminate any such reliance by using an explicit exec /opt/perl/bin/perl5.8.7, so that both users will always invoke exactly the same Perl binary. As BerkeleyDB uses a binary component, that component must be tailored to the perl5.8.7 you use. If for example one Perl was compiled with threads and the other wasn't, that might lead to the problems.
Also, could you elaborate on how the Unfortunately runme.sh has to have this form for cron: exec perl5.8.7 cronmgr.pl < /dev/null >&0 2>&0 and, of course, I cannot even pass back a useful exit value from cronmgr.pl because it is always seen as null (as long as the 5.8.7 interpreter itself fires ok, which it does!). And leaving out the chaining effect of exec, other subsequent commands in runme.sh will execute ok too. But food for thought on the config issues after a cron upgrade, if that doesn't help. cheers Pstack
Finally, I can agree there may not be a bug involved -- if the behaviour I find is intentional.
1.PERL5LIB loads as empty for the cron-user and so misses out on install configurations that other user's enjoy, despite having been assigned an ordinary environment in the calling shell-script through loading a dot-command.
2.eval puts the name of an unsuccessfully loaded module into %INC and, even when deleted, and a known-fix applied to PERL5LIB, the eval rerun still FAILS. But, ignoring the FAIL return from eval, the module can actually be successfully loaded and run.
3.Unfortunately, getting a fixed-cron to build is not as easy as all that. It appears to be very distro specific, and only available as an RPM, the latest for my distro being the one I have. I am still looking. CGI::Carp did at least help to trap meta-errors previously going awol.
4.My install of 5.8.7 has no problems except with cron. It correctly detected an architecture of i686 and installed accordingly, configured to correctly find user-pre-installed modules under Redhat's 'vendor-perl'/5.8.0/'i386' install, using PERL5LIB paths. My guess is that the empty PERL5LIB awarded to cron is to blame.
Reason: [jdporter]: troll trash
You may view the original node and the consideration vote tally.