Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#34224 - [libvirt] qemu guest dies with 'chardev: opening backend "pty" failed'
Attached to Project:
Community Packages
Opened by Csaba Henk (csheemea) - Saturday, 09 March 2013, 03:45 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 04 June 2013, 13:16 GMT
Opened by Csaba Henk (csheemea) - Saturday, 09 March 2013, 03:45 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 04 June 2013, 13:16 GMT
|
DetailsDescription:
Trying to start a qemu/kvm guest () it immediately fails with following message: error: Failed to start domain <guest> error: internal error process exited while connecting to monitor: chardev: opening backend "pty" failed Additional info: * package version(s): 1.0.3-1rc2 and 1.0.3-2rc2 (newest as of writing this). Older versions (=<1.0.2-3) work fine. Steps to reproduce: Basically, just start the libvirtd service and do a virsh start <guest> for some existing guest; but any fronted (virt-manager, virt-inst) reproduces the issue. My observations: the following are irrelevant: - whether systemd or sysvinit is used - whether qemu or qemu-kvm is used - cgroup tunings The scenario is: qemu (ran as nobody) tries to set up a pseudo-terminal. It calls openpty(), which internally invokes a setuid helper, pt_chown. pt_chown is expected to make the ptmx-asssinged new pty owned by the caller. However, the respective chown(2) call fails with EPERM, despite the 0 effective uid. It might be something with capabilities... see the /proc/<pid>/status file of such a pt_chown proccess attached. (Nb. when su-ing to "nobody" in root shell, there is no problem with pt_chown, it succeeds). |
This task depends upon
Closed by Sergej Pupykin (sergej)
Tuesday, 04 June 2013, 13:16 GMT
Reason for closing: Not a bug
Additional comments about closing: I suggest to put this warning into wiki:
https://wiki.archlinux.org/index.php/Lib virt
Tuesday, 04 June 2013, 13:16 GMT
Reason for closing: Not a bug
Additional comments about closing: I suggest to put this warning into wiki:
https://wiki.archlinux.org/index.php/Lib virt
procstatus.txt
and it seems to be one of the particularly least useful ones, as far as I'm concerned.
For what end should I edit /etc/libvirt/qemu.conf? I don't see any tunable that's
relevant to this problem. I acknowledged that qemu is being ran as "nobody", and,
besides me, it was fine with libvirt 1.0.2* (with the only caveat that "nobody" was
needed to put in kvm group to be able to use kvm -- well, then it might be better to
create a dedicated service user, but I speak of operability not of best practices).
(Also I never had ~/.libvirt so that part seemed weird as well...)
Please tell me if I'm missing something obvious...
- issue was that pt_chown, the setuid helper used by openpty(3), was running with insufficient capabilities
- this is due to a recent adjustment of libvirtd's way of starting qemu
- however, properly mounted devpts (ie, with gid=tty) makes pt_chown unnecessary
Cf. http://thread.gmane.org/gmane.comp.emulators.libvirt/74067/focus=74110
systemd does mount devpts properly in the above sense. However, if someone has a superfluous
fstab entry for devpts which specifies otherwise, systemd adheres to that spec; and historically,
Arch was shipping such a bogus devpts spec, cf.
http://projects.archlinux.org/svntogit/packages.git/commit/?id=5d58f365
so one who is not careful enough about /etc/ maintainance will have that bogus entry.
That was my case too.
I suggest to warn users in post_upgrade to make sure that devpts is mounted with gid=5.