Please provide open-vm-tools and workstation/fusion version.
We will also need the open-vm-tools and host logs.

open-vm-tools version is 11.3.0, on Fedora KDE spin 35, using x11.

How can i get open-vm-tools logs?

@soredake
This issue is present in KDE 34 onwards and it is because KDE using systemd to bring up the desktop environment.
There is already a bug opened for fedora redhat.
As a workaround it is suggested to set ‘systemdBoot=false’ in /etc/xdg/startkderc and restart the vm.
It fixes both dnd and copy&paste issue.

@soredake
This issue is present in KDE 34 onwards and it is because KDE using systemd to bring up the desktop environment.
There is already a bug opened for fedora redhat.
As a workaround it is suggested to set ‘systemdBoot=false’ in /etc/xdg/startkderc and restart the vm.
It fixes both dnd and copy&paste issue.

Can i have link to this bugreport?

Here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1953472

If dnd is not working then please check "systemctl status run-vmblock\x2dfuse.mount".
For dnd, run-vmblock\x2dfuse.mount must be enabled and started. We checked that for Fedora 34 and 35, this is not enabled. It can be enabled and started using following commands:
systemctl enable run-vmblock\x2dfsuse.mount # allow to run on system boot/reboot
systemctl start run-vmblock\x2dfuse.mount # start for the current session
For more info, you can refer to https://kb.vmware.com/s/article/74671

According to https://bugs.kde.org/show_bug.cgi?id=433299, Systemd version 250 introduced ExitType=cgroup (used by services generated by KDE). Is this issue seen with recent KDE versions running on systems with Systemd 250 or later?

I will test fedora rawhide kde later.

Rawhide kde is broken in vmware right now (freezes oftenly), so i'll just wait for 36 release.

@soredake you might want to use a stable build of Rawhide if you are trying it out.

I upgraded the system to rawhide from fedora kde 35 and verified following:

1. It has systemd 250 (v250.3-3.fc36) and ExitType=cgroup in /run/user/1000/systemd/generator.late/app-vmware\x2duser@autostart.service.
2. vmware-user-suid-wrapper.desktop is autostarted and run-vmblock\x2dfuse.mount is also enabled.
3. copy&paste and dnd works.

I upgraded the system to rawhide from fedora kde 35 and verified following:

1. It has systemd 250 (v250.3-3.fc36) and ExitType=cgroup in /run/user/1000/systemd/generator.late/app-vmware\x2duser@autostart.service.
2. vmware-user-suid-wrapper.desktop is autostarted and run-vmblock\x2dfuse.mount is also enabled.
3. copy&paste and dnd works.

In x11 or wayland?

x11

Thanks!

Today, i've installed fedora kde 36 in vm, and it's still not autostarted.

Today, i've installed fedora kde 36 in vm, and it's still not autostarted.

I installed Fedora kde 36 and observed that vmware-user-suid-wrapper is autostarted.
Also, it has systemd 250 (v250.3-8.fc36).
Copy&Paste and dnd is working in x11.

IDK, i just installed it, haven't changed anything. Have you done anything besides installing it?

IDK, i just installed it, haven't changed anything. Have you done anything besides installing it?

Nothing else. Just installed and switched to x11.

what is 'systemctl --version' on your system?
Also, check 'systemctl --user status app-vmware\x2duser@autostart.service' .

I installed one more vm with fedora kde 36 but still not able to reproduce the issue.
Did you do fresh install or upgrade?
As per your logs, service did try autostart but timed out. app-vmware\x2duser@autostart.service has 'TimeoutSec=5s'. You may try reloading the vm to see if issue persists.
Also, can you give one more try for fresh install?

Also, can you give one more try for fresh install?

I adjusted TimeoutSec to 100s for a test, and it turned out that service is actually is started and works (for 5 seconds only by default, that's when i tried it's not worked), but systemd thinks that service is not started and kills it after 5 seconds if i allocate more than 4 cores to vm. When i set core number to 4 or lower systemd correctly recognize that service is started.

