in reply to Re: Authen::Krb5 Problem
in thread Authen::Krb5 Problem

Not very helpful to me but hopefully you can understand it. To me the puzzle is why does an attached console make any difference?

No, but the oracle might.

Credentials cache I/O operation failed XXX

Cause:

Kerberos had a problem writing to the system's credentials cache (/tmp/krb5cc_uid).

Solution:

Make sure that the credentials cache has not been removed, and that there is space left on the device by using the df command.

Might be permissions Credentials cache I/O operation failed XXX (with 1.5.x on Windows 2003 Terminal Server)?

Replies are listed 'Best First'.
Re^3: Authen::Krb5 Problem
by gw1500se (Beadle) on Nov 05, 2008 at 15:44 UTC
    Thanks for the reply but its none of the above. There is plenty of space in that file system. However, lets not lose sight of the original problem. This only fails when it is run without a console (cron or at). Since the script runs in root's crontab I don't see how permissions can be a problem, particularly in /tmp.
[reply]

      Add code to your script that dumps the environment variables (sorted) to a file. Capture the outputs of successful and unsuccessful runs and diff the files. You'll probably find that the limited environment provided by cron and at is missing one or more environment variables that are required to allow kerberos clients to work correctly on your system. If this is the case, you can create a file that exports the missing variables and source it in the crontab entry.

      converter

[reply]
        The only difference in environment variables that even has a long shot as far as I can tell is the shell. When run from command line it is using 'bash' and when running from 'cron' it is using 'sh'. Does perl even care? I thought perl runs in its own shell. Anyway, sourcing `. /etc/profile` in the script does not help.
[reply]
      It has to be; how did you check?
[reply]

In Section Seekers of Perl Wisdom