Red Hat Bugzilla – Full Text Bug Listing
|Summary:||sudo service libvirtd start from pts/n causes starting vms to fail if pts/n has only existed once (?)|
|Product:||[Fedora] Fedora||Reporter:||Jón Fairbairn <jon.fairbairn>|
|Component:||libvirt||Assignee:||Daniel Veillard <veillard>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||11||CC:||berrange, clalance, crobinso, itamar, markmc, veillard, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-20 14:32:49 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jón Fairbairn 2009-08-01 07:49:12 EDT
Description of problem: If libvirtd is started from a shell on a pseudo tty pts/n, the resulting process retains an affinity for that pseudo tty. Result is that if the pty doesn't exist the first time virt-manager tries to start a vm, it fails complaining about char device redirected to pts/n Version-Release number of selected component (if applicable): libvirt-0.6.2-13.fc11.x86_64 How reproducible: With difficulty Steps to Reproduce: 1. make sure libvirtd is has not run from boot 2. ssh to the machine and make sure it's a pts that hasn't been used before 3. sudo service libvirtd start in that ssh 4. close the ssh 5. try using virt-manager to start a vm Actual results: Error about char device redirected to pts/n Expected results: virtual machine should start Additional info: I can't reproduce this reliably; I was chasing after a different bug that I think is to do with selinux when I hit this one and thought it was not selinux after all (both bugs can bite at once, it seems). Certainly, this bug disappears if the same pts is created again, even if it doesn't exist during the attempt to start the vm, and I haven't managed to reproduce it more than once after any given boot. I shall try again to produce the selinux problem I was looking for...
Comment 1 Mark McLoughlin 2009-08-11 13:28:54 EDT
(In reply to comment #0) > Actual results: > Error about char device redirected to pts/n In F-11, libvirt returns an error like that if it fails to startup qemu because qemu always prints this on startup e.g. char device redirected to /dev/pts/20 char device redirected to /dev/pts/21 if you can reproduce, please try and gather as much info as possible from /var/log/libvirt/qemu/%guest.log and ~/.virt-manager/virt-manager.log etc. See: http://fedoraproject.org/wiki/Reporting_virtualization_bugs
Comment 2 Jón Fairbairn 2009-08-19 05:42:54 EDT
Created attachment 357907 [details] ~/.virt-manager/virt-manager.log for a failed start I managed to trigger this again this morning. Here's the virt-manager.log.
Comment 3 Jón Fairbairn 2009-08-19 05:43:41 EDT
Created attachment 357908 [details] Content of message box on failure
Comment 4 Jón Fairbairn 2009-08-19 05:50:18 EDT
Created attachment 357909 [details] log for the particular machine, spanning the failure The failed session is not the last one (I tried to trigger the bug again, but the machine started fine) I still can't work out how provoke this reliably.
Comment 5 Daniel Berrange 2009-08-19 05:59:45 EDT
Can you paste in your /etc/fstab entry for 'devpts', and also the /proc/mounts line for devpts.
Comment 6 Jón Fairbairn 2009-08-19 06:07:40 EDT
$ egrep pts /etc/fstab devpts /dev/pts devpts gid=5,mode=620 0 0 $ egrep pts /proc/mounts devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 I changed the fstab line to the above because of bug #515521 (I had hoped it would also solve this problem, but the failure for which I attached the logs above happened with the new mode).
Comment 7 Mark McLoughlin 2009-08-19 06:52:05 EDT
Jon: the error message libvirt is returning isn't very helpful, could you try and reproduce using this build of libvirt: http://koji.fedoraproject.org/koji/taskinfo?taskID=1614160 hopefully that should give us a much better error message The patch included in the build is this: http://gitorious.org/~markmc/libvirt/fedora/commit/1319852c44
Comment 8 Mark McLoughlin 2009-11-20 14:32:49 EST
No response to needinfo since 2009-08-19, closing