Allow the project to include init configs

[polarathene]

Is your feature request related to a problem? Please describe.

I'd like the project to be open to community contributed init files, especially for systemd.

In particular there is an issue reported since Jan 2022 that affects distros using systemd to manage XDG autostart .desktop files. Far easier to contribute that fix directly to open-vm-tools and have packagers pick it up on the next release.

---

This project seems to justify the exclusion based on this comment:

Unfortunately there is no startup script in the open-vm-tools.
Different Linux distributions use different init systems and init scripts. Each Linux vendor adds the needed files and scripts to their open-vm-tools packages.

I think that should be re-evaluated as the majority AFAIK use systemd these days? Even the advise given for CentOS 7 (released 2014, EOL in 2024) was advised with systemd config. There are a few that do not use systemd, but it seems odd to exclude the mainstream default on this basis?

I have seen other projects maintain these init configs so that it can be centralized and aligned with the projects releases, rather than defer to packagers where effort is duplicated unnecessarily are may diverge in approach for the same init system. It would be better for reproductions with bug reports when you're less dependent upon a specific distro and it's package / release where these configurations may change and influence the reproduction.

Despite all this, .desktop files present in the project serve a similar purpose yet are included.

---

A more recent (April 2023) justification for not including the systemd service files was given: #662 (comment)

It additionally directs the user to a VMWare knowledge base article: https://kb.vmware.com/s/article/74671

Perhaps that should be more discoverable from this projects README? Arguably though it'd seem more valuable to add actual configs into source control that is usable across distros, packagers with different requirements can tweak accordingly as they already do.

Describe the solution you'd like

A contrib/init folder in this project for the community to collaborate and assist maintaining such files.

Packagers or local builds can then benefit from this, while reducing burden on reproduction / troubleshooting of issues for maintainers.

---

If I'm not mistaken, this project may already be limited in bandwidth available from the maintainers. No expectation for them to create these, but instead for the community to contribute them and collaborate.

moby (Docker) for example has contrib/init/ with directories for different init systems config files. A packager can then source this common config from here, as can users that are building open-vm-tools from source, instead of also needing to reference a distros package for additional changes/files.

In one issue, we have some systemd services shared and documented from Ubuntu: #642 (comment)

---

There's also been a long standing issue reported since Jan 2022 regarding KDE Plasma failing to reliably start a service. This is from the Desktop Environment modernizing it's boot process by adopting the systemd XDG autostart service generator, but something related to invoking the vmware-user-suid-wrapper binary provided from this project does not seem entirely compatible with this (potentially due to the 5 sec timeout default being too low?).

In the linked comment, I investigated it recently and found a way to resolve the issue. I'd have contributed the fix, but learned the project doesn't ship any of the other systemd service configs. Instead, distros will need to go through a similar process or discover my comment far down in the thread (which will get buried / hidden over time if activity continues), then maintain that vs adopting an upstream contributed version which can be collaborated on should similar problems occur with other Desktop Environments going forward?

It benefits the maintainers as well. Despite the issue being open as long, and earlier discussions, maintainers have not engaged in troubleshooting or assisting with advice on resolving the issue. Not a problem, I can understand why, but the symptoms may contribute to other bug reports if neither party makes that connection. A pull request that is reviewed and approved however would likely be fresh in the mind of the maintainers, documented and resolved as part of the project and once that release is tricked down, simple to instruct users affected until the packagers leverage the provided config (which I assume would be quick via changelog awareness?).

Describe alternatives you've considered

Unofficial documentation of changes to upstream or additional files required to support features working need to be communicated in long-winded user discussions (be that Github issues, or other communties and wikis), and potentially reach packagers for consideration.

---

When I looked into this KDE compatibility issue originally, I compared what several distros did differently. OpenSUSE TumbleWeed differed and worked reliably via an additional shell script that was called instead of the binary, why it works I'm not certain (potentially because of the systemd service using Type=exec with ExitType=cgroup and how a shell script as the parent instead of the binary that forks was treated differently?).

I think given their script logic, this was present for some time before and not intended as a fix/workaround for the KDE Plasma specific problem, just a side-effect that avoided encountering it.

So the alternative is to expect users to find that and resolve the issue themselves (which you can see from the comments that followed after mine, was not that successful), or reach out to as many distros packagers as possible to communicate a fix that each must implement and maintain vs collaborate from using a common source maintained as part of open-vm-tools.

My later investigation that resolved it better with an explicit systemd service config is a best effort on my part, and not an area I have much expertise in. I trust that the packagers would however, so by contributing it into this repo, they could address any concerns and everyone benefits.

Additional context

No response

[polarathene]

Two examples of non-obvious "bugs" to troubleshoot as a user:

• vmware-user-suid-wrapper.desktop is not autostarted in fedora kde 35 #568 (comment)
• [BUG]: Viewport/monitor controls are missing (Multi-Monitor support also failing) #591 (comment)

The issues and many duplicates related to the same issues with little engagement to resolve them could do with better communication of docs, or inclusion of the configs for packagers to use / adapt and more easily communicate improvements/fixes (which otherwise results in problems being repeated until solutions are re-discovered from years ago).