I'm not sure who misbehaves here, systemd, vmware with hyper-v or open-vm-tools when core number set to >=8

Actually, chances that systemd correctly recognize that service is started are 50/50.

We are able to reproduce the issue and observed that vmusr actually starts but gets killed after 5 seconds. We are still debugging to find the root cause.
Issue does not seem to be with open-vm-tools as I tested a scenario by setting systemdBoot to false and vmusr started successfully on reboot.
You may use this as a workaround for now: set ‘systemdBoot=false’ in /etc/xdg/startkderc and restart the VM

This has been plaguing me since FC34 came out and it's still an issue in FC36
https://bugzilla.redhat.com/show_bug.cgi?id=1953472
Supposedly it is something with the auto start file and kde exit values. it should be fixed in systemd 250 but FC36 has systemd 250 and it still doesn't work.
The workaround via startkderc DOES work but this file gets overwritten often by updates.

I installed Fedora kde 36 and observed that vmware-user-suid-wrapper is autostarted.

Failure should be consistent now.

Fedora 36 KDE

Failing consistently (after updating to recent Plasma 5.24.5 => 5.25.2 upgrade).

Plasma: 5.25.2
Frameworks: 5.94
Qt: 5.15.3
Kernel 5.18.9
xorg: 1.20.14, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.5
systemd: 250.7

$ systemctl --user --all --failed status

● fedora
    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Fri 2022-07-08 19:51:19 NZST; 10min ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─app.slice

# ...

× app-vmware\x2duser@autostart.service - VMware User Agent
     Loaded: loaded (/etc/xdg/autostart/vmware-user.desktop; generated)
     Active: failed (Result: timeout) since Fri 2022-07-08 19:51:29 NZST; 10min ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 1556 ExecStart=/usr/bin/vmware-user-suid-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 1556 (code=exited, status=0/SUCCESS)
        CPU: 180ms

Jul 08 19:51:24 fedora systemd[1113]: Starting app-vmware\x2duser@autostart.service - VMware User Agent...
Jul 08 19:51:25 fedora vmtoolsd[1561]: gtk_disable_setlocale() must be called before gtk_init()
Jul 08 19:51:29 fedora systemd[1113]: app-vmware\x2duser@autostart.service: start operation timed out. Terminating.
Jul 08 19:51:29 fedora systemd[1113]: app-vmware\x2duser@autostart.service: Failed with result 'timeout'.
Jul 08 19:51:29 fedora systemd[1113]: Failed to start app-vmware\x2duser@autostart.service - VMware User Agent.

$ journalctl -b0 | grep -i vmware

Jul 06 10:59:06 fedora kernel: DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Jul 06 10:59:06 fedora kernel: vmware: hypercall mode: 0x02
Jul 06 10:59:06 fedora kernel: Hypervisor detected: VMwar

# ...

Jul 06 10:59:06 fedora kernel: Booting paravirtualized kernel on VMware hypervisor
Jul 06 10:59:06 fedora kernel: input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input4
Jul 06 10:59:06 fedora kernel: input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3
Jul 06 10:59:06 fedora kernel: usb 1-1: Product: VMware Virtual USB Mouse
Jul 06 10:59:06 fedora kernel: usb 1-1: Manufacturer: VMware
Jul 06 10:59:06 fedora kernel: input: VMware VMware Virtual USB Mouse as /devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb1/1-1/1-1:1.0/0003:0E0F:0003.0001/input/input5
Jul 06 10:59:06 fedora kernel: hid-generic 0003:0E0F:0003.0001: input,hidraw0: USB HID v1.10 Mouse [VMware VMware Virtual USB Mouse] on usb-0000:02:00.0-1/input0

# ...

