[Info-vax] Are queue manager updates written to disk immediately ?

AEF spamsink2001 at yahoo.com
Tue Apr 16 21:43:01 EDT 2013


On Apr 11, 12:28 pm, Simon Clubley <clubley at remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2013-04-11, Jan-Erik Soderholm <jan-erik.soderh... at telia.com> wrote:
>
>
>
> > I guess accounting (acc/queue=ba0) also shows both jobs as runed?
>
> There's no accounting entry for the first job even though there is
> a full logfile, but since accounting log updates are buffered, then
> that's not really a major surprise.
>
> > Nothing weird with the start/finish timestamps in accounting?
>
> > I would look mare at something with the system clock at
> > startup that made the holding job to be released. Such
> > as a startup with wrong time setting or similar.
>
> All the timestamps on the log files and accounting are correct; the only
> time the system clock is corrected on this system is once a day during
> during the night from a NTP source and that job had already run a couple
> of hours previously. There was nothing strange in this NTP update job
> log file either.
>
> In addition, the queue entry number from the accounting record for the
> second job didn't match the entry number from the submit command in
> the first job.

What was that queue entry number?

So the first job submitted a job with entry number 3927.

The second job ran and submitted a new job with entry number 3923.

So you're saying that the second job did not have an entry number of
3927? You're saying that nothing ran with an entry number of 3927?

Can you please be more specific?

You wrote:

>From the end of the first run:

$       submit/queue=ba0/after:"tomorrow+08:20"
ownsrc:check_queues.com
Job CHECK_QUEUES (queue BA0, entry 3927) holding until 12-APR-2013
08:20
$       exit
  [deleted]       job terminated at 11-APR-2013 08:20:02.57

  Accounting information:
  Buffered I/O count:                204      Peak working set
size:       5088
  Direct I/O count:                  229      Peak virtual
size:         173040
  Page faults:                      1455      Mounted
volumes:                0
  Charged CPU time:        0 00:00:00.52      Elapsed time:       0
00:00:02.56

As the job had completed, the entry should have disappeared from the
queue database at that point. Instead after the system restart, the
same job ran again. Here is the end of the second run:

$       submit/queue=ba0/after:"tomorrow+08:20"
ownsrc:check_queues.com
Job CHECK_QUEUES (queue BA0, entry 3923) holding until 12-APR-2013 0
$       exit
  [deleted]       job terminated at 11-APR-2013 08:25:11.69

  Accounting information:
  Buffered I/O count:                204      Peak working set
size:       5680
  Direct I/O count:                  253      Peak virtual
size:         173040
  Page faults:                      1387      Mounted
volumes:                0
  Charged CPU time:        0 00:00:00.67      Elapsed time:       0
00:00:05.25

End of job details.


>
> Thanks for the suggestions however, I do appreciate them.
>
> Simon.
>
> --
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

AEF



More information about the Info-vax mailing list