How to start Boundary Desktop without starting a cache

Boundary
1

Hello!
Boundary cache daemon seem to be buggy is there some way to make desktop client run without using it?
Looks like BOUNDARY_SKIP_CACHE_DAEMON works for CLI only, maybe it’s possible to make desktop GUI client to respect this env or any other way to bypass cache exists?

1 Like
2

Hey @dmitryroshchin,

We don’t currently have a way for end users to bypass the cache daemon on the desktop client. What specific issue are you referring to in your link regarding cache daemon being buggy?

3

Hey @zed thanks for response and sorry for confusion!

Here is the correct issue link:

The problem seems to be not with cache-daemon itself, but with how GUI client interacts with cache, because CLI works way faster

Thats why I thought about disabling cache usage in GUI. Maybe I could rebuild GUI client verison by disabling cache directly in code for checking this hypothesis? If that is possible, please tell me where to look.

Thanks!

4

Thanks for the followup @dmitryroshchin! Apologies for not further responding in the previous thread, I believe we missed your update. Unfortunately it seems like we haven’t been able to reproduce the issue nor have we seen anyone else yet with the same issue.

Regarding disabling the cache usage, you should be able to just run boundary cache stop in a terminal to stop the cache. Please note that some features depend on the cache and will not work without it so it is not a supported workflow currently.

Restarting the desktop client should also restart the cache again as well.

5

Thanks @zed !
New update on the issue, I hope it will help:

I’ve just tested boundary desktop on my old amd64 system and it works fast as it should
No performance degradation at all!
On both systems OS is MacOS 15.1 and Boundary Desktop Client Version: 2.2.0

I guess this proves that there is no configurations issues on controller’s side and It’s strange that you didn’t meet the same issues with other installations
The issue seems to be existing only with arm version of the desktop and/or cache daemon. What other debugging steps could we do to pinpoint it?