Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work

[Greg Troxel <gdt%lexort.com@localhost>]

ts1000 <ts1000%rad2know.net@localhost> 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.