Bug 1953472 - VMWare copy&paste broken on KDE spin + X
Summary: VMWare copy&paste broken on KDE spin + X
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: open-vm-tools
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ravindra Kumar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-26 07:58 UTC by Stefan Hoffmeister
Modified: 2022-02-04 17:34 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-04 17:33:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Stefan Hoffmeister 2021-04-26 07:58:50 UTC
VMware copy&paste is broken on the KDE spin with X, with F34 (beta == almost final).

This appears to not be a problem with open-vm-tools per se, but with the packaging of it, with the integration of open-vm-tools with KDE in F34.

To reproduce:
* have fresh / clean install of F34, KDE spin, inside a VMware virtual machine
* login with Plasma on X
* copy text inside the X session, inside the F34 guest
* paste into the host

//exp: Text is pasted
//act: Copied text inside guest does not make it to the host

Apparent root cause: Content of /etc/xdg/autostart/vmware-user.desktop does not get executed.

Possible workaround: Run content of /etc/xdg/autostart/vmware-user.desktop manually.

This is a regression relative to F33.

Comment 1 Ravindra Kumar 2021-04-26 16:13:38 UTC
Thanks Stefan for reporting the issue. Did you check any system logs that could explain why /etc/xdg/autostart/vmware-user.desktop was not run? Does GNOME desktop work fine? Wondering if this is specific to KDE?

Comment 2 Stefan Hoffmeister 2021-04-26 18:57:59 UTC
Many thanks for your response, Ravindra.

Lets take a journey:

* install F34 from KDE spin, run under X (my baseline) -> broken copy&paste from guest to host

* `dnf install @workstation-product-environment`
* `reboot` (for good measure)
* log into KDE / X again to verify that copy&paste from guest to host is still broken
-> still broken

* leave -> logoff
* log into Gnome on X11
* try copy & paste from guest to host
-> works

* logoff
* log into GNOME (= Gnome on Wayland)
* try copy & paste from guest to host
-> works

* logoff
* log into KDE / X
* try copy & paste from guest to host
-> broken

(I am using Visual Studio Code as the source on the Linux side).

With respect to logs - honestly, I don't know where to look. `journalctl -xe` looks good (from my KDE session):

```
Apr 26 20:37:59 fedora systemd[7383]: Starting VMware User Agent...
░░ Subject: A start job for unit UNIT has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit UNIT has begun execution.
░░ 
░░ The job identifier is 530.

Apr 26 20:38:00 fedora systemd[7383]: Started VMware User Agent.
░░ Subject: A start job for unit UNIT has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit UNIT has finished successfully.
░░ 
░░ The job identifier is 530.
Apr 26 20:38:00 fedora systemd[7383]: Reached target Startup of XDG autostart applications.
░░ Subject: A start job for unit UNIT has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit UNIT has finished successfully.
░░ 
░░ The job identifier is 521.
```

But despite claiming all good, copy&paste does not work. Manually running `nohup /usr/bin/vmware-user-suid-wrapper >/dev/null 2>&1 &` fixes KDE (I might be overdoing it here with nohup and bg, just not taking any prisoners).

I am not testing KDE on Plasma because that would not be a productive effort (yet).

I am now reverting to the backup copy of the virtual machine; would be nice if VMware Workstation Player did snapshots ;)

Comment 3 Ravindra Kumar 2021-04-27 00:16:19 UTC
Thanks Stefan. This does seem like an autostart issue with KDE to me. We may need some KDE expert look at it.

You said it was working in F33. Would you mind comparing open-vm-tools package versions in F33 and F34? If we have the same version of open-vm-tools working in F33 (preferably the latest working version), then we can route this issue to KDE for further triage?

Comment 4 Rex Dieter 2021-04-27 04:04:53 UTC
kde plasma in f34 relies on systemd-xdg-autostart-generator, fwiw, and it seems to be running (trying to at least) for me, according to journalctl:

... fedora systemd[1809]: Starting VMware User Agent...
... fedora vmware-user-suid-wrapper[3855]: vmware-user: could not open /proc/fs/vmblock/dev
... fedora vmware-user-suid-wrapper[3855]: Error: /usr/bin/vmtoolsd must be run inside a virtual machine on a VMware hypervisor product.
... fedora systemd[3529]: app-vmware\x2duser: Deactivated successfully.

So it's either something to do with the autostart-generator, or plasma's default use of wayland on f34 that may be relevant.

To test both of those items:
* edit /etc/xdg/startkderc, comment out systemdBoot=true (or set to false)
* when logging in to plasma, choose x11 session type (instead of wayland)

Try changing one at a time to set if either helps.

Comment 5 Stefan Hoffmeister 2021-04-27 06:06:51 UTC
I may have a lead: systemd 248, user units and KDE 5.21.