Jul 06 10:59:09 fedora systemd[1]: Detected virtualization vmware.
Jul 06 10:59:09 fedora systemd[1]: Mounting run-vmblock\x2dfuse.mount - VMware vmblock Fuse Mount...
Jul 06 10:59:09 fedora systemd[1]: Mounted run-vmblock\x2dfuse.mount - VMware vmblock Fuse Mount.
Jul 06 10:59:11 fedora VGAuthService[837]: Pref_Init: Using '/etc/vmware-tools/vgauth.conf' as preferences filepath
Jul 06 10:59:11 fedora systemd[1]: Started vmtoolsd.service - Service for virtual machines hosted on VMware.

# ...

Jul 06 11:00:17 fedora systemd[1095]: Starting app-vmware\x2duser@autostart.service - VMware User Agent...
Jul 06 11:00:22 fedora systemd[1095]: app-vmware\x2duser@autostart.service: start operation timed out. Terminating.
Jul 06 11:00:22 fedora systemd[1095]: app-vmware\x2duser@autostart.service: Failed with result 'timeout'.
Jul 06 11:00:22 fedora systemd[1095]: Failed to start app-vmware\x2duser@autostart.service - VMware User Agent.

Service that fails due to timeout:

/etc/xdg/autostart/vmware-user.desktop:

[Desktop Entry]
Type=Application

Exec=/usr/bin/vmware-user-suid-wrapper
Name=VMware User Agent
# KDE bug 190522: KDE does not autostart items with NoDisplay=true...
# NoDisplay=true
X-KDE-autostart-phase=1

EndeavourOS (ArchLinux based) KDE

Same problem as Fedora.

Plasma: 5.25.2
Frameworks: 5.95
Qt: 5.15.5
Kernel: 5.18.9
xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.5
systemd: 251.2

$ systemctl --user --all status

# ...

× app-vmware\x2duser@autostart.service - VMware User Agent
     Loaded: loaded (/etc/xdg/autostart/vmware-user.desktop; generated)
     Active: failed (Result: timeout) since Fri 2022-07-08 18:36:15 NZST; 7min ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 726 ExecStart=/usr/bin/vmware-user-suid-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 726 (code=exited, status=0/SUCCESS)
        CPU: 235ms

Jul 08 18:36:10 eos-kde systemd[528]: Starting VMware User Agent...
Jul 08 18:36:11 eos-kde vmtoolsd[728]: gtk_disable_setlocale() must be called before gtk_init()
Jul 08 18:36:15 eos-kde systemd[528]: app-vmware\x2duser@autostart.service: start operation timed out. Terminating.
Jul 08 18:36:15 eos-kde systemd[528]: app-vmware\x2duser@autostart.service: Failed with result 'timeout'.
Jul 08 18:36:15 eos-kde systemd[528]: Failed to start VMware User Agent.

# ...

● xdg-desktop-autostart.target - Startup of XDG autostart applications
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-autostart.target; static)
     Active: active since Fri 2022-07-08 18:36:15 NZST; 9min ago
      Until: Fri 2022-07-08 18:36:15 NZST; 9min ago
       Docs: man:systemd.special(7)

Jul 08 18:36:15 eos-kde systemd[528]: Reached target Startup of XDG autostart applications.

/etc/xdg/autostart/vmware-user.desktop: (basically the same as Fedora, adds Encoding)

