search

vmware / open-vm-tools

Official repository of VMware open-vm-tools project
http://sourceforge.net/projects/open-vm-tools/
2.24k stars 426 forks source link

vmware-user-suid-wrapper.desktop is not autostarted in fedora kde 35 #568

Closed soredake closed 4 months ago

soredake commented 2 years ago

Describe the bug

vmware-user-suid-wrapper.desktop is not autostarted in fedora kde 35, which leads to non working dnd and clipboard sharing.

Reproduction steps

1. Install fedora kde 35 in vm.
2. Switch to x11.
3. Copy something on host.
4. Try to paste it in vm.
5. Not working.
...

Expected behavior

dnd and clipboard sharing works.

Additional context

No response

rprabhud commented 2 years ago

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

soredake commented 2 years ago

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

How can i get open-vm-tools logs?

rprabhud commented 2 years ago

@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 commented 2 years ago

@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?

rprabhud commented 2 years ago

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

rprabhud commented 2 years ago

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

ravindravmw commented 2 years ago

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?

soredake commented 2 years ago

I will test fedora rawhide kde later.

soredake commented 2 years ago

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

ravindravmw commented 2 years ago

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

rprabhud commented 2 years ago

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.

soredake commented 2 years ago

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?

rprabhud commented 2 years ago

x11

soredake commented 2 years ago

Thanks!

soredake commented 2 years ago

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

rprabhud commented 2 years ago

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.

soredake commented 2 years ago

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

rprabhud commented 2 years ago

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

Nothing else. Just installed and switched to x11.

rprabhud commented 2 years ago

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

soredake commented 2 years ago 
❯ systemctl --version
systemd 250 (v250.3-8.fc36)
❯ 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)
     Active: failed (Result: timeout) since Thu 2022-05-26 12:41:29 EEST; 2s ago
       Docs: man:systemd-xdg-autostart-generator(8)
    Process: 1518 ExecStart=/usr/bin/vmware-user-suid-wrapper (code=exited, status=0/SUCCESS)
   Main PID: 1518 (code=exited, status=0/SUCCESS)
        CPU: 410ms

мая 26 12:41:23 fedora systemd[1046]: Starting app-vmware\x2duser@autostart.service - VMware User Agent...
мая 26 12:41:24 fedora vmtoolsd[1521]: gtk_disable_setlocale() must be called before gtk_init()
мая 26 12:41:29 fedora systemd[1046]: app-vmware\x2duser@autostart.service: start operation timed out. Terminating.
мая 26 12:41:29 fedora systemd[1046]: app-vmware\x2duser@autostart.service: Failed with result 'timeout'.
мая 26 12:41:29 fedora systemd[1046]: Failed to start app-vmware\x2duser@autostart.service - VMware User Agent.
rprabhud commented 2 years ago

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?

soredake commented 2 years ago

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

soredake commented 2 years ago

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

rprabhud commented 2 years ago

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

IKatsu commented 2 years ago

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.

polarathene commented 2 years ago

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
service status logs ```console $ 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 output if helpful (vmware filtered snippets) ```console $ 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
service status logs ```console $ 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
service status logs ```console $ 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?

dbjungle commented 2 years ago

Creating /usr/bin/vmware-user-autostart-wrapper and adding it to Plasma's autostart resolved the issue for me on EndeavourOS.

Operating System: EndeavourOS
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.12-arch1-1 (64-bit)
Graphics Platform: X11
Nantris commented 2 years ago

Same issue with Kubuntu 22.04 with KDE 5.25. Worked fine with KDE 5.24. Adding scripts to autostart does not resolve it, but manually running the script does.

Edit: After an hour of trying to fix this, I'm just running it manually instead. Hopefully Kubuntu 22.10 will fix it via inclusion of systemd@251.

stefanhh0 commented 2 years ago

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

GrassBlock1 commented 2 years ago

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.

Nantris commented 1 year ago

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.

silverqx commented 1 year ago

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

IKatsu commented 1 year ago

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

IKatsu commented 1 year ago

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.

elboulangero commented 1 year ago

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

GuillaumeDIDIER commented 1 year ago

Issue still present in a Fresh Fedora KDE 38 btw

insanity213 commented 1 year ago

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.

polarathene commented 1 year ago

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?

insanity213 commented 1 year ago

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.

polarathene commented 1 year ago

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?

Earlier investigation The XDG autostart desktop file will be used by systemd to generate a `.service` file at runtime (`xdg-desktop-autostart.target`), but it is possible to opt-out too, as documented here: https://systemd.io/DESKTOP_ENVIRONMENTS/#xdg-autostart-integration This is the Plasma systemd integration responsible AFAIK at `/usr/lib/systemd/user/plasma-workspace.target`: ``` [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 ``` That uses `Wants=` and `Before=` to require `xdg-desktop-autostart.target` be started after this point (_[systemd unit docs](https://www.freedesktop.org/software/systemd/man/systemd.unit.html)_). Systemd will encode a `-` in the xdg autostart file name into the generated service as `\x2d`, which we can see from checking the `journalctl` logs, view the unit contents with `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 ``` Meanwhile, we can see from the OpenSUSE TW script that it attempts to wait for a different VMWare service dependency to be ready first, `systemctl cat vmware-vmblock-fuse.service`: ``` # /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 ``` The `WantedBy=` ensures it is started for the `multi-user.target` (_CLI services, as opposed to later `graphical-session.target` for GUI services_). So here we have the `vmware-user-suid-wrapper` get called and timeout within 5 sec, vs the openSUSE TW approach which for systemd doesn't seem to bother with waiting on `vmblock-fuse` to exist and just calls the `vmware-user-suid-wrapper` directly. I stripped out everything else to just the command with the script shebang and it seems to work reliably. Environment variables seems to be the the same, so I'm not quite sure what is different beyond `vmware-user-suid-wrapper` only sometimes hitting the 5 second timeout when not run via a shell script. --- So the following works (_but would likely require applying again after system updates_): `/usr/bin/vmware-user-autostart-wrapper`: (_this provides the compatibility_): ```bash #! /bin/sh /usr/bin/vmware-user-suid-wrapper ``` `/etc/xdg/autostart/vmware-user-autostart.desktop` (_modified to use the minimal shell script above_): ``` [Desktop Entry] Exec=vmware-user-autostart-wrapper Name=VMware User Agent Type=Application X-KDE-autostart-phase=1 ```

Probable solution

TL;DR:

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.

Extra commands for the curious (or troubleshooting) ```bash # 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.

insanity213 commented 1 year ago

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 :beers:

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

polarathene commented 1 year ago

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 :+1: 

# 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:

tk-nguyen commented 1 year ago

@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()
polarathene commented 1 year ago

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.

tk-nguyen commented 1 year ago

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

polarathene commented 1 year ago

This bug should be fixed upstream with a systemd change for upcoming v254 release: https://github.com/systemd/systemd/pull/28314

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

soredake commented 4 months ago

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