| Summary: | sys-devel/gcc-4.6.3: hangs in pkg_postinst when using autofs | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Juergen Rose <rose> |
| Component: | Core | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | kripton |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
/var/db/pkg/sys-devel/gcc-4.6.3/environment.bz2
debug.log |
||
|
Description
Juergen Rose
2013-01-24 13:29:42 UTC
Try using `lsof | grep portage_lockfile` to identify the process that's locking it. The process may be an orphan that you need to kill. Even after reboot the issue does not disappear. 'emerge -v1 gcc' hangs again and 'lsof' shows only two emerge processes, accessing /var/db/.pkg-ebuild.portage_lockfile:
root@impala:/root(12)# emerge -pvuND world
These are the packages that would be merged, in order:
Calculating dependencies * waiting for lock on /var/db/.pkg.portage_lockfile
...... done!
Exiting on signal 2
root@impala:/root(13)# lsof | grep portage_lockfile
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /home_impala/rose/.gvfs
Output information may be incomplete.
emerge 8585 root 8uW REG 253,1 0 101409 /var/db/.pkg-ebuild.portage_lockfile
emerge 31111 root 5uW REG 253,2 0 66431420 /var/tmp/portage/sys-devel/.gcc-4.6.3.portage_lockfile
emerge 31111 root 11uW REG 253,1 0 98330 /var/db/.pkg.portage_lockfile
root@impala:/root(14)# ps uwax | grep emerge | grep -v grep
root 8585 0.0 3.1 382068 253644 pts/0 S+ Jan24 0:09 /usr/bin/python2.7 /usr/bin/emerge -v1 gcc
root 31111 0.1 2.9 359788 237992 pts/0 S+ Jan24 0:41 /usr/bin/python2.7 /usr/bin/emerge -v1 gcc
The lock on /var/db/.pkg-ebuild.portage_lockfile shows that it's running an ebuild phase, so I guess your problem is that the ebuild phase is hanging for some reason. We need to find out which ebuild phase it is and where it's hanging inside that phase. You can use pstree or ps --forest to see if there's a hung subprocess that it's waiting for. The ebuild phase is a bash process, and we're interested any subprocesses of it. Some reboots, some 'emerge -uvDN --kep-going world' and 'revdep-rebuild -- --keep-going' world later 'emerge -v1 gcc' still hangs at the same point. In a second terminal I see: root@impala:/root(42)# ps waux | grep emerge | grep -v grep root 7535 0.2 2.9 354620 238768 pts/0 S+ 08:01 0:41 /usr/bin/python2.7 /usr/bin/emerge -v1 gcc root 16241 0.0 3.1 380988 258352 pts/0 S+ 08:39 0:09 /usr/bin/python2.7 /usr/bin/emerge -v1 gcc root@impala:/root(43)# ps waux | grep ebuild | grep -v grep root 16385 0.0 0.0 22464 4044 pts/0 S+ 08:40 0:00 /bin/bash /usr/lib64/portage/bin/ebuild.sh postinst root 16397 0.0 0.0 22616 3712 pts/0 S+ 08:40 0:00 /bin/bash /usr/lib64/portage/bin/ebuild.sh postinst root@impala:/root(44)# ps waux | grep bash | grep -v grep rose 3502 0.0 0.0 28772 4764 pts/3 Ss+ Jan27 0:00 bash -l root 16385 0.0 0.0 22464 4044 pts/0 S+ 08:40 0:00 /bin/bash /usr/lib64/portage/bin/ebuild.sh postinst root 16397 0.0 0.0 22616 3712 pts/0 S+ 08:40 0:00 /bin/bash /usr/lib64/portage/bin/ebuild.sh postinst root 27129 0.0 0.0 28640 4696 tty1 S+ Jan27 0:00 -bash root@impala:/root(45)# pstree -p 7535 emerge(7535)───emerge(16241)───ebuild.sh(16385)───ebuild.sh(16397) Which additional information I could still provide? It looks like it's hanging in the pkg_postinst phase. Go ahead and kill it, then run that postinst phase alone with --debug, like this: ebuild /var/db/pkg/sys-devel/gcc-4.6.3/gcc-4.6.3.ebuild postinst --debug &>debug.log Also, please attach /var/db/pkg/sys-devel/gcc-4.6.3/environment.bz2. Created attachment 337486 [details]
/var/db/pkg/sys-devel/gcc-4.6.3/environment.bz2
I just did 'ebuild /var/db/pkg/sys-devel/gcc-4.6.3/gcc-4.6.3.ebuild postinst --debug &>debug.log', which also hangs at: ... + echo ' * http://www.gentoo.org/doc/en/gcc-upgrading.xml' * http://www.gentoo.org/doc/en/gcc-upgrading.xml + read -r + LAST_E_CMD=ewarn + return 0 + echo + is_crosscompile + [[ x86_64-pc-linux-gnu != x86_64-pc-linux-gnu ]] I will attach the complete debug.log. Created attachment 337498 [details]
debug.log
Now I have the same issue with gcc-4.7.2-r1 on an other system. 'emerge -uvDN world' hangs at: * gcc-config x86_64-pc-linux-gnu-4.7.2 * source /etc/profile * Switching native-compiler to x86_64-pc-linux-gnu-4.6.3 ...>>> Regenerating /etc/ld.so.cache... [ ok ] * If you have issues with packages unable to locate libstdc++.la, * then try running 'fix_libtool_files.sh' on the old gcc versions. * You might want to review the GCC upgrade guide when moving between * major versions (like 4.2 to 4.3): * http://www.gentoo.org/doc/en/gcc-upgrading.xml 'genlop -c' in an other windows shows that there is no running merge: rose@caiman:/home/rose(8)$ genlop -c !!! Error: no working merge found. (the -c option only works if there is an ongoing compilation, see manpage) 'lsof' and 'ps -ef | grep emerge' do not show something interesting: rose@caiman:/home/rose(9)$ lsof | grep portage_lockfile rose@caiman:/home/rose(10)$ ps -ef | grep emerge | grep -v grep root 25953 4246 0 09:55 pts/3 00:01:06 /usr/bin/python2.7 /usr/bin/emerge -vuND --resume --skipfirst world root 27284 25953 0 10:38 pts/3 00:00:04 /usr/bin/python2.7 /usr/bin/emerge -vuND --resume --skipfirst world Maybe it is due to autofs problems, after restarting autofs it works. |
