Bug 1953472

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?

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 ;)

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?

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.

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.

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.

FWIW - https://github.com/systemd/systemd/pull/18782 is systemd enabling the vmware-user use case.

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

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.

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.