in reply to possible perl5.8.7 bug?

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.

Replies are listed 'Best First'.
Re^2: possible perl5.8.7 bug?
by Pstack (Scribe) on Jan 03, 2006 at 22:47 UTC

    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

[reply]

      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?

[reply]
[d/l]
[select]

        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

[reply]
        My apologies. I did reply, but it may have been pulled due to non-formatting or poor-formatting! Cheers. Pstack
[reply]
Re^2: possible perl5.8.7 bug?
by Pstack (Scribe) on Jan 13, 2006 at 04:32 UTC

    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??

[reply]

In Section Seekers of Perl Wisdom