Yes, I have created custom iso with debug output. It didn't help, so
another one with strace was created.
On Jan 27, 2016 00:56, "Alex Schultz" wrote:
> On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
> wrote:
> > When there is too high strata,
I've got proposal from mos-linux team about switch to sntp instead of
ntpdate due to ntpdate deprecation. It looks nice enough for me but we
already had similar problems with sntp before switching to ntpdate.
Does anyone vote against switching to sntp?
On Wed, Jan 27, 2016 at 2:25 PM, Maksim
I think we shouldn't depend on the other services like Syslog and logger
trying to catch the problem and it is better to create the logs ourselves.
On Wed, Jan 27, 2016 at 1:49 PM, Stanislaw Bogatkin
wrote:
> >But you've used 'logger -t ntpdate' - this is can fail again
But you've used 'logger -t ntpdate' - this is can fail again and logs can
be empty again.
My opinion we should use output redirection to the log-file directly.
On Wed, Jan 27, 2016 at 11:21 AM, Stanislaw Bogatkin wrote:
> Yes, I have created custom iso with debug
>But you've used 'logger -t ntpdate' - this is can fail again and logs can
be empty again.
What do you mean by 'fall again'? Piping to logger uses standard blocking
I/O - logger gets
all the output it can reach, so it get all output strace will produce. If
ntpdate will hang for some
reason - we
Hi guys,
for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
time, but breaks our BVT and swarm tests. There is no exact point where
problem root located. To better understand this, some verbosity to ntpdate
output was added but in logs we can see only that packet exchange
On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
wrote:
> Hi guys,
>
> for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
> time, but breaks our BVT and swarm tests. There is no exact point where
> problem root located. To better understand
When there is too high strata, ntpdate can understand this and always write
this into its log. In our case there are just no log - ntpdate send first
packet, get an answer - that's all. So, fudging won't save us, as I think.
Also, it's a really bad approach to fudge a server which doesn't have a
On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
wrote:
> When there is too high strata, ntpdate can understand this and always write
> this into its log. In our case there are just no log - ntpdate send first
> packet, get an answer - that's all. So, fudging won't save
Yes, there is no information in the logs as Stanislaw said before, also
maybe exist another problem with syslog logging, so maybe on of the
solution is don't use -s option or external 'logger' program, and better
use simple redirection of stdout and stderr to the plain log file?
On Wed, Jan 27,
10 matches
Mail list logo