[tpm] Net::SCP and Net::SFTP modules

[Rob Janes]

try running strace on it in the foreground, and in the background.

if you think it's the %ENV settings, why not Data::Dumper them.
probably better to custom dump them tho, so it's sorted.

print join("\n", map { "$_=$ENV{$_}" } sort keys %ENV), "\n";

the at command will run things quickly in the same environment as
cron, that can speed up your test cycles.  at -f xxxx now, or
at now <<HERE
my command line
HERE

however, you've done a lot of work on the environment angle, without
progress, so i think it's foreground vs background.  i'll bet it's
thinking about prompting for a password.  maybe doing this ...

by-your-command < /dev/null > /dev/null 2>&1

will change something if you run it in the foreground?

or how about

echo "farboo" > junk
by-your-command < junk > junkout 2>&1

try running in from the shell, but background it with &  processes
spawned by & still have access to the console.  you might want to put
some extra code in the perl to totally detach, see what happens.  put
this at the top ...

use POSIX qw(setsid :sys_wait_h);

defined(my $pid=fork) or die "cannot fork process:$!";

if ($pid) {
  do {
    print "waiting for $pid\n";
    $kid = waitpid($pid,0);
    $status = $?;
  } until $kid > 0;

  if ( WIFEXITED($status) ) {
    print "exit ", WEXITSTATUS($status), "\n";
    exit 1 if WEXITSTATUS($status);
    exit 0;
  } elsif ( WIFSIGNALED($status) ) {
    print "signal ", WTERMSIG($status), "\n";
    exit 2;
  }

  exit 3;
}

setsid || die "setsid: $!";

etc etc

On Mon, Nov 10, 2008 at 12:27 PM, Henry Baragar
<Henry.Baragar at instantiated.ca> wrote:
> On Sunday, November 09 2008 07:10 pm, Richard Dice wrote:
>> On Sun, Nov 9, 2008 at 6:23 PM, Henry Baragar
>> <Henry.Baragar at instantiated.ca
>>
>> > wrote:
>> >
>> > I have been trying to use Net::SFTP:  it works when I run the application
>> > from
>> > the shell, but not under cron!
>>
>> Cron as your user, or cron as the system cron?
>>
> The user is the same in both cases.
>
>> cron provides a huge dearth of environment variables and other things that
>> might be set up by your .login or .bashrc file.
>>
> I have removed the user .profile and .bashrc files (there is no .login or
> other *sh init files) and successfully run the script by hand.
>
>> My guess is that there is
>> something being provided by an envvar, shell alias, _something_ in your
>> personal environment that your Perl program somehow depends upon.
>>
> I have put the following command in the user's crontab:
>        /bin/bash --login -c 'sftp_script'
> with no luck.
>
>> Or it
>> might be something as simple as directory permissions and how they apply in
>> the context of the system cron user.  (might be root, might be cron, might
>> be something else)
>>
>> That debugging message hardly seems helpful, as it is telling where in the
>> stack of depended-upon modules the failure occurs at.
>>
> Agreed, but I was hoping that it behaved the same at other sites and that
> other users would recognize.
>
>> You should build
>> some debugging / error trapping (eval) code around each line in your
>> subroutine there to see where the failure actually occurs at from the
>> perspective of your program.  From there you can try to figure out how it
>> is different when run as yourself and when run as cron.
>>
> It fails on the following line:
>        $sftp->do_write($handle,0,$self->payload);
> That is, the file gets opened on the remote server but nothing ever gets
> written to it (i.e. it has a filesize of 0).
>
> It did not seem worthwhile to dig into the guts of Net::SFTP (which has been
> stable for 3 years) until I exhausted the Google and mailing list options.
>
> Regards,
> Henry
>
>
>> Cheers,
>>  - Richard
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/listinfo/toronto-pm
>