Community Packages

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!
Tasklist

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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

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
Comment by KaiSforza (KaiSforza) - Saturday, 09 March 2013, 04:05 GMT
Edit /etc/libvirt/qemu.conf. Its in the 'post_upgrade. Honestly, the post_install should call the post_upgrade so new installs know too.
Comment by Csaba Henk (csheemea) - Saturday, 09 March 2013, 08:13 GMT
I've seen that message as many times as I experimented with the various versions
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...
Comment by Csaba Henk (csheemea) - Wednesday, 13 March 2013, 01:42 GMT
I wrote to libvir@, conclusion is:

- 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.

Loading...