In article <62e8b5d1.0311070031.6b14d18e@posting.google.com >,
Paolo Asioli <asioli@libero.it> wrote:
>Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote in message news:<lbjlqvke8kskfsgsen0rgm9e8bplfantbe@4ax.com>. ..
>
>> Wrong. cron needs to have a "controlling terminal" in which it can
>> send its output. The default is to either eat the output or send it
>> gift wrapped via email. Check your root email.
>
>Sorry, I dodn't explain myself. With that command I know that the
>output of that command will go in the user's email.
>
>But the problem is that, while crontab jobs are correctly executed on
>that machine, "at" jobs aren't executed anyore. We have a number of
>5.05 installations and lately two or three of them showed the problem:
>basically after a time, we don't know why, the "at" command stops
>working.
>And to test this malfunctioning, if you schedule a simple command like
>"ls -la", which reads the current directory and send the output to the
>user's email, the job stays in the queue without ever getting
>executed.
>
>This is becoming a really big problem, since the nightly batch
>transfers don't get executed anyore and it seems to be difficult to
>convert everything to crontab.

>Any ideas ?

>Suppose that a number of jobs result still in the queue: is it
>possible that cron keeps subsequent at jobs in the queue if the limit
>in queuedefs has already been reached ?

Do these jobs show up in at's queue - or are they simply gone and
not just not executing. That wasn't clear.



--
Bill Vermillion - bv @ wjv . com