Bug 1750120 - unable to paste/copy between host and guest
Summary: unable to paste/copy between host and guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spice-vdagent
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: PrioritizedBug Triaged https://fedora...
: 1748123 (view as bug list)
Depends On:
Blocks: F31BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2019-09-08 14:56 UTC by lnie
Modified: 2019-09-17 15:27 UTC (History)
20 users (show)

Fixed In Version: spice-vdagent-0.19.0-3.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-17 11:51:07 UTC


Attachments (Terms of Use)
journal from the guest (1.10 MB, text/plain)
2019-09-08 14:56 UTC, lnie
no flags Details


Links
System ID Priority Status Summary Last Updated
freedesktop.org Gitlab spice/linux/vd_agent/merge_requests/2 None None None 2019-09-13 15:09:07 UTC

Description lnie 2019-09-08 14:56:04 UTC
Created attachment 1612829 [details]
journal from the guest

Description of problem:
Do a default installation with Fedora-Workstation-Live-x86_64-31-20190907.n.0.iso,try to copy/paste from guest to host,but failed,vice versa.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jens Petersen 2019-09-10 09:57:48 UTC
Really annoying bug - been seeing it for a while.

Comment 2 Adam Williamson 2019-09-11 00:22:40 UTC
yeah, I've noticed this too but just didn't get around to filing it. *last* time we had this bug it was caused by an SELinux denial: did either of you check if it works with enforcing=0?

Comment 3 Jens Petersen 2019-09-11 03:34:31 UTC
I just tried enforcing=0 with Fedora-Workstation-Live-x86_64-31-20190909.n.0.iso and it didn't help.

Comment 4 Jens Petersen 2019-09-11 09:17:41 UTC
Fedora-KDE-Live-x86_64-31-20190909.n.0.iso seems okay fwiw.

Comment 5 Kamil Páral 2019-09-11 12:12:59 UTC
I believe the correct component is spice-vdagent, changing.

I've tested F31 Workstation and F31 KDE Live images, using F30 Workstation host. In both cases, the spice-vdagentd.service is running OK. But the journal output differs.

F31 KDE:
$ journalctl -u spice-vdagentd
-- Logs begin at Wed 2019-09-11 08:03:27 EDT, end at Wed 2019-09-11 12:03:52 EDT. --
Sep 11 08:03:55 localhost-live systemd[1]: Starting Agent daemon for Spice guests...
Sep 11 08:03:55 localhost-live systemd[1]: spice-vdagentd.service: Can't open PID file /run/spice-vdagentd/spice-vdagentd.pi>
Sep 11 08:03:55 localhost-live systemd[1]: Started Agent daemon for Spice guests.
Sep 11 08:03:56 localhost-live spice-vdagentd[1512]: opening vdagent virtio channel
Sep 11 08:03:56 localhost-live spice-vdagentd[1512]: Set max clipboard: 104857600
Sep 11 08:03:56 localhost-live spice-vdagentd[1512]: Set max clipboard: 104857600

F31 Workstation:
$ journalctl -u spice-vdagentd
-- Logs begin at Wed 2019-09-11 07:57:44 EDT, end at Wed 2019-09-11 11:58:05 EDT. --
Sep 11 11:58:01 localhost-live systemd[1]: Starting Agent daemon for Spice guests...
Sep 11 11:58:01 localhost-live systemd[1]: spice-vdagentd.service: Can't open PID file /run/spice-vdagentd/spice-vdagentd.pid>
Sep 11 11:58:01 localhost-live spice-vdagentd[1620]: Error getting session for pid 1614: No data available
Sep 11 11:58:01 localhost-live systemd[1]: Started Agent daemon for Spice guests.

$ ps aux | grep vdagent
liveuser    1614  0.0  0.0  82960  2408 ?        Ssl  07:58   0:00 /usr/bin/spice-vdagent
root        1620  0.0  0.0   7016   256 ?        Ss   07:58   0:00 /usr/sbin/spice-vdagentd
liveuser    2436  0.0  0.0 216116   828 pts/0    S+   08:08   0:00 grep --color=auto vdagent

$ rpm -q spice-vdagent
spice-vdagent-0.19.0-2.fc31.x86_64

Notice the error in F31 Workstation output:
> Error getting session for pid 1614: No data available

I see the same errors on the installed system. Running `spice-vdagent --foreground` manually doesn't discover any useful output.

Comment 6 Kamil Páral 2019-09-11 12:16:01 UTC
Nominating as a prioritized bug. This is hurting QA performance quite a bit. It will no doubt annoy our users as well.

Comment 7 Adam Williamson 2019-09-11 14:59:17 UTC
Hum. I wonder if this is related to my tty? bug?

https://bugzilla.redhat.com/show_bug.cgi?id=1748681

