in reply to Re^2: Perl app won't compile /run from cron
in thread Perl app won't compile /run from cron

"This is a headless server so having libraries splattered around isn't helpful"

Then don't do that. If you are using the system perl and a package is available in apt, use that, otherwise you need to install things in the right place (sudo cpanm Image::Grab), or (as detailed in other replies you already have) specify the correct paths for your cron jobs for where you have installed things.

Replies are listed 'Best First'.
Re^4: Perl app won't compile /run from cron
by dazz (Beadle) on May 24, 2018 at 22:56 UTC
    Hi
    I didn't intentionally install the modules in the home directory but even if I did, I am trying to run a cron perl script as user (not root). So perl should have configured itself to do that by default.
    I have just run  sudo cpan BLOB, the other module not found. It is installed in /usr/local/share/perl/5.24.1/BLOB
    Installing the modules as root has fixed the problem. The perl compiler can now find the modules by default.

    So modules installed with CPAN in the home user directory aren't found when the script is run as user by cron. That's a bug.


    Dazz
[reply]
[d/l]
[select]

      That's a bug.

      No it is not a bug, cron was designed that way

      cron is designed to set up a minimal environment when it starts a cron job. It is not a login session so it does not add any environment settings specified via login-semantics such as found in rc files. it is up to you to set them up.

      The Cron Environment and Cron Job Failures discusses this in more depth.

[reply]

      "I didn't intentionally install the modules in the home directory but even if I did, I am trying to run a cron perl script as user (not root). So perl should have configured itself to do that by default. "

      This would be undesirable behaviour. Users without appropriate permissions should not be able to install things system wide. Fortunately for us as users the tools provide this useful feature under the hood to take care of this. If you read cpanm and local::lib you'll understand what they do.

      "So modules installed with CPAN in the home user directory aren't found when the script is run as user by cron. That's a bug."

      I appreciate why you may think so, but this is not the case, it isn't a bug. If you take a step back and think about this from the perspective of security and a multi user system, this is how it's supposed to work. The alternative options described in other responses would also have worked.

[reply]
        Hi
        If I install a module with cpan as root, then the @INC is correctly updated and the perl scripts run perfectly from cron as user or root.
        So a user without root access loads perl into the user home dir, then tries to run the same script from cron user. That fails because cpan didn't update @INC environment correctly.

        How can that not be a cpan bug???

        Having to hand edit @INC is a work-around, not a solution.
        Similarly installing modules as root to avoid the issue for a user is also a work-around, and not a good one.

        The solution is to fix the root cause.

        It is not a risk to security if the user environment @INC is updated by cpan to allow a user to run perl scripts from user cron. If it is designed that way, then what you are saying is that it is designed to fail by default. It isn't like running a perl script from cron is a rare event. It should be easy.


        Dazz
[reply]

In Section Seekers of Perl Wisdom