ts1000 <ts1...@rad2know.net> writes: > It seems that gradle is: > placing a lock on a file somewhere in ~/.gradle directory > then, I presume it writes to it. > > Then it tries to remove the lock, and then close the file. > > Somewhere there there seem to be an error.
That sounds promising. > There is also an error about a file missing: > > 15850 25 java NAMI "/usr/share/nls/nls.alias.db" > > I am not sure what this file represents or if it is relevant. This is unlikely to be important. > > And from there on, I see timeouts.. i am presuming that because that > file is not properly closed > 15850 17 java RET ___lwp_park60 -1 errno 60 Connection > timed out In the kdump output, you can find a file descriptor when a file gets opened, and then that same value in subsequent calls. The goal is to find the system call that either has clearly bad arguments or an unexpected return value. In this case, this is thread 17, and a return of -1 errno 60 means that the time given in _lwp_park expired before wakup. You can give the -T flag to kdump and see the times of all the calls. I did not mean to suggest this is easy to resolve, but I think you are making progress. You might try to find the code that is doing the locking/closing and see what syscalls are made and then go read the POSIX specs for those and make sure the usage is legal.