[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #XQC-361661]: LDM Question

Hi Bob,

> I agree that waiting till XXX XXXX has time to resolve the queue size
> issue is resolved makes sense.
> 
> But, I can't explain one thing. When I changed the crontab entry to be:
> 0 0 * * * bin/ldmadmin check |& cat > /var/tmp/ldm.log
> 
> This is the output I see in /var/tmp/ldm.log:
> 
> (ldm.ipa.unca.edu /ldm-home > cat /var/tmp/ldm.log
> Checking for a running LDM system...
> Checking the system clock...
> Couldn't get time from time-server at ntp.ucsd.edu using the ntpdate(1)
> utility, "chronyd -Q 'pool pool.ntp.org iburst'".  If the utility is valid
> and this happens often, then remove ntp.ucsd.edu from registry parameter
> "/check-time/ntpdate/servers".
> 
> Couldn't get time from time-server at otc1.psu.edu using the ntpdate(1)
> utility, "chronyd -Q 'pool pool.ntp.org iburst'".  If the utility is valid
> and this happens often, then remove otc1.psu.edu from registry parameter
> "/check-time/ntpdate/servers".
> 
> Couldn't get time from time-server at ntppub.tamu.edu using the ntpdate(1)
> utility, "chronyd -Q 'pool pool.ntp.org iburst'".  If the utility is
> valid and this happens often, then remove ntppub.tamu.edu from registry
> parameter "/check-time/ntpdate/servers".
> 
> Couldn't get time from time-server at pool.ntp.org using the ntpdate(1)
> utility, "chronyd -Q 'pool pool.ntp.org iburst'".  If the utility is valid
> and this happens often, then remove pool.ntp.org from registry parameter
> "/check-time/ntpdate/servers".
> 
> Couldn't get time from time-server at ntp1.cs.wisc.edu using the
> ntpdate(1) utility, "chronyd -Q 'pool pool.ntp.org iburst'".  If the
> utility is valid and this happens often, then remove ntp1.cs.wisc.edu
> from registry parameter "/check-time/ntpdate/servers".
> 
> You should either fix the problem (recommended) or disable time-checking
> by executing the command "regutil -u 0 /check-time/enabled" (not
> recommended).

That's the output I expect from *before* the changes you made.

> NO mention of the queue size problem.
> 
> But when I run the check from the command line, I see the message about the
> queue size.
> 
> (ldm.ipa.unca.edu /ldm-home > ldmadmin check
> Checking for a running LDM system...
> Checking
> Checking the most-recent insertion into the queue...
> Vetting the size of the queue against the maximum acceptable latency...
> vetQueueSize(): The maximum acceptable latency (registry parameter
> "/server/max-latency": 3600 seconds) is greater than the observed
> minimum virtual residence time of data-products in the queue (8 seconds).
> This will hinder detection of duplicate data-products.
> The value of the "/reconciliation-mode" registry-parameter is "do nothing"
> vetQueueSize(): The queue should be 199424005200 bytes in size with
> 735300 slots or the maximum-latency parameter should be decreased to
> 8 seconds. You should set registry-parameter "/reconciliation-mode" to
> "increase queue" or "decrease maximum latency" or manually adjust the
> relevant registry parameters and recreate the queue.

This output is what I expect *from* the changes you made.

It's as if the "bin/ldmadmin" being invoked by the chrontab(1) entry is *not* 
the same ldmadmin(1) being invoked by your user shell. Is the user the same? 
Same PATH? Same current working directory (the LDM user's home directory)? etc.

> I don't think this is an issue with the time the crontab entries are
> running as I have tried running the check at various times during the day
> always with the above queue size error. But I only see the chronyd error
> messages when I run the check in a crrontab entry.
> 
> It probably isn't worth working on this any more till we can resolve the
> queue size error.

Roger that.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: XQC-361661
Department: Support LDM
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.