Am 06.11.2013 20:52, schrieb Thomas Meyer: > Am Mittwoch, den 06.11.2013, 13:40 +0100 schrieb Richard Weinberger: >> On Tue, Nov 5, 2013 at 9:21 PM, Thomas Meyer <tho...@m3y3r.de> wrote: >>> Hi, >>> >>> I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y" >>> command seems to get stuck after a while/few minutes. >>> >>> Any ideas what's going one here? How to debug this? >>> >>> It looks like the process running yum is in state ptrace stopped, but >>> doesn't continue. >> >> Got only yum stuck or the whole UML kernel? > > How to tell? It feels like the whole kernel got stuck.
Login on another shell... :) >> Does yum a ptrace() within UML or did you observe that from the outside? > > I saw it from outside in below process listing. Okay. All UML childs do ptrace() as UML uses ptrace() for system call emulation. >> >>> The process tree looks also strange: >>> >>> 20330 pts/3 S+ 1:18 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20337 pts/3 S+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20338 pts/3 S+ 0:03 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20339 pts/3 S+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20347 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20405 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20469 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20615 pts/3 S+ 0:00 | \_ xterm -T Virtual Console #1 >>> (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k >>> 20625 ? Ss 0:00 | | \_ port-helper -uml-socket >>> /tmp/xterm-pipeiW6d5k >>> 20626 ? Zs 0:00 | \_ [linux] <defunct> >>> 20630 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20642 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20650 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20651 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20663 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20681 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20684 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20690 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20691 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20699 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20709 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20722 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20754 pts/3 S+ 0:00 | \_ xterm -T Virtual Console #2 >>> (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS >>> 20757 ? Ss 0:00 | | \_ port-helper -uml-socket >>> /tmp/xterm-pipetxRIbS >>> 20755 pts/3 S+ 0:00 | \_ xterm -T Virtual Console #6 >>> (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp >>> 20762 ? Ss 0:00 | | \_ port-helper -uml-socket >>> /tmp/xterm-pipedhXmGp >>> 20758 ? Zs 0:00 | \_ [linux] <defunct> >>> 20760 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20763 ? Zs 0:00 | \_ [linux] <defunct> >>> 20797 pts/3 S+ 0:00 | \_ xterm -T Virtual Console #3 >>> (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd >>> 20812 ? Ss 0:00 | | \_ port-helper -uml-socket >>> /tmp/xterm-pipeULItXd >>> 20813 ? Zs 0:00 | \_ [linux] <defunct> >>> 20815 pts/3 S+ 0:00 | \_ xterm -T Virtual Console #5 >>> (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3 >>> 20876 ? Ss 0:00 | | \_ port-helper -uml-socket >>> /tmp/xterm-pipeaKUbD3 >>> 20877 ? Zs 0:00 | \_ [linux] <defunct> >>> 20896 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 20909 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21005 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21007 pts/3 Z+ 0:00 | \_ [uml_net] <defunct> >>> 21019 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21112 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21125 pts/3 Z+ 0:00 | \_ [uml_net] <defunct> >>> 22164 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22211 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22224 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22380 pts/3 t+ 0:51 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21965 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21968 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 21983 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22053 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22058 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >>> 22887 pts/3 t+ 0:00 | \_ ./linux ubd0=ext3fs.img mem=768M >>> systemd.unit=multi-user.target umid=fedora20 >> >> Remain the tasks in state Z or are they fipping around? > > All process remain in thier state. nothing seems to happen any more. Ok. The it would be nice to find out what the UML main thread does. gdb can tell you. >> Maybe the UML userspace creates many threads and on the host side UML >> didn't call wait() jet... > > I don't think so. yum is probably not a big thread user, I guess. Isn't it a huge chunk of python? ;-) Thanks, //richard ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
