Bug 495830
| Summary: | glibc is not updated cause glibc_post_upgrade.i686 is hang. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Masao Takahashi <masao-takahashi> | ||||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | jakub | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i686 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-04-16 21:08:11 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Masao Takahashi
2009-04-15 01:54:07 UTC
I add a rpm log as follows. D: install: %post(glibc-2.9.90-16.i686) synchronous scriptlet start D: install: %post(glibc-2.9.90-16.i686) execv(/usr/sbin/glibc_post_upgrade.i686) pid 11719 ^CD: install: waitpid(11719) rc 11719 status 2 secs 122.265 error: %post(glibc-2.9.90-16.i686) scriptlet failed, signal 2 An additional info: glibc_post_upgrade.i686 is waiting for completion of ldconfig. ldconfig is hang. Not glibc_post_upgrade. I add a ldconfig log. Created attachment 339785 [details]
ldconfig log
glibc-2.9.90-17.i686 has a same problem. Does ldconfig also hang if you just run it from command line? Can you run top once that happens to see if it consumes CPU time or not? Can you strace it to see what it does last? Can you check dmesg if you don't have say filesystem/disk errors? There haven't been any ldconfig changes since mid 2007... (In reply to comment #5) > Does ldconfig also hang if you just run it from command line? After I invoke glibc_post_upgrade.i686, glibc_post_upgrade.i686 executes ldconfig and waits for it's completion. But ldconfig doesn't complete. > Can you run top once that happens to see if it consumes CPU time or not? It does not consume CPU time. > Can you strace it to see what it does last? Can you check dmesg if you don't I check dmesg. But no erros are found. I did strace. The last was "fuke" , perhaps. > have say filesystem/disk errors? > > There haven't been any ldconfig changes since mid 2007... strace last message: Bad : fuke Correct : futex Can you please attach the full strace dump? Given that ldconfig isn't multithreaded, nor doesn't use process wide synchronization primitives, I highly doubt ldconfig ever does even a single futex call. Created attachment 339813 [details]
a strace log of ldconfig-2.9.90-17
I add a strace log of ldconfig-2.9.90-17.
strace -f ldconfig 2>ldconfig.log
But, glibc-2.9.90-11 is good.
Please run LC_ALL=C ldconfig and see what error it actually attempts to report, the problem is I assume during transcoding of the error message. (In reply to comment #10) > Please run > LC_ALL=C ldconfig > and see what error it actually attempts to report, the problem is I assume > during transcoding of the error message. I did it. ldconfig output is as follows. And ldconfig is completed. You are right. What shall i do? -------------------------------------------------------- ldconfig: /usr/lib/libreadline.so.5 is not a symbolic link ldconfig: /usr/lib/libbz2.so.1 is not a symbolic link ldconfig: /usr/lib/libz.so.1 is not a symbolic link ldconfig: /usr/lib/libpopt.so.0 is not a symbolic link ldconfig: /usr/lib/libneon.so.25 is not a symbolic link ldconfig: /usr/lib/libncurses.so.5 is not a symbolic link ldconfig: /usr/lib/libncursesw.so.5 is not a symbolic link ldconfig: /usr/lib/libparted-1.7.so.1 is not a symbolic link ldconfig: /usr/lib/libwrap.so.0 is not a symbolic link -------------------------------------------------------- Should be fixed in glibc-2.9.90-19. (In reply to comment #12) > Should be fixed in glibc-2.9.90-19. Yes glibc-2.9.90-19 is good. |