With KDE 5.21, a new way to bring up the desktop environment was introduced, using systemd user units (http://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/). On my clean install of the F34 KDE spin, this new way is active. Part of this story is that autostart .desktop files get transposed into systemd user units; /etc/xdg/autostart/vmware-user.desktop is such a desktop file. It gets processed and has /run/user/1000/systemd/generator.late/app-vmware\x2duser as a result.

Via https://pagure.io/fedora-kde/SIG/issue/50 and some hunting in the links it seems as if systemd 248 as shipped with F34 (systemd-248-2.fc34.x86_64) and forking are an unhappy mix - the way I read it, systemd 248 looks at the exit status of the process referenced in the .desktop file - and then, in an act of cleaning up the user unit, kills any and all processes that were part of the process tree of that user unit.

As the executable name `vmware-user-suid-wrapper` used inside vmware-user.desktop already suggests, it is a wrapper for a different deliverable - and does execve() inside: https://github.com/vmware/open-vm-tools/blob/42ce53f39be45b7795a9f1adf892af84629b4a19/open-vm-tools/vmware-user-suid-wrapper/wrapper-linux.c#L143

So, working theory / speculation: All works well coming up, see

```
systemctl --user status app-vmware\\x2duser 
○ app-vmware\x2duser - VMware User Agent
     Loaded: loaded (/etc/xdg/autostart/vmware-user.desktop; generated)
     Active: inactive (dead) since Tue 2021-04-27 07:36:34 CEST; 22min ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 3741 ExecStart=/usr/bin/vmware-user-suid-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 3741 (code=exited, status=0/SUCCESS)
        CPU: 304ms

Apr 27 07:36:33 fedora systemd[3471]: Starting VMware User Agent...
Apr 27 07:36:33 fedora vmtoolsd[3743]: gtk_disable_setlocale() must be called before gtk_init()
Apr 27 07:36:34 fedora systemd[3471]: app-vmware\x2duser: Deactivated successfully.
Apr 27 07:36:34 fedora systemd[3471]: Started VMware User Agent.
```

but vmware-user-suid-wrapper terminating (it's a wrapping launcher) results in *vmware-user* being killed by systemd, as vmware-user is member of the same process group as vmware-user-suid-wrapper. Alas, I cannot find any log entries for that killing, wouldn't even know where to look. And that's where all the launching was successful, but then systemd cleans things up...

There are suggestions that systemd 249 might fix that problem. But systemd releases seem to take a considerable while to release, and systemd 248 is fresh.

Comment 6 Stefan Hoffmeister 2021-04-27 06:14:10 UTC
I can confirm that for /etc/xdg/startkderc

  [General]
- systemdBoot=true
+ systemdBoot=false

restores the expected vmware-user functionality (copy&paste, probably also drag&drop), without having to manually run `/usr/bin/vmware-user-suid-wrapper`

I am not (yet) using Wayland, so I have not tested there.

Comment 7 Stefan Hoffmeister 2021-04-27 06:23:11 UTC
FWIW - https://github.com/systemd/systemd/pull/18782 is systemd enabling the vmware-user use case.

Comment 8 Paul Black 2021-04-27 07:07:55 UTC
(In reply to Stefan Hoffmeister from comment #6)
> I can confirm that for /etc/xdg/startkderc
> 
>   [General]
> - systemdBoot=true
> + systemdBoot=false

This works for me for starting programs specified in the System Settings => Autostart => Startup/Shutdown (MS Teams & Dropbox).


> I am not (yet) using Wayland, so I have not tested there.

Nor me.

Comment 9 Ravindra Kumar 2022-02-04 07:24:28 UTC
Thanks Stefan for sharing all the details. According to https://bugs.kde.org/show_bug.cgi?id=433299, Systemd 250.x introduces ExitType=cgroup which is used by KDE and should address this bug. If we can get a confirmation that Systemd 250.x with latest KDE works fine, we would be able to close this bug because there is nothing much to fix in open-vm-tools for this issue.

Comment 10 Ravindra Kumar 2022-02-04 17:33:25 UTC
We performed tests with Rawhide builds and found this.

F35 has systemd 249 (v249.4-2.fc35)
F34 has systemd 248 (v248-2.fc34)
Upgraded to Rawhide, it has systemd 250 (v250.3-3.fc36)

In F34 and F35, ExitType is not present in /run/user/1000/systemd/generator.late/app-vmware\x2duser.
In Rawhide upgraded system /run/user/1000/systemd/generator.late/app-vmware\x2duser has ExitType=cgroup.

We also verified that vmusr process is started, copy&paste works as expected.

There is no change needed in open-vm-tools. So, closing it.


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