in reply to vanishing system call

In addition to checking the return code and printing $? if the return code is non-zero, make sure you have enough file temp space.

Sort creates temporary files under /tmp or where $ENV{TMPDIR} points to depending on your version of sort. Make sure you have upto double the size of what you are sorting (e.g. 60 MB). If I'm sorting something large I specifically set the temp sorting directory (many sort's use -T) so I know I have enough space and am not competing with someone else's space usage.

bluto

Replies are listed 'Best First'.
Re: Re: vanishing system call
by Anonymous Monk on Sep 20, 2002 at 20:26 UTC
    Hi all,
    This reply is to the previous three posts, as some possibilities are raised more than once. Thanks for all the help...

    Temp space - checked that, and there's plenty of room. Helpfully enough, we did have some trouble with space limitations on /var/tmp on this server previously, and the error messages were fairly explicit.

    Output space - same thing, there's plenty of room in the output directory.

    Path to "sort" - a good point; I hadn't tried using the full path to the binary. But the script works perfectly until I increase the number of data files I'm processing past a certain point (3 of them). So I doubt the path is a problem.

    Unnecessary "cat" - oops. Quite right. I honestly don't know why I put that in there! I'll try it without "cat" - could that extra process be using up all our allocated memory? Again, I still don't understand why I wouldn't get some kind of error, if that were the case.

    Here's another interesting wrinkle. Before and after the "sort" system call, I just tried putting some other system calls to see if they worked. So now it looks like this:
    system("echo 'now executing sort...' "); system(" cat $file | sort -t\\| +1 -2 > $file.out"); system("ls -la");
    If I process 2 data files, all 3 system calls execute. If I process 3 data files, the first 2 system calls execute, but the third one doesn't. If I process 4 data files, none of them execute. Spooky! So, okay, if I'm running out of memory, why do the system calls die so silently? I guess I'm probably trying to determine if this is a Perl thing, or a Solaris thing. I'm baffled, though, because I've always found Perl to have exceptionally useful errors. I'll toss it by the Unix admins just to see what happens....
    Thanks!
      So, okay, if I'm running out of memory, why do the system calls die so silently?

      How do you know they are dying silently? You haven't been listening to what system may be trying to tell you. I recommend you debug this based starting strictly with the system() return values, since you say it was working before. Don't complicate the problem by changing several things at once.

      if (system "your command") != 0){ my $exitval = $? >> 8; # return val from your cmd my $signum = $? & 127; # set if cmd stopped by a signal my $coredumped = $? & 128; # set if cmd dumped core }
      What perl version are you running? On what Solaris?

      What does this program do for you?

      #!/usr/bin/perl -w use strict; $|=1; my $limit=20; for(my $i=0; $i<$limit; ++$i) { print "$i\n"; system("/bin/echo echoing -- $i"); }
      It works fine on the stock 5.005_03 that came with my Solaris 5.8 box. I can even increase $limit to 2000 with no problems.

      If that all works fine, all I can think of is that maybe you're using up too many filehandles as part of your other processing? What _else_ are you doing for each file, apart from the system calls?
      --
      Mike