cron: b queue max run limit

[Ralph Grothe]

Hi,

I wonder if the reason for this is a massive performance bottleneck (but PerfView doesn't indicate such for the time of occurance), or there exists a maximum run limit to be set/configured somewhere?

In /var/adm/cron/log there are excessive entries as such (see below), and all cron jobs weren't executed but (as written) rescheduled.
The only rescue was to restart cron :-(

! b queue max run limit reached Tue Nov 26 18:05:06 MET 2002
! rescheduling at job Tue Nov 26 18:05:06 MET 2002
! b queue max run limit reached Tue Nov 26 18:05:34 MET 2002
! rescheduling at job Tue Nov 26 18:05:34 MET 2002


Can someone give me an explanation or a hint?

Regards
Ralph

[Jean-Louis Phelix · Accepted solution]

hi,

have a look at /var/adm/cron/queuedefs (man queuedefs) to see how concurrent cron jobs are limited.

Regards.

[Pete Randall]

Ralph,

If you have PHCO_24702 installed, you need to install PHCO_27141 as well. See this thread:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1cb03a7b3682d611abdb0090277a778c,00.html

Pete

[James R. Ferguson]

Hi Ralph:

See 'man 4 queuedefs'. The system-wide limit for all queues is 100.

Regards!

...JRF...

[Shannon Petry]

Set queuedefs to allow single or 2 jobs only. Also, make sure you install the patch recommended as your system will sit and spin trying to launch at jobs.

Regards,
Shannon

[Ralph Grothe]

Yes,
it seems you all were right in your assumption of too low queuedef values.
As it revealed upon inspection the value for batch jobs was set to only 4 and that for at jobs also.
For cron there wasn't an entry in the file so that I presume the default of 100 (or what is left from 100 when max batch an d at jobs are subtracted) will be taken for cron.
I increased both max jobs No. to 10 for at and batch (hope this will suffice).
Unfortunately I couldn't find something in neither the manpages of cron nor queuedefs on how this new value is conveyed to the running cron daemon.
I hesitate to restart cron through its init script right now (production server).
Will a SIGHUP to cron's PID be of any help?

[Pete Randall]

Ralph,

I certainly don't think it could hurt.

Pete

[Pete Randall]

Actually, Ralph, I tried the SIGHUP to be sure. It didn't have any ill effects - I just don't know if it will make cron re-read it's config. Try it and let me know, then we'll both have learned something.

Pete

[Ralph Grothe]

Pete,

actually, I cannot tell if SIGHUP has any effect on HP-UX's cron.

(usually this signal was only chosen as an informal convention of daemon developers to have them reread their configuration and reinitialize themselves, because as session leaders that are dissociated from the terminal they have no other need for a SIGHUP.
More recent daemons such as Apache's httpd actually prefer SIGUSR[12] to reinitialize I think)

After I sent cron a SIGHUP I couldn't find a confirming entry that it caught it.

I assume cron wil read queuedefs file (or a hashed copy) continously like new entries to crontabs.

Unfortunately the manpage doesn't reveal anything about its behaviour.

[Pete Randall]

Ralph,

I was hoping that, once you'd SIGHUP'ed, you would be able to see a flow of at jobs. Did you check for that patch I mentioned?

Pete