Comment 8 Matthew Miller 2019-09-11 15:11:43 UTC
Given the QA impact, should this get a beta FE?

Also: presumably the testing is with Wayland. Does the problem exist in the X fallback, too?

Comment 9 Kamil Páral 2019-09-11 15:22:06 UTC
(In reply to Matthew Miller from comment #8)
> Also: presumably the testing is with Wayland. Does the problem exist in the
> X fallback, too?

Yes, it happens also with X11 (tested with F31 Workstation Live). Also happens with setenforce 0.

Comment 10 Adam Williamson 2019-09-11 15:35:01 UTC
Matthew: it's already nominated as Beta FE. The 'blocks' field seems to have been hidden behind a 'show advanced fields' button in Bugzilla recently, which is why you don't see it right away.

I'm +1 for this, as it affects the live environment and that can't entirely be fixed with an update, and it's an annoying issue.

Comment 11 Ben Cotton 2019-09-11 15:50:51 UTC
Accepted as a Prioritized Bug in today's meeting

Comment 12 Adam Williamson 2019-09-11 19:20:44 UTC
CCing bberg for GNOME session changes, as it seems likely that's related here.

Comment 13 Benjamin Berg 2019-09-11 23:46:24 UTC
Ugh, sounds like we need a fix in spice-vdagentd. i.e. it tries to look-up the session but fails to do so because it is not technically part of any session (yes, this is the case by design and intentional even tough somewhat crazy).

Mutter/GDM/gnome-session all have workarounds for exactly this. I have not looked at spice-vdagent though. Newer systemd also has support to make these workarounds really simple.

Comment 14 Benjamin Berg 2019-09-12 08:33:53 UTC
I just checked, and the problem is indeed the call to sd_pid_get_session (in src/vdagentd/systemd-login.c). A fallback will be needed there to find the users graphical (or greeter) session. Similar code is already in e.g. mutter (https://gitlab.gnome.org/GNOME/mutter/blob/master/src/core/main.c#L354). Some of the DBus API has a special "auto" value for the session on the systemd side now, which might also be a way to solve this if we can depend on systemd v243.

A workaround for this is to modify /usr/bin/gome-session to pass --builtin to gnome-session-binary.

I can look into this and cook up a patch, might be a few days though.

Comment 15 Kamil Páral 2019-09-12 10:38:56 UTC
Thanks a lot. Benjamin, very appreciated. This problem makes QA life much harder than it used to be :)

Comment 16 Frediano Ziglio 2019-09-12 11:34:32 UTC
(In reply to Adam Williamson from comment #7)
> Hum. I wonder if this is related to my tty? bug?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1748681

I think Adam is right, this should be fixed at the Gnome/SystemD level instead.

Comment 17 Benjamin Berg 2019-09-13 07:43:20 UTC
(In reply to Frediano Ziglio from comment #16)
> … this should be fixed at the Gnome/SystemD level instead.

It is a conceptual issue that occurs because we do not have a separation between the user and session scopes. This lack of separation has existed for years now, the only change here is that the entire desktop is now affect rather than "just" DBus activated applications.

Said differently, a fix is will be prohibitively expensive compared to the small improvements that it may allow us to do.

Comment 18 Benjamin Berg 2019-09-13 14:56:17 UTC
I created a scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=37647756

It looks good in my testing (i.e. it gets past the session ID lookup), but I didn't test the actual integration. Could someone please verify before I submit the patch upstream and the MR for the package?

Comment 19 Kamil Páral 2019-09-13 16:20:52 UTC
(In reply to Benjamin Berg from comment #18)
> I created a scratch build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=37647756

Benjamin, you're my hero! I installed this in my F31 VM and clipboard integration is working perfectly. I'm looking forward for an official fix.

Comment 20 Benjamin Berg 2019-09-13 16:29:03 UTC
Thanks, created a pull request for the package: https://src.fedoraproject.org/rpms/spice-vdagent/pull-request/1

Comment 21 Fedora Update System 2019-09-13 16:54:11 UTC
FEDORA-2019-0989e01e70 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0989e01e70

Comment 22 Fedora Update System 2019-09-14 01:40:37 UTC
spice-vdagent-0.19.0-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0989e01e70

Comment 23 Kamil Páral 2019-09-16 15:01:24 UTC
The fix works, thanks!

Comment 24 Chris Murphy 2019-09-16 16:02:10 UTC
*** Bug 1748123 has been marked as a duplicate of this bug. ***

Comment 25 Fedora Update System 2019-09-17 02:18:49 UTC
spice-vdagent-0.19.0-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 26 Kamil Páral 2019-09-17 11:51:07 UTC
I believe Adam reopened this by mistake, closing again.

Comment 27 Adam Williamson 2019-09-17 15:27:39 UTC
it was unfortunate timing...thanks.


Note You need to log in before you can comment on or make changes to this bug.