exec("ntpdate <server>") doesn't work

[Thomas Brathans]

Hi,

when I try to execute the obove mentioned to synchronise the servertime by a
php-script, it doesn't work. Other shell-commands work fine. Executing
ntpdate <server> directly in the shell works also well.
So why doesn't it work?

Thanks...

[Tim Van Wassenhove]

Re: exec(&quot;ntpd ate &lt;server&gt;& quot;) doesn't work

On 2003-12-22, Thomas Brathans <thobr@t-online.de> wrote:[color=blue]
> Hi,
>
> when I try to execute the obove mentioned to synchronise the servertime by a
> php-script, it doesn't work. Other shell-commands work fine. Executing
> ntpdate <server> directly in the shell works also well.[/color]

I think only root can run ntpdate. And your webserver is not running as
root, you don't want that either.

Just install an entry for ntpdate in crontab for root to run it from
time to time... man crontab for more info.


--
verum ipsum factum

[Thomas Brathans]

Re: exec(&quot;ntpd ate &lt;server&gt;& quot;) doesn't work

Tim Van Wassenhove wrote:

[color=blue]
> I think only root can run ntpdate. And your webserver is not running as
> root, you don't want that either.
>
> Just install an entry for ntpdate in crontab for root to run it from
> time to time... man crontab for more info.[/color]

No, the rights seem to be ok. For my task it is necessary, that the time is
synchronised just before a certain action in my php-script.
Any other idea?

[clvrmnky]

Re: exec(&quot;ntpd ate &lt;server&gt;& quot;) doesn't work

Thomas Brathans wrote:
[color=blue]
> Tim Van Wassenhove wrote:
>
>
>[color=green]
>>I think only root can run ntpdate. And your webserver is not running as
>>root, you don't want that either.
>>
>>Just install an entry for ntpdate in crontab for root to run it from
>>time to time... man crontab for more info.[/color]
>
>
> No, the rights seem to be ok. For my task it is necessary, that the time is
> synchronised just before a certain action in my php-script.
> Any other idea?
>[/color]
It should be mentioned that using ntpdate in this manner is an egregious
hack. If you run xntp as a daemon, and have a few stratum 2 servers to
key off of, after the daemon settles down, the current time should be
close enough for anything you need to do. This is certainly good enough
to coordinate things like radio-astronomy devices.

The idea is to have a local box act as a local timeserver, so your
webserver, DB server &etc all run xntp using that local timeserver as a
master.

Read the docs for ntpdate (which is soon to be retired). There are a
number of caveats if you need to use it. It is really intended to slew
the local clock into some kind of decent shape prior to starting the ntp
daemon. It's use to arbitrarily and asynchronously set the clock in
this manner is definitely not recommended, and may result in your clocks
*not* being in correct sync.

[Thomas Brathans]

Re: exec(&quot;ntpd ate &lt;server&gt;& quot;) doesn't work

clvrmnky wrote:
[color=blue]
> Thomas Brathans wrote:
>[color=green]
>> Tim Van Wassenhove wrote:
>>
>>
>>[color=darkred]
>>>I think only root can run ntpdate. And your webserver is not running as
>>>root, you don't want that either.
>>>
>>>Just install an entry for ntpdate in crontab for root to run it from
>>>time to time... man crontab for more info.[/color]
>>
>>
>> No, the rights seem to be ok. For my task it is necessary, that the time
>> is synchronised just before a certain action in my php-script.
>> Any other idea?
>>[/color]
> It should be mentioned that using ntpdate in this manner is an egregious
> hack. If you run xntp as a daemon, and have a few stratum 2 servers to
> key off of, after the daemon settles down, the current time should be
> close enough for anything you need to do. This is certainly good enough
> to coordinate things like radio-astronomy devices.
>
> The idea is to have a local box act as a local timeserver, so your
> webserver, DB server &etc all run xntp using that local timeserver as a
> master.
>
> Read the docs for ntpdate (which is soon to be retired). There are a
> number of caveats if you need to use it. It is really intended to slew
> the local clock into some kind of decent shape prior to starting the ntp
> daemon. It's use to arbitrarily and asynchronously set the clock in
> this manner is definitely not recommended, and may result in your clocks
> *not* being in correct sync.[/color]

I was wrong - it actually was a matter of rigths, but I didn't notice it
cause some other stuff went wrong...
But I still think that my solution is a good one, cause right after
synchronising the time with ntpdate a file is timestamped... I see no other
way keeping the time between synchronisation and timestamping that short.
So nobody has the opportunity to manipulate the time before timestamping.

[clvrmnky]

Re: exec(&quot;ntpd ate &lt;server&gt;& quot;) doesn't work

Thomas Brathans wrote:
[color=blue]
> clvrmnky wrote:[/color]
[...][color=blue][color=green]
>>It should be mentioned that using ntpdate in this manner is an egregious
>>hack. If you run xntp as a daemon, and have a few stratum 2 servers to
>>key off of, after the daemon settles down, the current time should be
>>close enough for anything you need to do. This is certainly good enough
>>to coordinate things like radio-astronomy devices.
>>
>>The idea is to have a local box act as a local timeserver, so your
>>webserver, DB server &etc all run xntp using that local timeserver as a
>>master.
>>
>>Read the docs for ntpdate (which is soon to be retired). There are a
>>number of caveats if you need to use it. It is really intended to slew
>>the local clock into some kind of decent shape prior to starting the ntp
>>daemon. It's use to arbitrarily and asynchronously set the clock in
>>this manner is definitely not recommended, and may result in your clocks
>>*not* being in correct sync.[/color]
>
>
> I was wrong - it actually was a matter of rigths, but I didn't notice it
> cause some other stuff went wrong...
> But I still think that my solution is a good one, cause right after
> synchronising the time with ntpdate a file is timestamped... I see no other
> way keeping the time between synchronisation and timestamping that short.
> So nobody has the opportunity to manipulate the time before timestamping.[/color]

It's your design, of course, but you are not guaranteeing any further
precision on that timestamp by using ntpdate asynchronously. In fact,
you may be guaranteeing the exact opposite!

Depending on your server OS, it may be easy for non-privileged users to
change the system clock (if this is a concern, you have bigger
problems), but generally xntp run as a daemon works closely with your
hardware clock to keep it in tight precision with the stratum 2 (and
eventually, stratum 1) servers it talks to. This precision is much
tighter than a simple call to ntpdate.

AFAIK, ntpdate does not use the hardware clock drift to recalculate the
time, nor is it guaranteed to actually return the "correct" time (within
the advertised specs of ntp). It is a tool intended to slew the clock
into reasonable shape prior to running ntp. For non-critical
applications, it's probably fine. If you require a higher level of
precision or accuracy, then it is certainly not the way to go.

I'm assuming you are running a local timeserver, and your script calls
ntpdate on that server. Hitting random stratum 1 and 2 servers with
ntpdate whenever you want is a bit rude compared with running a proper
ntp server that uses a pool of stratum 2 servers to coordinate when it
synchronizes. i.e., ntp, once setup, is nice and easy on upstream servers.