[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=/usr/bin/vmware-user-suid-wrapper
Name=VMware User Agent
# KDE bug 190522: KDE does not autostart items with NoDisplay=true...
# NoDisplay=true
X-KDE-autostart-phase=1

openSUSE Tumbleweed KDE

This distro does not encounter the problem!

Plasma: 5.25.2
Frameworks: 5.95
Qt: 5.15.5
Kernel 5.18.6
xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0
open-vm-tools: 12.0.0
systemd: 250.6

$ systemctl --user --all status

● localhost.localdomain
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Tue 2022-07-05 23:01:40 NZST; 2 days ago
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─app.slice
# ...
           │ ├─app-vmware\x2duser\x2dautostart@autostart.service
           │ │ └─ 1882 /usr/bin/vmtoolsd -n vmusr --blockFd 3

# ...

● app-vmware\x2duser\x2dautostart@autostart.service - VMware User Agent
     Loaded: loaded (/etc/xdg/autostart/vmware-user-autostart.desktop; generated)
     Active: active (running) since Tue 2022-07-05 23:01:44 NZST; 2 days ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 1866 ExecStart=/usr/bin/vmware-user-autostart-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 1866 (code=exited, status=0/SUCCESS)
      Tasks: 4 (limit: 4588)
     Memory: 22.1M
        CPU: 1min 25.964s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-vmware\x2duser\x2dautostart@autostart.service
             └─ 1882 /usr/bin/vmtoolsd -n vmusr --blockFd 3

Jul 05 23:01:44 localhost.localdomain systemd[1305]: Starting VMware User Agent...
Jul 05 23:01:44 localhost.localdomain systemd[1305]: Started VMware User Agent.
Jul 05 23:01:44 localhost.localdomain vmtoolsd[1882]: gtk_disable_setlocale() must be called before gtk_init()

/etc/xdg/autostart/vmware-user-autostart.desktop:

[Desktop Entry]
Exec=vmware-user-autostart-wrapper
Name=VMware User Agent
Type=Application
X-KDE-autostart-phase=1

/usr/bin/vmware-user-autostart-wrapper: (this provides the compatibility)

#!/bin/sh
MAX_RETRY=8
RETRY=0
SLEEP=1

unset SESSION_MANAGER

# If running systemd, skip the delay loop as starting vmblock-fuse is not enforced
if file /sbin/init | grep -qv "systemd"; then

  while [ $RETRY -lt $MAX_RETRY ]; do

  if [ -f /var/run/vmblock-fuse/dev ]; then
     RETRY=$MAX_RETRY
  else
    logger "Try $RETRY/$MAX_RETRY : /var/run/vmblock-fuse/dev not available. sleeping for $SLEEP seconds"
    sleep $SLEEP
    RETRY=$(($RETRY + 1))
    SLEEP=$(($SLEEP * 2))
  fi
  done
fi

# Unconditionally start vmware-user-suid-wrapper (after waiting for vmblock-fuse if not under systemd)
/usr/bin/vmware-user-suid-wrapper

Fix? (from openSUSE TW)

When running vmware-user-suid-wrapper manually, I get the output:

(vmware-user:2245): Gtk-WARNING **: 20:08:49.599: gtk_disable_setlocale() must be called before gtk_init()

And it tends to hang there while running, although sometimes I've seen it exit. I don't know what is expected there, but I guess that causes the timeout issue, and SUSE avoids that somehow with the script? (early exit?)

I applied it to Fedora 36 KDE, and pointed /etc/xdg/autostart/vmware-user.desktop to Exec= that instead, and it worked correctly. Perhaps that could be adapted and upstreamed?

Debian GNU Testing has the very same issue:

Operating System: Debian GNU/Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.4
Kernel Version: 5.19.0-1-amd64 (64-bit)
Graphics Platform: X11

Following workaround solved the problem for now:

$ cat /etc/xdg/startkderc 
[General]
systemdBoot=false

systemsetttings -> startup/shutdown -> autostart:
add: /usr/bin/vmware-user-suid-wrapper
reboot

Arch Linux with latest rolling release has the same issue:

Operating System: Arch Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.12-arch1-1 (64-bit)
Graphics Platform: X11

And set ‘systemdBoot=false’ in /etc/xdg/startkderc (it doesn't exist on my vm and I just create it)and restart the vm worked for me.

Unfortunately Kubuntu 22.10 with systemd@251 doesn't resolve the issue - autostart still fails to fix the inability to copy/paste. Also tried with KDE 5.26.

On Manjaro this worked for me

Install optional dependency:
sudo pacman -S gtkmm3

Fix buggy behavior:
sudo vim /etc/xdg/startkderc

[General]
systemdBoot=false

Reboot

Still an issue in Fedora 36 KDE spin
They keep resetting the startkderc too with some update which adds to the frustration.

I am undecided if this is either funny or really sad how this is still an issue in FC37 KDE. (Tested the latest live spin to be sure it wasn't due to me upgrading an old VM)
Fedora keeps closing bug reports claiming its fixed or just because the bug was reported on an older major version.
Manually adjusting the /etc/xdg/startkderc works but not in the long run as that file gets overwritten by updates.

What I found to work as a more lasting workaround is to create your own autostart application that is pointing to:
/usr/bin/nohub /usr/bin/vmware-user-suid-wrapper

It needs the nohub or it won't work.
The kwriteconfig5 mentioned in this thread didn't work for me on FC36 and 37.

FWIW, this issue is also confirmed on Kali Linux KDE.

Issue still present in a Fresh Fedora KDE 38 btw

Ran into this on Kubuntu 23.04 today, about the only work around I've found is to add vmware-user to ~/.bashrc. It pukes those errors every time you launch a terminal but at least copy/paste works on boot without having to run anything. All my attempts at using systemd, the wrapper, KDE autostart, etc had no effect. Guess I'll live with some terminal puke.

the only work around I've found is to add vmware-user to ~/.bashrc.

Did you try the openSUSE Tumbleweed solution that I verified worked for Fedora?

What was your systemd attempt? Or did you mean disabling the Plasma systemd boot?

Yeah I tried adding that TW script and calling it from Exec= in the systemd service file but it didn't work. I tried popping in an additional systemd script just to run vmware-user or that script. Also played around with some of the After= and WantedBy= statements in the service files. Tried some stupid tricks in crontab too. Honestly by then I was a few beers deep and just throwing stuff at the wall to see if anything would stick. Something about this version of KDE and Wayland doesn't seem to like starting vmware-user and in all reality I don't really know wth I'm doing either. Adding /usr/bin/vmware-user to the top line of my ~/.bashrc works, even if its ugly. I can deal with the garbage in the terminal when starting a new one, I just needed to get a build environment together for a little project I'm playing with and was pissed off I couldn't cut n paste from the host machine.

Yeah I tried adding that TW script and calling it from Exec= in the systemd service file but it didn't work.

That's not what I documented. The Exec= to adjust is in the .desktop XDG autostart file, not a systemd service.

Something about this version of KDE and Wayland doesn't seem to like starting vmware-user and in all reality I don't really know wth I'm doing either.

It's due to Plasma changing their boot process to leverage systemd instead of orchestrating it all via shell scripts (At least I think that's what they used previously?), but that affected the reliability of this VMWare service starting.

UPDATE: Seems to be due to this change that systemd manages the XDG autostart files and generates units from them, but the default settings that can't be inferred aren't playing nice.

I had some time to look further into it. Perhaps you can share how well it works for you?

[Unit]
Description=KDE Plasma Workspace
Requires=plasma-core.target graphical-session.target
Wants=plasma-restoresession.service plasma-xembedsniproxy.service plasma-gmenudbusmenuproxy.service plasma-powerdevil.service plasma-ks>
BindsTo=graphical-session.target
Before=graphical-session.target xdg-desktop-autostart.target plasma-ksplash-ready.service plasma-restoresession.service
RefuseManualStart=yes
StopWhenUnneeded=true

# /run/user/1000/systemd/generator.late/app-vmware\x2duser@autostart.service
# Automatically generated by systemd-xdg-autostart-generator

[Unit]
Documentation=man:systemd-xdg-autostart-generator(8)
SourcePath=/etc/xdg/autostart/vmware-user.desktop
PartOf=graphical-session.target

Description=VMware User Agent
After=graphical-session.target

[Service]
Type=exec
ExitType=cgroup
ExecStart=:/usr/bin/vmware-user-suid-wrapper
Restart=no
TimeoutSec=5s
Slice=app.slice

# /usr/lib/systemd/system/vmware-vmblock-fuse.service
[Unit]
Description=Open Virtual Machine Tools (vmware-vmblock-fuse)
ConditionVirtualization=vmware

[Service]
Type=simple
RuntimeDirectory=vmblock-fuse
RuntimeDirectoryMode=755
ExecStart=/usr/bin/vmware-vmblock-fuse -d -f -o subtype=vmware-vmblock,default_permissions,allow_other /run/vmblock-fuse

[Install]
WantedBy=multi-user.target

#! /bin/sh
/usr/bin/vmware-user-suid-wrapper

[Desktop Entry]
Exec=vmware-user-autostart-wrapper
Name=VMware User Agent
Type=Application
X-KDE-autostart-phase=1

Probable solution

TL;DR:

• Create a user unit to run vmware-user-suid-wrapper and enable it.
• Prevent systemd from creating it's own unit from the XDG autostart .desktop file (X-systemd-skip=true).

You can create a user unit of your own, with basically the same output as systemd generated (shared in the collapsed "earlier investigation" above), it just needs a [Install] section to enable. Here is a slight variant of that, create this file:

~/.config/systemd/user/app-vmware-user.service:

[Unit]
Description=VMware User Agent
Documentation=https://github.com/vmware/open-vm-tools
# When the target is stopped or restarted, that will propagate to this unit too
PartOf=graphical-session.target
# Start this unit after the target is reached
After=graphical-session.target

[Service]
Type=forking
ExecStart=/usr/bin/vmware-user-suid-wrapper
# Group this service in the XDG app slice 
Slice=app.slice

[Install]
# When enabling this unit, a symlink is created so the target will start this service
WantedBy=graphical-session.target

Now enable the unit so it's started at boot systemctl --user enable --now app-vmware-user.service.

# If you make changes to the unit, apply them with:
systemctl --user daemon-reload
systemctl --user restart app-vmware-user.service

# Overall status with last few log lines
systemctl --user status app-vmware-user.service
# Full logs for unit since boot
journalctl --boot --user-unit app-vmware-user.service

# Unit is grouped under the app.slice:
systemd-cgls --user app.slice
# Additional monitoring for the slice, increase depth to see individual units:
systemd-cgtop --depth 3 --order path user.slice

You'll still have the /etc/xdg/autostart/vmware-user.desktop file generating it's own unit for systemd, you can avoid this by adding X-systemd-skip=true into that file.

That's not what I documented. The Exec= to adjust is in the .desktop XDG autostart file, not a systemd service.

Well I guess thats what I get for trying to fix this while drinking 9% Belgian ale 🍻

It's due to Plasma changing their boot process to leverage systemd instead of orchestrating it all via shell scripts (At least I think that's what they used previously?), but that affected the reliability of this VMWare service starting.

Makes sense, but honestly the last time I used KDE I was running a K6/2-350 processor. Haven't really kept up on things.

I had some time to look further into it. Perhaps you can share how well it works for you?

Works perfectly! Thank you so much!!!

I did a little bit more investigation / experimenting. Creating an explicit systemd service + disabling the implicit generation of one from the .desktop file should be valid, but an override drop-in for the time being is simpler and doesn't require editing the packaged .desktop file 👍

# Create an drop-in user override file:
nano '~/.config/systemd/user/app-vmware\x2duser@autostart.service.d/override.conf'
# or:
systemctl --user edit "app-vmware\x2duser@autostart.service"

# Add these two lines:
[Service]
Type=forking

That's all, just a file with two lines :)

You could additionally mimic what other .service files in your open-vm-tools package likely provided, adding a constraint to only run the unit when a VMware guest is detected (not required, but maybe good practice if the guest would potentially also run in a non-vmware environment):

[Unit]
ConditionVirtualization=vmware

If this workaround doesn't solve it for you, share information from these two commands:

systemctl --user cat "app-vmware\x2duser@autostart.service"
systemctl --user status "app-vmware\x2duser@autostart.service"

That will share the generated service config + any override added, and the 2nd command will show the failed status + logs.

Update

For anyone interested:

• I documented plenty of information in my PR, along with a summary / conclusion.
• The upstream systemd issue I raised will workaround the issue in a future systemd release by replacing TimeoutSec=5s with TimeoutStopSec=5s. Thus this problem will be resolved once that reaches you 👍

@polarathene, I tried your suggestions but still doesn't seem to work.

I'm currently using Fedora 38, KDE Plasma 5.27.5, VMWare Workstation 17.0.2, open-vm-tools 12.1.5.

Here's some additional information:

test@fedora ~> systemctl --user cat app-vmware\\x2duser@autostart.service
# /run/user/1000/systemd/generator.late/app-vmware\x2duser@autostart.service
# Automatically generated by systemd-xdg-autostart-generator

[Unit]
Documentation=man:systemd-xdg-autostart-generator(8)
SourcePath=/etc/xdg/autostart/vmware-user.desktop
PartOf=graphical-session.target

Description=VMware User Agent
After=graphical-session.target

[Service]
Type=exec
ExitType=cgroup
ExecStart=:/usr/bin/vmware-user-suid-wrapper
Restart=no
TimeoutSec=5s
Slice=app.slice

# /usr/lib/systemd/user/service.d/10-timeout-abort.conf
# This file is part of the systemd package.
# See https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer.
#
# To facilitate debugging when a service fails to stop cleanly,
# TimeoutStopFailureMode=abort is set to "crash" services that fail to stop in
# the time allotted. This will cause the service to be terminated with SIGABRT
# and a coredump to be generated.
#
# To undo this configuration change, create a mask file:
#   sudo mkdir -p /etc/systemd/user/service.d
#   sudo ln -sv /dev/null /etc/systemd/user/service.d/10-timeout-abort.conf

[Service]
TimeoutStopFailureMode=abort

# /home/test/.config/systemd/user/app-vmware\x2duser@autostart.service.d/overri>
[Service]
Type=forking

test@fedora ~> systemctl --user status "app-vmware\x2duser@autostart.service"
● app-vmware\x2duser@autostart.service - VMware User Agent
     Loaded: loaded (/etc/xdg/autostart/vmware-user.desktop; generated)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
             /home/test/.config/systemd/user/app-vmware\x2duser@autostart.service.d
             └─override.conf
     Active: active (running) since Thu 2023-06-08 23:16:29 +07; 5min ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 1934 ExecStart=/usr/bin/vmware-user-suid-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 1950 (vmtoolsd)
      Tasks: 4 (limit: 4586)
     Memory: 25.2M
        CPU: 349ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/app-vmware\x2duser@autostart.service
             └─1950 /usr/bin/vmtoolsd -n vmusr --blockFd 3 --uinputFd 4

Jun 08 23:16:29 fedora systemd[1308]: Starting app-vmware\x2duser@autostart.service - VMware User Agent...
Jun 08 23:16:29 fedora systemd[1308]: Started app-vmware\x2duser@autostart.service - VMware User Agent.
Jun 08 23:16:30 fedora vmtoolsd[1950]: gtk_disable_setlocale() must be called before gtk_init()

I tried your suggestions but still doesn't seem to work.

Everything looks good there. I see --uinputFd which implies Wayland, that doesn't work unless using Gnome I think.

This issue is only about the generated vmware-user.desktop service failing to be recognized as "Started" by systemd, which would trigger the current timeout condition terminating vmtoolsd -n vmusr --blockFd 3 (breaking the supported functionality).

Lack of proper Wayland support is a known issue and there are other issues open for tracking that. I don't know if there is much progress to resolve it though.

Yeah, I switched back to X11 and it seems to work fine. Thanks for your help!

This bug should be fixed upstream with a systemd change for upcoming v254 release: systemd/systemd#28314

For guests prior to that release, you can workaround the issue as shared above.

2 years passed, maintainers either not interested or too busy to fix this, thus closing.