As posted in juju-dev last night:
Okay, I couldn't resist investigating a bit. I've been looking at the
database dump from earlier today and it's smelling like a simpler bug
in the txn package, and I might have found the cause already.
Here is a quick walkthrough while debugging the problem, to
Alright, the guess last night was correct, and the candidate fix as
well. I've managed to reproduce the problem by stressing out the
scenario described with 4 concurrent runners running the following two
operations, meanwhile the chaos mechanism injects random slowdowns in
various critical points:
This error should never happen on a healthy database. The only case I've
debugged with such an issue was on a system that had a corrupted
database due to an out-of-space situation.
The reason why this should never happen is clear in the code of the txn
package: before anything is ever done with
@John, it's definitely a bad idea to have transactions in a capped
collection for that sort of reason, but as far as I can see the _txns_
collection, the one holding the transactions themselves, is not capped.
Having missing logs for a transaction would not cause this issue.
--
You received this
Looking at the logs from Adam that Nate forwarded to me, I can see the
database is being terminated and restarted over and over and over, every
few seconds. Looking at logs around it, looks like at least rsyslogd is
also being re-freshed on the same cadence.
By itself, this should not be an
Sorry, it's late here..
neither the Go community nor the Go core development team (most
important in this case) is not hostile to dynamic linking.
This should read:
note that neither the Go community nor the Go core development team
(most important in this case) are hostile to dynamic
We've had extensive conversations on this topic elsewhere, and these
were pretty much entirely covered in Jamie's comment #27, which does an
excellent job describing the various perspectives for the same problems.
Thanks for that Jamie.
Just a couple of points that might be useful to add:
I don't feel like this is a huge issue, but please note that if this is
changed, the message should only be touched in the very specific case
where juju is executed without any other arguments. It is really an
error to interrupt whatever juju was going to do and stop to print that
message.
--
That's awesome, thanks Peter.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in ubuntu.
https://bugs.launchpad.net/bugs/721801
Title:
llseek bug in amd64 host
--
Ubuntu-server-bugs mailing list
Public bug reported:
Binary package hint: qemu-kvm
It's been reported in the Go mailing list that lseek is failing on an
amd64 host when emulating arm.
The attached patch was recommended as a possible fix for the problem.
The full conversation may found in the following thread:
** Patch added: Patch suggested in the list to fix the problem
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/721801/+attachment/1859926/+files/x86-64-llseek.patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm
** Description changed:
Binary package hint: qemu-kvm
- It's been reported in the Go mailing list that lseek is failing on an
+ It's been reported in the Go mailing list that llseek is failing on an
amd64 host when emulating arm.
The attached patch was recommended as a possible fix
** Summary changed:
- lseek bug in amd64 host
+ llseek bug in amd64 host
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in ubuntu.
https://bugs.launchpad.net/bugs/721801
Title:
llseek bug in amd64 host
--
There are packages available for testing in my PPA:
sudo add-apt-repository ppa:niemeyer/ppa
sudo apt-get upgrade
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in ubuntu.
https://bugs.launchpad.net/bugs/721801
Title:
** Changed in: image-store-proxy (Ubuntu Maverick)
Assignee: Gustavo Niemeyer (niemeyer) = (unassigned)
--
image-store does not support images without a ramdisk
https://bugs.launchpad.net/bugs/572317
You received this bug notification because you are a member of Ubuntu
Server Team, which
I have discussed this with Scott over the phone a while ago, but didn't
write anything in the bug about it. Sorry about that.
So here are the possible outcomes with this bug:
1) I fix the problem myself
2) I guide someone else to fixing the problem
3) The feature is removed from the Image Store
Oh, there's another one which I missed:
5) Provide a ramdisk and kernel to images installed via the store.
This would be pretty easy from an Image Store perspective, of course.
--
image-store does not support images without a ramdisk
https://bugs.launchpad.net/bugs/572317
You received this bug
I'm attaching an Eucalyptus patch which implements the following
changes:
- New services tab, with links to Canonical services
- New Landscape registration option in the services tab
- Moved Rightscale registration option to right after the Landscape one (was
under Credentials).
- Fixed the size
Martin,
Please rest assured I understand very well all of the consequences of
using one approach or the other, and opt to use one or the other
depending on specific needs. In fact, if you look through the code
you'll see that in some cases subprocess was used.
In the case at hand I could very
No, this is not a security issue. localPath is based on the sha256,
which is checked right above for validity.
--
[FFE] Image Store Proxy must handle compressed images
https://bugs.launchpad.net/bugs/445714
You received this bug notification because you are a member of Ubuntu
Server Team, which
Scott Moser pointed out that he wants to use .tar.gz on the published
images, because using the --sparse option of tar greatly reduces the
size of the resulting file in comparison to plain gzip, so I went ahead
and added support for .tar.gz on the image store proxy too, in addition
to .gz.
This
Oh, again, this was all unittested, and manually tested using the fake
store api.
--
[FFE] Image Store Proxy must handle compressed images
https://bugs.launchpad.net/bugs/445714
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Public bug reported:
Registering a walrus on localhost fails with an internal error message:
$ sudo euca_conf --register-walrus localhost
Adding WALRUS host localhost
Internal Error.
ERROR: failed to register Walrus, please log in to the admin interface and
check cloud status.
This was done
** Attachment added: eucalyptus-logs.tar.bz2
http://launchpadlibrarian.net/32747582/eucalyptus-logs.tar.bz2
--
Internal error registering local walrus
https://bugs.launchpad.net/bugs/439364
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
*** This bug is a duplicate of bug 436885 ***
https://bugs.launchpad.net/bugs/436885
From the description of bug #436885, this doesn't feel like a duplicate
at least, since the deadlock condition wasn't following any significant
usage. But then, the other bug is quite short on details, so
Public bug reported:
The Image Store Proxy which landed last week through the Feature Freeze
Exception in bug #423865 needs to be updated to version 1.0 so that it
fully works. The 0.9.1 version which landed in alpha 5 still missed
some features like signature checking.
** Affects: eucalyptus
It does. It should just display a message saying that the proxy is not
available.
That said, considering it has so few dependencies by itself, it'd be
good to have the Eucalyptus package depending on the Image Store Proxy
package, so that people will benefit from the service without having to
Public bug reported:
Eucalyptus is hanging during an euca-upload-bundle and the command euca-
upload-bundle doesn't return.
The ps output:
112 8313 0.0 0.3 51496 12340 pts/0S+ 15:16 0:00 python
/usr/bin/euca-upload-bundle --manifest
Oops.. sorry for missing the package.
Btw, this was with 1.6~bzr645-0ubuntu2.
--
Eucalyptus cloud controller stops working suddenly
https://bugs.launchpad.net/bugs/428010
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in
Potentially some times, but signals seems to be working fine now, and it
happened to me today again.
--
Eucalyptus cloud controller stops working suddenly
https://bugs.launchpad.net/bugs/428010
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
I'm attaching my cloud-ouput.log file. grep -i corrupt there doesn't
find anything, but there are several other errors.
** Attachment added: cloud-output.log
http://launchpadlibrarian.net/31664702/cloud-output.log
--
Eucalyptus cloud controller stops working suddenly
Public bug reported:
Eucalyptus is returning a 500 error when trying to register a ramdisk
image:
Command 'euca-register' returned status code 1:
Warning: failed to parse error message from AWS: unknown:1:0: syntax error
BotoServerError: 500 Internal Server Error
Failure: 500 Internal Server
32 matches
Mail list logo
