471,316 Members | 1,059 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,316 software developers and data experts.

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

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...
Jul 17 '05 #1
5 4136
On 2003-12-22, Thomas Brathans <th***@t-online.de> wrote:
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.


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
Jul 17 '05 #2
Tim Van Wassenhove wrote:

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.


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?

Jul 17 '05 #3
Thomas Brathans wrote:
Tim Van Wassenhove wrote:
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.

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?

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.

Jul 17 '05 #4
clvrmnky wrote:
Thomas Brathans wrote:
Tim Van Wassenhove wrote:
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.

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?

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.


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.
Jul 17 '05 #5
Thomas Brathans wrote:
clvrmnky wrote:

[...]
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.

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.


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.

Jul 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.