Gradle does not work when WSS Agent is enabled on macOS
search cancel

Gradle does not work when WSS Agent is enabled on macOS

book

Article ID: 424520

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

macOS developers using WSS Agent on macOS platforms to access internet sites via Cloud SWG.

Some developers on this platform install Gradle, for code development and the Gradle application path is bypassed from going into Cloud SWG.

When launching Gradle however, it seems to lock (without any error code) and users cannot build/test anything from the command line nor their IDE.

Launching the gradle command with a "--debug" flag logs the following line over and over (with different dynamic ports each time issue replicated):

2025-11-14T22:42:59.553+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] The file lock for journal cache (/Users/example_user/.gradle/caches/journal-1)
is held by a different process (pid: xxxxx, lockId: #####). Pinged owner at port 53949.

Once in this state, the only way to get Gradle to work again is to either

  • disable the WSS agent and 
  • stop / start all Gradle daemons from the command line

Environment

Gradle.

macOS.

WSS Agent.

Cause

macOS issues with loopback applications and network extensions.

Resolution

Disable IPv6 on the macOS interfaces using the following terminal command or the following macOS UI options:

sudo networksetup -setv6off Wi-Fi              (or can add the Ethernet interface name) 

Additional Information

The file lock references port 59868 which is not an active listener with the netstat output, nor do we even see a TCP SYN or UDP request to. This message is reported on the loopback session to TCP 53949 (assuming a Gradle control channel) but there does not seem to be anything I can find for
 
 
There is some traffic reported in the PCAPs to this 59868 UDP (not TCP) port from about 10 seconds earlier for this port but it is not active at the time we reference it .

This is where it gets interesting. We can find the UDP requests going out the wire, but they never reach the destination as the TCP/IP stack claims that port is not reachable .. it would appear that this UDP port was torn down before Gradle tried to reference it, and cannot. It does not seem to recover well but simply keeps retrying.
 
 
 
Since the netstat output showed a number of IPv4 and IPv6 UDP listeners on loopback interface for Gradle, we tried disabling IPv6 to see if it made any difference and fortunately it worked around the issue.