SEO

Hello,

I'm having the following problem, maybe someone will be able to help
me:

I have a SCO Openserver 5.05 machine which stopped executing at jobs.

When I use the at command:
at now + 2 minutes
ls -la
Ctrl-D
it says that the job will be executed, but after half an hour the job
is still in the /usr/spool/cron/atjobs folder and never gets executed.
At the same time, cron is working correctly (apparently) since crontab
job get executed without any problems.

I don't know what to check to find a soluzione to the problem.

Any idea ?

Thank you in advance.

Paolo Asioli

Paolo Asioli typed (on Thu, Nov 06, 2003 at 07:34:18AM -0800):
| Hello,
|
| I'm having the following problem, maybe someone will be able to help
| me:
|
| I have a SCO Openserver 5.05 machine which stopped executing at jobs.
|
| When I use the at command:
| at now + 2 minutes
| ls -la
| Ctrl-D
| it says that the job will be executed, but after half an hour the job
| is still in the /usr/spool/cron/atjobs folder and never gets executed.
| At the same time, cron is working correctly (apparently) since crontab
| job get executed without any problems.
|
| I don't know what to check to find a soluzione to the problem.
|
| Any idea ?

Is oss642a installed? Maybe it fixes the problem.

As you show it, that cron job would only result in sending
you some email with the output of 'l -a'.

--
JP

On 6 Nov 2003 07:34:18 -0800, asioli@libero.it (Paolo Asioli) wrote:

>Hello,
>
>I'm having the following problem, maybe someone will be able to help
>me:
>
>I have a SCO Openserver 5.05 machine which stopped executing at jobs.
>
>When I use the at command:
>at now + 2 minutes
>ls -la
>Ctrl-D

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.

Try it this way:

at now +2 minutes
date > /tmp/date.out
<ctrl>D

The contents of the /tmp/date.out file will be when cron executed the
at command. If you wanna see output on a terminal, try it this way:

at now +2 minutes
ls -al | /usr/lib/lponlcr > /dev/tty01
<ctrl>D

Whatever you do, don't run anything from the "at" command that
requires a keyboard command or keyboard input to terminate. It will
run forever until you kill the job.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# jeffl@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager jeffl@cruzio.com AE6KS

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 ?

I'll investigate, but if anyone has idea to help be troubleshoot is
very welcome !

Thank you very much.

Paolo

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

PROBLEM SOLVED !!!!

Thank you all, with your help I got a better understanding of the
internals of the "at" command.

The stuck jobs DID show in the at -l queue list, but they never got
executed.

This was caused by older jobs that were still executing but in effect
stuck (the process hung and was never killed) that filled up the 4
places allowed by default in the at queue. In that case the at simply
stopped executing new jobs, since it was waiting for the older ones to
finish.

Thank you again for the help !

Best regards,
Paolo