Package: ntpdate
Version: 1:4.2.6.p5+dfsg-3.1
Followup-For: Bug #484974
Dear Maintainer,
I also think this is a problem, specially on hosts with a lot of alias
interfaces.
This may possibly be related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647465
and
On Tue, Sep 02, 2014 at 11:10:03AM -0600, David Mohr wrote:
I also think this is a problem, specially on hosts with a lot of alias
interfaces.
I would like to point out that it's been possible to add multiple
IPs to a single interfance for a very long time now, but I'm not
sure the interfaces
The main problem is with tap or tun interfaces related with virtual
machines on Xen hosts.
It this triggers a time sync on dom0. This can cause a time leap on all
VMs (and it can cause great problems with databases if it's a leap
backwards)
Le 02/09/2014 20:12, Kurt Roeckx a écrit :
I would
(Please note that mailing nnn@bugs doesn't reach the bug submitter.
I only saw this after a manual lookup.)
On Wed, Jun 18, 2008 at 10:18:24PM -0400, Steve Kostecke wrote:
Peter Eisentraut said:
What are you using ntpdate for?
A better question is why are you using ntpdate at all?
Josip Rodin said:
On Wed, Jun 18, 2008 at 10:18:24PM -0400, Steve Kostecke wrote:
A better question is why are you using ntpdate at all?
[snip]
I answered this earlier, but here goes one more time: I use ntpdate for its
exact simplest purpose - setting the clock ad hoc from a specified NTP
On Mon, Jul 14, 2008 at 08:58:32AM -0400, Steve Kostecke wrote:
I answered this earlier, but here goes one more time: I use ntpdate for its
exact simplest purpose - setting the clock ad hoc from a specified NTP
server. The machine doesn't have ntpd installed, and I either don't want
it at all,
Peter Eisentraut said:
What are you using ntpdate for?
A better question is why are you using ntpdate at all?
Besides the diagnostics that ntpdate can produce, the only advantage
ntpdate has over ntpd is that ntpdate can use an unpriviledged source
port and ntpd currently can not.
ntpd can
Am Montag, 16. Juni 2008 schrieb Josip Rodin:
I don't want to have to go rm the conffile or remove the package on N
machines just because of whatever happens on the some random desktop...
Desktop users might say the opposite. I think you are just going to have to
live with the default
On Mon, Jun 16, 2008 at 11:21:08AM +0200, Peter Eisentraut wrote:
Am Montag, 16. Juni 2008 schrieb Josip Rodin:
I don't want to have to go rm the conffile or remove the package on N
machines just because of whatever happens on the some random desktop...
Desktop users might say the
Josip Rodin wrote:
/etc/network/if-up.d/ntpdate runs even if you bring up a virtual interface
like eth0:5; I don't see any reason why it should ever do that.
Unless you can provide a concrete reason why the current behavior is really
harmful, I am hesitant to add more special rules based on
On Mon, Jun 16, 2008 at 12:10:59AM +0200, Peter Eisentraut wrote:
Josip Rodin wrote:
/etc/network/if-up.d/ntpdate runs even if you bring up a virtual interface
like eth0:5; I don't see any reason why it should ever do that.
Unless you can provide a concrete reason why the current behavior
Josip Rodin wrote:
So, where is the demand for ntpdate to be run on eth* interfaces? All I see
is people asking for it with PPP connections (typically, dialups and/or
desktops). Why aren't we doing this for ppp interfaces only?
It seemed like a useful generalization. PPP use has declined much
On Mon, Jun 16, 2008 at 01:43:18AM +0200, Peter Eisentraut wrote:
Josip Rodin wrote:
So, where is the demand for ntpdate to be run on eth* interfaces? All I see
is people asking for it with PPP connections (typically, dialups and/or
desktops). Why aren't we doing this for ppp interfaces
Package: ntpdate
Version: 1:4.2.2.p4+dfsg-2
Hi,
/etc/network/if-up.d/ntpdate runs even if you bring up a virtual interface
like eth0:5; I don't see any reason why it should ever do that.
Please fix this. TIA.
(I see little reason for it to run by default on the bringing up of eth0,
but that's
14 matches
Mail list logo
