in reply to The "Perl script on command line works but as cronjob it fails" story revisited

These things are normally caused by one of four things...

  1. Running under a different user, therefore different permissions.
  2. Running under a different user, therefore different "dotfiles".
  3. Running through cron, therefore different environment variables.
  4. Running through cron, therefore different working directory (avoid relative file system paths).
package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
  • Comment on Re: The "Perl script on command line works but as cronjob it fails" story revisited

Replies are listed 'Best First'.
Re^2: The "Perl script on command line works but as cronjob it fails" story revisited
by karlgoethebier (Abbot) on Mar 05, 2013 at 12:16 UTC

    Hi tobyink, shure.

    But what really confuses me is: No mail, no syslog but my tmp files get written.

    Unfortunatly i can't remote this boxes cause i'm @home today...

    But i'll take a look in depth at it (env) when i'm back in office.

    I checked the other issues yesterday - OK

    And honestly, i don't have any idea why environment matters in this case.

    Perhaps i made some false assumptions: e.g. that this boxes are clones...(as been told by the admin who did the setup).

    Thanks and regards, Karl...and i'll give some feedback

    «The Crux of the Biscuit is the Apostrophe»

      karlgoethebier:

      In my (unfortunate) experience, clones are only identical the moment they're cloned. Normally there's an immediate tweak so they don't collide on the network. But soon after a package gets installed on one but not the other, or someone tweaks the "production" server and forgets to tweak the "backup" server. Or they make a test on the "backup" without cleaning up.

      The long and short of it is that I no longer trust anyone's statements when they tell me the system is a "clone". That's the reason you need to check the environment, permissions, account setups, etc. for everything that matters to your code, or the code that your code relies on.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.