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. | [reply] [d/l] |
| [reply] |
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 :-) | [reply] [d/l] |