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 runme.sh "fails" ? Is there any error output given?

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 together with module search-logic that restricts itself to a single arch (i686 OR i386) only??

-imran