Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

PAR binary with Storable works for a while then dies

by iguanodon (Priest)
on Jun 04, 2007 at 20:09 UTC ( [id://619220]=perlquestion: print w/replies, xml ) Need Help??

iguanodon has asked for the wisdom of the Perl Monks concerning the following question:

I work with several AIX boxes where I don't have root access, and getting new modules installed is a long, difficult process. So far I've been able to install my own copy of Perl on a dev box, but not on any test or production ones. In order to use non-core modules in my scripts I opted to not install them locally, instead I've been packing them up with PAR on the dev box and distributing the binary to the test and prod environments. This all works fine... until it stops working. When I first install a PAR binary everything runs smoothly. But after some period of time (usually a few weeks), the script will die with this error:
String found where operator expected at ../../lib/Storable.pm (autospl +it into ../../lib/auto/Storable/_retrieve.al) line 319, near "logcroa +k "can't open $file: $!"" (Do you need to predeclare logcroak?) String found where operator expected at ../../lib/Storable.pm (autospl +it into ../../lib/auto/Storable/_retrieve.al) line 325, near "logcarp + "Storable::lock_store: fcntl/flock emulation broken on $^O"" (Do you need to predeclare logcarp?) String found where operator expected at ../../lib/Storable.pm (autospl +it into ../../lib/auto/Storable/_retrieve.al) line 328, near "logcroa +k "can't get shared lock on $file: $!"" (Do you need to predeclare logcroak?) syntax errorsyntax error at ../../lib/Storable.pm (autosplit into ../. +./lib/auto/Storable/_retrieve.al) line 325, near "logcarp "Storable:: +lock_store: fcntl/flock emulation broken on $^O"" syntax error at ../../lib/Storable.pm (autosplit into ../../lib/auto/S +torable/_retrieve.al) line 328, near "logcroak "can't get shared lock + on $file: $!"" Compilation failed in require at //export/home/user/perl/lib/5.8.8/Aut +oLoader.pm line 27. at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/retr +ieve.al) line 303
The last line there is strange, the path given in the "Compilation failed in require at" exists only on the dev box, but it gets printed on the other boxes. I don't know what to make of that but I thought it might be worth mentioning.

I thought this might be due to corruption of the file Storable is storing to, but deleting the file and letting it get get created again doesn't solve the problem. I also don't think the problem is corruption of the packed PAR file. I've just started tracking checksums to verify that but I'll have to wait until the problem reappears to know for sure.

But I've found that if I just re-pack the binary with PAR and distribute it again, it solves the problem. No changes to the code, just pack again and it starts working. Then the new binary will work for a few weeks and blow up again.

Any pointers to help me debug this further?

Replies are listed 'Best First'.
Re: PAR binary with Storable works for a while then dies
by Anonymous Monk on Jun 05, 2007 at 06:21 UTC
    It looks like the temporary directory where PAR unpacks your program is getting corrupted
      Thanks, that makes sense. Rather than try and figure out why this is happening, I'm just going to set up a local perl lib directory on these boxes and install my non-core modules there.

Re: PAR binary with Storable works for a while then dies
by belg4mit (Prior) on Jun 07, 2007 at 00:24 UTC
    As the AM mentioned, this is the tmp files. Many distributions have something like tmpwatch which automagically prunes "old" cruft from /var/tmp and /tmp to help promote system stability; running out of scratch space can lead to very bad things.

    --
    In Bob We Trust, All Others Bring Data.

      Thanks. Based on AM's response I took another look at the PAR docs and found out about PAR_GLOBAL_TEMP. But I'm confused about whether that var needs to be set on the target machines or if I can just set it on the build machine. If I could set PAR_GLOBAL_TEMP to something like ~/tmp/par/program_name on the build machine and it would just work on the target machines that would be the best situation.

      I'll experiment with this when I get to work.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://619220]
Approved by Joost
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (6)
As of 2024-03-19 02:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found