in reply to Re: executing "at" from perl
in thread executing "at" from perl

Thanks, all.

My option number 3 does not work:

system "echo rm $session_file | at now + 1 minute";
The session file is created, the job shows up in atq, but it fails silently. It's the 'silently' part that is most maddening. Hm maybe I should direct errors somewhere..but the apache user isn't in /etc/at.deny, and indeed I forced a shell on the user and it worked okay--I thought cdarke might be on to something :-)

gmargo: I hear you loud and clear. I think I'm going to check out moritz suggestion and check out CGI::Session. However, in this case I'm putting in the 'at' right after creating the session file, so at least it isn't from user input. So I *presume* it's okay, but yeah, I'll check out CGI::Session :-). I hear ya loud and clear, and appreciate the input.

Really now it just bugs me that I don't know why it fails.

Replies are listed 'Best First'.
Re^3: executing "at" from perl
by rastoboy (Monk) on Nov 17, 2009 at 06:04 UTC
    Hm actually it doesn't look like CGI::Session automatically cleans up old session files? I was wondering how that would work.

    This script is going to run on a server I don't admin, so I'm concerned about leaving these things lying around on his hard drive.

      All right just for the record I've isolated it to an OS level issue. I even became the apache user and executed the spool file from /var/spool/at and it worked! But in root's mail I'm getting (consistently when the job is run):
      This account is currently not available.
      Now I may not understand exactly what that means, but it seems reasonable to believe that that's the barrier I'm running up against. I do appreciate y'alls input, and I learned a few things so your time was not wasted :-)

        I wonder if that means that the apache user is not allowed to send (or receive) email? Normal cron/at output is sent via email. (What os is this?) (Do a test using echo, not rm.)