[Bug 1894407] Re: linux-tools: can perf be linked against libbfd, maybe statically?
(Actually, I'm frustrated enough I'm just going to say it explicitly, rather than indirectly: it looks like you didn't read my comment, as even the thrust of your response--that "it's not just about installing different versions of linux-tools"--isn't something I even hinted at as the reason; the most charitable explanation is that you took "parallel installations of this library" to somehow mean linux-tools and not libbfd, but that explanation doesn't help that you then try to inform me of a policy I explained, seem to have the policy wrong, and then didn't respond to any of the other points I made.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894407 Title: linux-tools: can perf be linked against libbfd, maybe statically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1894407] Re: linux-tools: can perf be linked against libbfd, maybe statically?
I not only understood that but explicitly stated as such; not just the reasoning, but also the policy... however, that only applies to dynamic linking: other packages--as I also explicitly demonstrated--link against libbfd statically for this very reason; are you saying that there has been a misunderstanding of the policy and they are out of compliance, and that I should file a bug against them--for example, oprofile--citing that "Seth Forshee has stated this package must not be linking against libbfd"? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894407 Title: linux-tools: can perf be linked against libbfd, maybe statically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1894407] Re: linux-tools: can perf be linked against libbfd, maybe statically?
I am leaving a comment to the effect that my issue is not something for which logs are relevant. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894407 Title: linux-tools: can perf be linked against libbfd, maybe statically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1894407] [NEW] linux-tools: can perf be linked against libbfd, maybe statically?
Public bug reported: The perf tool has an optional dependency on libbfd. Per Debian policy, and due to some situation involving parallel installations of this library, no packages should link dynamically against libbfd. In the past, bugs have been filed to link perf statically against libbfd in bug 783660 (from 2011) and then to just not link against it at all in bug 1748922 (from 2018) and bug 1828234 (from 2019). The argument was made that perf does not need this dependency, as perf can use libiberty as an alternative to demangle C++ names. However, that is not the only thing perf is using libbfd for: the other is to implement an inlined version of addr2line. This was part of an important patchset from 2013 that strove to improve the performance of perf. In my case, I ran my program for all of 30 seconds, generating a 163M large trace, and have been waiting almost an hour for the events to process... and it is only a third of the way done; what I see it doing is spawning, over and over and over again, addr2line, which it wouldn't do if linked against libbfd. https://lore.kernel.org/patchwork/patch/413455/ Is it possible to link perf statically against libbfd, in order to let it use the in-process implementation of addr2line? That is the solution that I've understood for other packages, such as oprofile in bug 426614 and bug 588033. Doing a quick grep of the code of perf for HAVE_LIBBFD_SUPPORT, it seems like bpf disassembly support is also dependent on libbfd (and so while it is great that Ubuntu's build of perf has been compiled against libbpf, it seems like that functionality is being hampered by the lack of linking libbfd). ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894407 Title: linux-tools: can perf be linked against libbfd, maybe statically? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1253209] [NEW] libbenchmark-timer-perl should depend on Statistics::PointEstimation
Public bug reported: Using code from the documentation for libbenchmark-timer-perl causes an error finding Statistics::PointEstimation (which I do not believe has even been packaged for Ubuntu). # perl -e 'use Benchmark::Timer; my $t = Benchmark::Timer-new(skip = 1, confidence = 97.5, error = 2);' Could not load the Statistics::PointEstimation module at -e line 1 ** Affects: libbenchmark-timer-perl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1253209 Title: libbenchmark-timer-perl should depend on Statistics::PointEstimation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libbenchmark-timer-perl/+bug/1253209/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1247013] [NEW] mod_python APLOG_NOERRNO unable to log on Apache 2.4
Public bug reported: When an error occurs from mod_python on Saucy (which uses Apache 2.4) there is nothing logged. I have tracked this issue down to the value of APLOG_NOERRNO being incorrect. This value is defined to be (APLOG_LEVELMASK + 1); on Apache 2.2, APLOG_LEVELMASK was 7, but on Apache 2.4 it is 15. The value in mod_python's Python code (which sadly can't use the C definition in a direct manner) is hardcoded as 8, but for Apache 2.4 it needs to be updated to 16. This variable is defined in lib/python/mod_python/apache.py, and should be an easy fix. (FWIW, I have not experienced other issues so far with the mod_python 3.3.1 patches for Apache 2.4.) (Also, I will note that the 3.4 and now 3.5 of mod_python from upstream no longer even have this variable: it still exists for backwards-compatibility with old code, but it is defined as 0.) ** Affects: libapache2-mod-python (Ubuntu) Importance: Undecided Status: New ** Patch added: patch to fix this issue against 3.3.1 https://bugs.launchpad.net/bugs/1247013/+attachment/3897448/+files/aplog_noerrno.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libapache2-mod-python in Ubuntu. https://bugs.launchpad.net/bugs/1247013 Title: mod_python APLOG_NOERRNO unable to log on Apache 2.4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/1247013/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1247013] [NEW] mod_python APLOG_NOERRNO unable to log on Apache 2.4
Public bug reported: When an error occurs from mod_python on Saucy (which uses Apache 2.4) there is nothing logged. I have tracked this issue down to the value of APLOG_NOERRNO being incorrect. This value is defined to be (APLOG_LEVELMASK + 1); on Apache 2.2, APLOG_LEVELMASK was 7, but on Apache 2.4 it is 15. The value in mod_python's Python code (which sadly can't use the C definition in a direct manner) is hardcoded as 8, but for Apache 2.4 it needs to be updated to 16. This variable is defined in lib/python/mod_python/apache.py, and should be an easy fix. (FWIW, I have not experienced other issues so far with the mod_python 3.3.1 patches for Apache 2.4.) (Also, I will note that the 3.4 and now 3.5 of mod_python from upstream no longer even have this variable: it still exists for backwards-compatibility with old code, but it is defined as 0.) ** Affects: libapache2-mod-python (Ubuntu) Importance: Undecided Status: New ** Patch added: patch to fix this issue against 3.3.1 https://bugs.launchpad.net/bugs/1247013/+attachment/3897448/+files/aplog_noerrno.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1247013 Title: mod_python APLOG_NOERRNO unable to log on Apache 2.4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-python/+bug/1247013/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Other people experiencing this issue may want to explicitly note the comment on this bug from Stefan (which is now somewhat buried) regarding the potential Xen IRQ misconfiguration in these kernels, and attempt that fix. Unfortunately, my test case is run my business on this system for a day and wait for my website to go offline and millions of users to complain ;P. However, for what it is worth, I do not believe the current 2.6.37 kernel from Natty (2.6.37-12.26) experiences this issue. I was building a new m2.4xlarge database server, which the Maverick kernels do not support correctly (bug 667796), and therefore started experimenting with upgrading just the kernel to Natty (with an APT Pin and all that). As the system seemed stable while building it and I knew the load characteristics would be drastically different on it than my previous web server backends, I decided to go ahead with it. Then, after that worked out for a while, I decided to risk moving all of my web backend boxes (the ones for which I was experiencing this issue) to that kernel as well. So far I've been very happy with the results. To date, I've been forced to use Karmic, with its non-PV-grub kernel, field upgraded to Maverick. The kernels from Lucid were not acceptable (seemingly serious performance regression), and Maverick has been right out (given this horrendous I/O lock-up issue, and the m4.4xlarge 64GB no-go). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/666211 Title: maverick on ec2 64bit ext4 deadlock -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
In case this is saves anyone's time: the top of those stack traces is garbage. Really, all of those processes are simply blocked in the scheduler: the second from the top entry in all the call stacks is a call to schedule() (which I presume is scrambling the registers enough to confuse the stack tracer). -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Yes: I'm just telling you that the ? entries at the top of these stacks are all in the scheduler. jbd2 and run-parts are blocked in io_schedule(), and pgbouncer is blocked in do_get_write_access(). Both of those functions are calling into schedule(), and that's what is actually at the top of the stack. (I disassembled the 2.6.35-22.35-virtual kernel and verified the call points from the non-? second entries down on the stack.) -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
@scott: I have attached a dmesg dump from a system that had failed. ** Attachment added: dmesg log from a system that had gotten hung up https://bugs.launchpad.net/ubuntu/+source/linux/+bug/666211/+attachment/1728897/+files/hung.dmesg -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Stefan, I'm not certain what you mean by something not used in the common images. To be clear, I do not even know how to make my own images. That's not to say I'm not certain I couldn't figure it out very quickly, but I never have as I personally do not think that is a good way of using EC2: I instead boot stock Ubuntu images (ami-688c7801 in this case) and then install packages on them. Currently, I do not any custom software other than my Python web application: everything I install comes from the default Ubuntu repositories. (If required, I can provide the exact set of commands that I manually run to setup one of these EC2 servers. Unfortunately, I have so far been unable to fully automate the bootup of these systems as the server tends to lock up on me while I'm doing the install, but I remember thinking it was an unrelated issue to this one. I will do some testing of the fully automated boot of these servers tonight and see if I can reproduce those lockups again to see if they look at all related.) So if you mean am I making my own AMI that has some kind of modified system software, the answer is definitely not. However, while I think that it is an amazing testament to modern engineering that I can reinstall and reboot computers from a thousand miles away, that is a fairly useless endeavor: the stock images are very stock and don't do anything at all, as far as I know, out of the box. To be putting any kind of load on them at all I'm certainly installing some software on it, even if that software is just a shell script fork bomb. In my particular case, I install apache2 with mod_python and pgbouncer (from Ubuntu universe), a program from Skype that provides a PostgreSQL pooling proxy server. My python application connects to pgbouncer (which is listening on a named Unix socket and pretends to be PostgreSQL) instead of directly to my database server, which then keeps its own pool of connections to the actual database. This makes the 3200 Apache threads that I normally have running able to rapidly get a database connection without trying to coordinate local in-process pools. Put differently: pgbouncer should be a fairly boring user-land process. If you are looking at it thinking it is some kind of cool kernel task that increases network security (maybe bouncing bad clients) or something, it (maybe sadly ;P) isn't. This software is actually the least popular (but I personally feel best ;P) choice in PostgreSQL pooling proxy servers, an already fairly narrow niche; therefore, I would find it highly unlikely if Timo was also using it, but maybe he will chime in with a yeah! pgbouncer is AWESOME! and prove me wrong. -J -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Stefan, To be clear, both Timo and I were using m1.xlarge instances, which are supposed to have four cores. (You mentioned the hardware you were testing on only had two cores, and therefore you weren't getting the same seemingly-bad and probably-should-be-fixed error messages.) Also, that log was saved from two weeks ago when I was running into this issue: the difference in Xen version could theoretically then be that Amazon has upgraded their system since then. (I have no idea if that even makes sense, but I figure I'll throw it out there as a possibility.) -J -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Stefan, These stack traces for pgbouncer are all in sys_write(), btw, which is then backed by ext4. Both from what I know about how pgbouncer operates, and from greping through its source code, the only file-backed operation it performs is writing to its log file, which it normally does only once a minute unless it is encountering some kind of connection failures. It looked (and still looks) to me like the filesystem is simply locking up. It should be noted that my dmesg log also includes another process that got stuck: run-parts, which got blocked in a call to sys_getdents(). Also, I looked into the AIO completion ordering change you mentioned, and it seems totally unrelated. The author of this patch referred to a reproduction of the bug they were fixing, which was a you now read a bunch of zeros when you were expecting data race condition, not a deadlock. In specific, operations involving unwritten extents would claim to be completed via AIO when they were still pending: the reordering fixed this. http://www.spinics.net/lists/linux-ext4/msg19590.html http://thread.gmane.org/gmane.comp.file-systems.ext4/19659 -J -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
We are also getting the following error message from the kernel: JBD: barrier-based sync failed on sda1-8 - disabling barriers My theory was that this has to do with the root partition being used as ext4. I do not know much about bundling of AMIs: is this something that is easy for you to change/test with your rebundled AMIs? -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 666211] Re: maverick on ec2 64bit ext4 deadlock
Somehow I thought I said this in the last comment, but I see that I didn't: using the instance's normal root partition, not an EBS root boot. -- maverick on ec2 64bit ext4 deadlock https://bugs.launchpad.net/bugs/666211 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
