Hi Cam,
On our hosts, 4 physical interfaces and then a bunch of bonds and
bridges taking total up to 12 entries in /etc/network/interfaces . So
contention certainly seems plausible?
My guests have actually gone back to working normally, so I likely have
mis-attributed an unrelated problem that
Nathan: How many interfaces or IP's are you bringing up? That error
message makes it sound like there could be a lot of contention on the
lock. Could you also get the output of `pstree | grep -B3 lockfile`
while a VM is coming up? (You'll need to attach to a free virtual
terminal using the kvm
This fix is causing problems on Ubuntu 12.04 for me; for both KVM hosts
and KVM guests. I see a message like
lockfile creation failed: exceeded maximum number of lock attempts
On my hosts, it delays boot finishing for several minutes; while some of
my guests just never become network accessible.
This bug was fixed in the package ntp - 1:4.2.6.p3+dfsg-1ubuntu3.8
---
ntp (1:4.2.6.p3+dfsg-1ubuntu3.8) precise; urgency=medium
* Use a single lockfile again - instead unlock the file before starting the
init script. The lock sho uld be shared - both services can't run at the
This bug was fixed in the package ntp - 1:4.2.6.p5+dfsg-3ubuntu2.14.04.7
---
ntp (1:4.2.6.p5+dfsg-3ubuntu2.14.04.7) trusty; urgency=medium
* Use a single lockfile again - instead unlock the file before starting the
init script. The lock sho uld be shared - both services can't
I can confirm I've been running this in production and have not seen any
further issues.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
Hello Thomas, or anyone else affected,
Accepted ntp into trusty-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/ntp/1:4.2.6.p5+dfsg-
3ubuntu2.14.04.7 in a few hours, and then in the -proposed repository.
Please help us by testing this new package.
Uploaded both now, thanks again!
** Changed in: ntp (Ubuntu Precise)
Status: Triaged => In Progress
** Changed in: ntp (Ubuntu Trusty)
Status: Triaged => In Progress
** Changed in: ntp (Ubuntu Precise)
Assignee: (unassigned) => Cam Cope (ccope)
** Changed in: ntp (Ubuntu
** Changed in: ntp (Ubuntu Precise)
Status: New => Triaged
** Changed in: ntp (Ubuntu Trusty)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1125726
Thanks Cam, I'm going to upload this to Xenial.
If you want this to be uploaded to a stable release, please provide the
required information (QA information, regression potential, etc) from
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
--
You received this bug notification because you
This bug was fixed in the package ntp - 1:4.2.6.p5+dfsg-3ubuntu9
---
ntp (1:4.2.6.p5+dfsg-3ubuntu9) xenial; urgency=medium
[ Cam Cope ]
* Use a single lockfile again - instead unlock the file before starting the
init script. The lock sho uld be shared - both services can't
** Description changed:
- We're seeing a race between if-up.d/ntpdate and the ntp startup script.
+ [Impact]
+ * Hardware clocks are not stepped at boot, which can prevent NTP from ever
+ syncing the clock.
+ Incorrect clocks can cause serious issues in distributed systems.
- 1)
** Also affects: ntp (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: ntp (Ubuntu Trusty)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
** Changed in: ntp (Ubuntu Precise)
Importance: Undecided => Medium
** Changed in: ntp (Ubuntu Trusty)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
** Changed in: ntp (Ubuntu)
Importance: Low => Medium
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1125726
Title:
boot-time race between /etc/network/if-up.d/ntpdate and
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1125726
Title:
boot-time race between /etc/network/if-up.d/ntpdate and
"/etc/init.d/ntp start"
To manage
In case it wasn't clear, my patch is supposed to be for the
debian/ntpdate.if-up file. Also, I think the priority of this bug should
be higher, it was assigned 'low' when there was no clear problem caused
by the race. Systems booting with uncorrectable clock skew can be a
serious problem.
--
You
The fix for 246203 was wrong: http://bazaar.launchpad.net/~ubuntu-
branches/ubuntu/karmic/ntp/karmic/revision/23
The issue is that the ntp init script is started inside the ntpdate ifup
script BEFORE the lock file is unlocked. That init script then blocks
because the lock is taken. The correct
See also
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/288905
where I said:
The way I read man ntpd (on Debian wheezy), we could (should?) replace
ntpdate by
ntpd -q; and if we are going to run ntpd then ntpdate is unnecessary anyway.
If we have (or are going to have) ntpd, then we
** Changed in: ntp (Ubuntu)
Importance: Undecided = Low
** Changed in: ntp (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1125726
Title:
Is there any danger of the rc2.d restarting ntp before if-up.d/ntpdate
script gets done starting ntpdate, causing ntpdate to fail?
Since we know that if-up.d/ntpdate will eventually start ntp, we could
define a transient 'ntp-will-start' upstart job. Have if-up.d/ntpdate
start ntp-will-start,
Thanks Thomas.
I'm not sure what to do with this bug now though. Do you think you could
distil your problem down to a failure case that applies generally? Or
should we just leave this bug as a wishlist item to improve the
ntp/ntpdate interaction? I guess the latter would need to be forwarded
to
Thanks Thomas.
It looks like this exists in the Ubuntu delta only, introduced in the
fix for bug 246203. If we used the same lock file, I think we'd get a
deadlock again.
Is there a specific operational problem here? The current arrangement
does seem messy, but I'm reluctant to touch it if it
We're seeing a possibly related problem on first boot, with more painful
consequences. Our install process does a puppet run in the late_command,
and then a reboot, and then another puppet run happens on boot.
In that first boot to the installed system, we're seeing ntp start once
and fail,
In addition, /etc/dhcp/dhclient-exit-hooks.d/ntp is *also* getting in on
the act, doing an ntp restart when it sees ntp service information from
the DHCP server.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in Ubuntu.
25 matches
Mail list logo
