Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Just a "me too" comment. I'm using openjdk8 on NetBSD/amd64 for a wildfly gradle project in IntelliJ. Any attempt to use openjdk11 fails - wildfly starts but cannot accept any http connections - gradle build hangs - intellij randomly hangs/cannot connect debugger to running java
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
You could also try sdkman (link below) https://sdkman.io/ I have found that to work fairly consistently. On Tue, 12 Jan 2021, 2:54 pm ts1000, wrote: > Nope, did not try that yet. > My goal is to create a development environment > for java backend work > > That encompasses gradle, openJDK11 (cannot use openjdk8 for my project, > openJDK8 works with gradle by the way), IntelliJ IDE, postgres 12. > > Stuck on gradle at the moment. I tried kdump to see if I can pick up > anything, but the complexity and depth of interaction amongst OS, C/C++ > libraries, OpenJDK11, Gradle is just staggering. > > At this point, I know that OpenJDK8 works with gradle. > I also know that OpenJDK11 can run other java programs (eg KeyExplorer). > But Gradle is probably using something in OpenJDK11 that does not have a > correct implementation somewhere below. > > > On 2021-01-11 23:27, Martin wrote: > > Hey, > > Have you tried running Java through NetBSD's Linux compatibility > > layer. >
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hey, Have you tried running Java through NetBSD's Linux compatibility layer. I believe it's Suse Linux. I don't remember if NetBSD does it by default or not using pkgin, I know that FreeBSD will if your installing it via their package manager. On Tue, 12 Jan 2021, 6:57 am ts1000, wrote: > Sorry meant NetBSD9.1 not NetBSD9.2 > > On 2021-01-11 19:16, ts1000 wrote: > > FYI, if somebody is still interested in the openjdk11+gradle conundrum > > I retested today: OpenJDK11+Gradle still, unfortunately, does not work > > on NetBSD9.1 with most reset package release Q4-2020 > > > > > > On 2020-11-20 01:59, ts1000 wrote: > >> Hello, > >> wanted to bump up my question to see if anybody could help. > >> Also, if I may, I wanted to ask if this group is the right question > >> about using NetBSD as a development environment (using OpenJDK11 in my > >> case). Or if there are other forums more specialized for this topic. > >> > >> thank you in advance > >> > >> On 2020-11-07 18:08, ts1000 wrote: > >>> Wanted to check if anybody has gradle working with OpenJDK 11 on > >>> OpenBSD 9.1 > >>> I cannot get it to work at all. > >>> > >>> not even: > >>> > >>> gradle status > >>> or > >>> gradle init > >>> > >>> I have tried going back to Gradle versions that are over 1 year old, > >>> and still same issue > >>> > >>> > >>> [... ] >
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Nope, did not try that yet. My goal is to create a development environment for java backend work That encompasses gradle, openJDK11 (cannot use openjdk8 for my project, openJDK8 works with gradle by the way), IntelliJ IDE, postgres 12. Stuck on gradle at the moment. I tried kdump to see if I can pick up anything, but the complexity and depth of interaction amongst OS, C/C++ libraries, OpenJDK11, Gradle is just staggering. At this point, I know that OpenJDK8 works with gradle. I also know that OpenJDK11 can run other java programs (eg KeyExplorer). But Gradle is probably using something in OpenJDK11 that does not have a correct implementation somewhere below. On 2021-01-11 23:27, Martin wrote: Hey, Have you tried running Java through NetBSD's Linux compatibility layer.
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Sorry meant NetBSD9.1 not NetBSD9.2 On 2021-01-11 19:16, ts1000 wrote: FYI, if somebody is still interested in the openjdk11+gradle conundrum I retested today: OpenJDK11+Gradle still, unfortunately, does not work on NetBSD9.1 with most reset package release Q4-2020 On 2020-11-20 01:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue [... ]
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
FYI, if somebody is still interested in the openjdk11+gradle conundrum I retested today: OpenJDK11+Gradle still, unfortunately, does not work on NetBSD9.2 with most reset package release Q4-2020 On 2020-11-20 01:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue [... ]
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 22.11.2020 23:50, ts1000 wrote: Thank you. I noticed that when building openJDK11 there was an option to enable 'dtrace' support. I thought that dtrace is not ktrace, so I did not enable it. Should I first rebuild OpenJDK11 with dtrace support ? Not needed for sure. Dtrace is just there in system $ sudo dtrace -l | wc -l 52623 $ and not so bad compared to OpenIndiana $ sudo dtrace -l | wc -l │[19:37:58:322] [4591:0002] [INFO][com.freerdp.client.x11] - Closed from X1 83420 $ that stuff in OpenJDK can be additional support for probes and developers or specific Java probes as mentioned here on FBSD https://forums.freebsd.org/threads/dtrace-openjdk12.71470/ and here is related info too https://github.com/AdoptOpenJDK/openjdk-build/issues/1242 BTW it is a tool you have available on NetBSD, FreeBSDm OpenIndiana, Illumos, SmartOS, Apple (Xcode/Instruments), Solaris 10,11 and probably soon even on Windows https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace I found even some good material working even on Gradle, but not sure how much of that is applicable here, still Java comes from Sun/Oracle as well as Dtrace so not everything may be there https://www.oracle.com/technetwork/systems/hands-on-labs/hol-uncover-jdk8-secrets-dtrace-2798366.html On 2020-11-22 19:47, Bodie wrote: On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall _lwp_unpark_all
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Thank you. I noticed that when building openJDK11 there was an option to enable 'dtrace' support. I thought that dtrace is not ktrace, so I did not enable it. Should I first rebuild OpenJDK11 with dtrace support ? On 2020-11-22 19:47, Bodie wrote: On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall _lwp_unpark_all return 840syscall_lwp_setname entry 841syscall_lwp_setname return 842syscall_lwp_getname entry 843syscall_lwp_getname return 844syscall_lwp_ctl entry 845syscall_lwp_ctl return 1062syscall compat_60__lwp_park entry 1063syscall compat_60__lwp_park return 1150syscall _lwp_park entry 1151syscall _lwp_park return $ With predicate like /errno = 60/ you can get for start at least how many times it happens during your run without modifying anything and soon you will learn way more how to get details which will be very usable in your work anyway. Sure you can somewhat get some of the results with ktrace/ktruss, but as you saw digging out of those
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 22.11.2020 06:56, ts1000 wrote: Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. DTrace for the victory I would say ;-) Start with this one http://dlc.openindiana.org/docs/osol/20090715/DYNMCTRCGGD/html/chp-intro-5.html That example for rw.d works just fine at least on NetBSD current (but I think on 9.1 stable too) Those system calls to lwp are covered by available providers: $ sudo dtrace -l -P syscall | grep lwp 812syscall _lwp_create entry 813syscall _lwp_create return 814syscall _lwp_exit entry 815syscall _lwp_exit return 816syscall _lwp_self entry 817syscall _lwp_self return 818syscall _lwp_wait entry 819syscall _lwp_wait return 820syscall_lwp_suspend entry 821syscall_lwp_suspend return 822syscall _lwp_continue entry 823syscall _lwp_continue return 824syscall _lwp_wakeup entry 825syscall _lwp_wakeup return 826syscall _lwp_getprivate entry 827syscall _lwp_getprivate return 828syscall _lwp_setprivate entry 829syscall _lwp_setprivate return 830syscall _lwp_kill entry 831syscall _lwp_kill return 832syscall _lwp_detach entry 833syscall _lwp_detach return 834syscall compat_50__lwp_park entry 835syscall compat_50__lwp_park return 836syscall _lwp_unpark entry 837syscall _lwp_unpark return 838syscall _lwp_unpark_all entry 839syscall _lwp_unpark_all return 840syscall_lwp_setname entry 841syscall_lwp_setname return 842syscall_lwp_getname entry 843syscall_lwp_getname return 844syscall_lwp_ctl entry 845syscall_lwp_ctl return 1062syscall compat_60__lwp_park entry 1063syscall compat_60__lwp_park return 1150syscall _lwp_park entry 1151syscall _lwp_park return $ With predicate like /errno = 60/ you can get for start at least how many times it happens during your run without modifying anything and soon you will learn way more how to get details which will be very usable in your work anyway. Sure you can somewhat get some of the results with ktrace/ktruss, but as you saw digging out of those million lines is not exactly fun On 2020-11-22 03:02, Kamil Rytarowski wrote: I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hello, unfortunately I am not yet able to figure out what's wrong. I think there is something wrong with OpenJDK11 port for netbsd or some OS feature that it relies on, does not work as JDK 11 expects. I do not think there is a problem with Gradle, at all. I have tried Gradle 6.7 and the old 5.4 and they both work with OpenJDK8 on Netbsd 9.1 However, my source code needs at least OpenJDK11, so cannot use 8. I also tried running under root, just to see if there was something about permissions.. but no luck I ran gradle with --no-daemon, no luck either. I have rebuilt OpenJDK11 from pkgsrc, twice -- no luck I have installed OpenJDK11 by pkgin from binary repo -- no luck. I have changed my locale from C to UTF8 -- no luck. I have been looking at the output of kdump/ktrace all day today. Unfortunately I cannot spot anything that I could investigate further. There are over 1mln lines there just from ' gradle status'. Most are getttime calls, bunch of memory maps. Some timeouts, but I see them not just at the end of ktrace when it hangs, but also early on. So I am at loss at the moment. On 2020-11-22 03:02, Kamil Rytarowski wrote: I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue https://github.com/gradle/gradle/issues/15087 I am thinking that something might be wrong with my sysctl.conf or login.conf or something else. If there are suggestions on what to look for next, would very much appreciate. -- my sysctl.conf -- nbsd1$ cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ # # sysctl(8) variables to set at boot time. # Default on panic: dump core and reboot. See savecore(8) for information. # Switch this to 1 if you want to enter the kernel debugger on crashes # instead. See ddb(4) for an introduction and also try the "help" command # at the db> prompt. # If you understand the implication and want to change the behaviour before # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see options(4). ddb.onpanic?=0 # Default core name template: #kern.defcorename=%n.core # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 # Default tty/pty character queue sizes. Should be bumped to 32K or so if # used in networking (ppp/pppoe) kern.tty.qsize=32000 #v-start kern.ipc.shmmaxpgs=32768 kern.sbmax=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.init_win=10 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.init_win_local=10 net.inet.tcp.congctl.selected=cubic #this is invalid net.inet.ip.ifq.maxlen = 4096 net.inet.tcp.delack_ticks=5 kern.maxfiles = 10 kern.maxproc = 10044 kern.posix.semmax = 10128 #v-endnbsd1$ -- my login .conf -- staff:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=1024M:\ :maxproc-max=1044:\ :maxproc-cur=1024:\ :openfiles-cur=512:\ :openfiles-max=104512:\ :stacksize-cur=128M: :copyright=/dev/null: :ignorenologin:\ :requirehome@: -- ulimit -a -- time (-t seconds ) unlimited file (-f blocks ) unlimited data (-d kbytes ) 1048576 stack (-s kbytes ) 114688 coredump (-c blocks ) unlimited memory (-m kbytes ) 8022248 locked memory (-l kbytes ) 2674082 thread (-r threads ) 1024 process (-p processes ) 1024 nofiles (-n descriptors) 512 vmemory (-v kbytes ) unlimited sbsize (-b bytes ) unlimited -- java -version -- $ java -version openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
I just ran into it independently on NetBSD/amd64 current 9.99.x. On 20.11.2020 02:59, ts1000 wrote: > Hello, > wanted to bump up my question to see if anybody could help. > Also, if I may, I wanted to ask if this group is the right question > about using NetBSD as a development environment (using OpenJDK11 in my > case). Or if there are other forums more specialized for this topic. > > thank you in advance > > On 2020-11-07 18:08, ts1000 wrote: >> Wanted to check if anybody has gradle working with OpenJDK 11 on >> OpenBSD 9.1 >> I cannot get it to work at all. >> >> not even: >> >> gradle status >> or >> gradle init >> >> I have tried going back to Gradle versions that are over 1 year old, >> and still same issue >> >> https://github.com/gradle/gradle/issues/15087 >> >> >> I am thinking that something might be wrong with my sysctl.conf or >> login.conf or something else. >> If there are suggestions on what to look for next, would very much >> appreciate. >> >> >> -- my sysctl.conf -- >> >> nbsd1$ cat /etc/sysctl.conf >> #!/sbin/sysctl -f >> # >> # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ >> # >> # sysctl(8) variables to set at boot time. >> >> # Default on panic: dump core and reboot. See savecore(8) for >> information. >> # Switch this to 1 if you want to enter the kernel debugger on crashes >> # instead. See ddb(4) for an introduction and also try the "help" command >> # at the db> prompt. >> # If you understand the implication and want to change the behaviour >> before >> # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see >> options(4). >> ddb.onpanic?=0 >> >> # Default core name template: >> #kern.defcorename=%n.core >> >> # Number of kernel threads to use for NFS client >> #vfs.nfs.iothreads=4 >> >> # Default tty/pty character queue sizes. Should be bumped to 32K or so if >> # used in networking (ppp/pppoe) >> kern.tty.qsize=32000 >> >> #v-start >> kern.ipc.shmmaxpgs=32768 >> >> kern.sbmax=8388608 >> net.inet.tcp.sendspace=3217968 >> net.inet.tcp.recvspace=3217968 >> >> net.inet.tcp.init_win=10 >> >> >> >> net.inet.tcp.recvbuf_auto=1 >> net.inet.tcp.sendbuf_auto=1 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> >> >> net.inet.tcp.init_win_local=10 >> >> >> net.inet.tcp.congctl.selected=cubic >> #this is invalid net.inet.ip.ifq.maxlen = 4096 >> net.inet.tcp.delack_ticks=5 >> >> kern.maxfiles = 10 >> kern.maxproc = 10044 >> kern.posix.semmax = 10128 >> #v-endnbsd1$ >> >> -- my login .conf -- >> >> >> staff:\ >> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin >> /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ >> :umask=022:\ >> :datasize-max=infinity:\ >> :datasize-cur=1024M:\ >> :maxproc-max=1044:\ >> :maxproc-cur=1024:\ >> :openfiles-cur=512:\ >> :openfiles-max=104512:\ >> :stacksize-cur=128M: >> :copyright=/dev/null: >> :ignorenologin:\ >> :requirehome@: >> >> >> >> >> -- ulimit -a -- >> >> time (-t seconds ) unlimited >> file (-f blocks ) unlimited >> data (-d kbytes ) 1048576 >> stack (-s kbytes ) 114688 >> coredump (-c blocks ) unlimited >> memory (-m kbytes ) 8022248 >> locked memory (-l kbytes ) 2674082 >> thread (-r threads ) 1024 >> process (-p processes ) 1024 >> nofiles (-n descriptors) 512 >> vmemory (-v kbytes ) unlimited >> sbsize (-b bytes ) unlimited >> >> -- java -version -- >> $ java -version >> openjdk version "11.0.8-internal" 2020-07-14 >> OpenJDK Runtime Environment (build >> 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) >> OpenJDK 64-Bit Server VM (build >> 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed >> mode) signature.asc Description: OpenPGP digital signature
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
ts1000 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.
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 21.11.2020 19:59, ts1000 wrote: Greg, Bodie thank you for suggesting to look for ktrace.out, after running: ktrace -i gradle status Indeed the dump was there. Now I know how to use ktrace, at least supreficially. I ran kdump on it, got an ASCII and started looking for abnormalities. 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. 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. 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 And then the rest of the code, may be not releasing some lock/semaphore because the file is not accessible. Which is why I am seeing that any gradle commands just hang. That's my interpretation of what's going on. The whole trace file converted to ascii is like 98Mb with over 1mln lines. So cannot post it. But here is a short exerpt that I am using for the study: "org.gradle.cache.internal.DefaultFileLockManager" 15850 2 java RET write 48/0x30 15850 2 java CALL write(0xfe,0x7db1b97fb830,2) 15850 2 java GIO fd 254 wrote 2 bytes "] " 15850 2 java RET write 2 15850 2 java CALL write(0xfe,0x7db1b97fb7d0,0x2c) 15850 2 java GIO fd 254 wrote 44 bytes "Releasing lock on daemon addresses registry." 15850 2 java RET write 44/0x2c 15850 2 java CALL __gettimeofday50(0x7db1b97fda10,0) 15850 2 java RET __gettimeofday50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fc550) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL _lwp_unpark_all(0x7db1b9a400f8,1,0x7db1b9667a40) 15850 2 java RET _lwp_unpark_all 0 15850 2 java CALL write(0xfe,0x7db1b97fb6f0,1) 15850 13 java RET ___lwp_park60 0 15850 2 java GIO fd 254 wrote 1 bytes "\n" 15850 2 java RET write 1 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe850) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe6c0) 15850 2 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe5b0) 15850 12 java RET __clock_gettime50 0 15850 2 java RET fcntl 0 15850 2 java CALL __fstat50(0x111,0x7db1b97fe8e0) 15850 2 java RET __fstat50 0 15850 2 java CALL lseek(0x111,0,0,1) 15850 2 java RET lseek 17/0x11 15850 2 java CALL ftruncate(0x111,0,0x11) 15850 2 java RET ftruncate 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL lseek(0x111,0,0x11,0) 15850 13 java CALL __gettimeofday50(0x7db1981ffc10,0) 15850 2 java RET lseek 17/0x11 15850 12 java RET __clock_gettime50 0 15850 13 java RET __gettimeofday50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe8b0) 15850 2 java RET fcntl 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff8d0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe7c0) 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9a0) 15850 2 java RET fcntl 0 15850 13 java RET __clock_gettime50 0 15850 2 java CALL close(0x111) 15850 2 java RET close 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9c0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97feca0) 15850 13 java CALL mmap(0x7db19333,0x4,PROT_READ|PROT_WRITE,0x1012,0x,0,0) 15850 13 java RET mmap 138201632276480/0x7db19333 15850 2 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dbca0) 15850 2 java CALL write(0xfe,0x7db1b97fbd70,0x1c) 15850 12 java RET __clock_gettime50 0 15850 2 java GIO fd 254 wrote 28 bytes "2020-11-21T17:30:40.618+" 15850 2 java RET write 28/0x1c 15850 2 java CALL write(0xfe,0x7db1b97fbd70,2) 15850 2 java GIO fd 254 wrote 2 bytes " [" 15850 2 java RET write 2 15850 2 java CALL write(0xfe,0x7db1b97fbd70,5) 15850 2 java GIO fd 254 wrote 5 bytes "DEBUG" 15850 2 java RET write 5 15850 2 java CALL write(0xfe,0x7db1b97fbd70,3) 15850 2 java GIO fd 254 wrote 3 bytes "] [" 15850 2 java RET write 3
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 21.11.2020 19:59, ts1000 wrote: Greg, Bodie thank you for suggesting to look for ktrace.out, after running: ktrace -i gradle status Indeed the dump was there. Now I know how to use ktrace, at least supreficially. It's not a Linux. It's a BSD. Everything is in the system without need to look for it over Google ;-) https://man.netbsd.org/ktrace.1 I ran kdump on it, got an ASCII and started looking for abnormalities. 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. 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. https://man.netbsd.org/nls.7 and because you play with Java then maybe this one too https://www.oracle.com/database/technologies/faq-nls-lang.html but looking on current system there is just this: $ ls -l /usr/share/nls/nls* -r--r--r-- 1 root wheel 1520 Nov 20 21:01 /usr/share/nls/nls.alias $ files with .db added are often used on systems with huge files like this and turning them in tho this format makes them quicker for lookup and such so maybe if you will just create db version out of it with eg. https://man.netbsd.org/cap_mkdb.1 (not tested by me, but it is for getting idea) 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 again use perfect man pages ;-) https://man.netbsd.org/_lwp_park.2 And then the rest of the code, may be not releasing some lock/semaphore because the file is not accessible. Which is why I am seeing that any gradle commands just hang. That's my interpretation of what's going on. The whole trace file converted to ascii is like 98Mb with over 1mln lines. So cannot post it. But here is a short exerpt that I am using for the study: "org.gradle.cache.internal.DefaultFileLockManager" 15850 2 java RET write 48/0x30 15850 2 java CALL write(0xfe,0x7db1b97fb830,2) 15850 2 java GIO fd 254 wrote 2 bytes "] " 15850 2 java RET write 2 15850 2 java CALL write(0xfe,0x7db1b97fb7d0,0x2c) 15850 2 java GIO fd 254 wrote 44 bytes "Releasing lock on daemon addresses registry." 15850 2 java RET write 44/0x2c 15850 2 java CALL __gettimeofday50(0x7db1b97fda10,0) 15850 2 java RET __gettimeofday50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fc550) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL _lwp_unpark_all(0x7db1b9a400f8,1,0x7db1b9667a40) 15850 2 java RET _lwp_unpark_all 0 15850 2 java CALL write(0xfe,0x7db1b97fb6f0,1) 15850 13 java RET ___lwp_park60 0 15850 2 java GIO fd 254 wrote 1 bytes "\n" 15850 2 java RET write 1 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe850) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe6c0) 15850 2 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe5b0) 15850 12 java RET __clock_gettime50 0 15850 2 java RET fcntl 0 15850 2 java CALL __fstat50(0x111,0x7db1b97fe8e0) 15850 2 java RET __fstat50 0 15850 2 java CALL lseek(0x111,0,0,1) 15850 2 java RET lseek 17/0x11 15850 2 java CALL ftruncate(0x111,0,0x11) 15850 2 java RET ftruncate 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL lseek(0x111,0,0x11,0) 15850 13 java CALL __gettimeofday50(0x7db1981ffc10,0) 15850 2 java RET lseek 17/0x11 15850 12 java RET __clock_gettime50 0 15850 13 java RET __gettimeofday50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe8b0) 15850 2 java RET fcntl 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff8d0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe7c0) 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9a0) 15850 2 java RET fcntl 0 15850 13 java RET __clock_gettime50 0 15850 2 java CALL close(0x111) 15850 2 java RET close 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9c0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97feca0) 15850 13 java CALL mmap(0x7db19333,0x4,PROT_READ|PROT_WRITE,0x1012,0x,0,0) 15850 13 java RET mmap 138201632276480/0x7db19333 15850 2
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Greg, Bodie thank you for suggesting to look for ktrace.out, after running: ktrace -i gradle status Indeed the dump was there. Now I know how to use ktrace, at least supreficially. I ran kdump on it, got an ASCII and started looking for abnormalities. 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. 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. 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 And then the rest of the code, may be not releasing some lock/semaphore because the file is not accessible. Which is why I am seeing that any gradle commands just hang. That's my interpretation of what's going on. The whole trace file converted to ascii is like 98Mb with over 1mln lines. So cannot post it. But here is a short exerpt that I am using for the study: "org.gradle.cache.internal.DefaultFileLockManager" 15850 2 java RET write 48/0x30 15850 2 java CALL write(0xfe,0x7db1b97fb830,2) 15850 2 java GIO fd 254 wrote 2 bytes "] " 15850 2 java RET write 2 15850 2 java CALL write(0xfe,0x7db1b97fb7d0,0x2c) 15850 2 java GIO fd 254 wrote 44 bytes "Releasing lock on daemon addresses registry." 15850 2 java RET write 44/0x2c 15850 2 java CALL __gettimeofday50(0x7db1b97fda10,0) 15850 2 java RET __gettimeofday50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fc550) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL _lwp_unpark_all(0x7db1b9a400f8,1,0x7db1b9667a40) 15850 2 java RET _lwp_unpark_all 0 15850 2 java CALL write(0xfe,0x7db1b97fb6f0,1) 15850 13 java RET ___lwp_park60 0 15850 2 java GIO fd 254 wrote 1 bytes "\n" 15850 2 java RET write 1 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe850) 15850 2 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97fe6c0) 15850 2 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe5b0) 15850 12 java RET __clock_gettime50 0 15850 2 java RET fcntl 0 15850 2 java CALL __fstat50(0x111,0x7db1b97fe8e0) 15850 2 java RET __fstat50 0 15850 2 java CALL lseek(0x111,0,0,1) 15850 2 java RET lseek 17/0x11 15850 2 java CALL ftruncate(0x111,0,0x11) 15850 2 java RET ftruncate 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dcb60) 15850 2 java CALL lseek(0x111,0,0x11,0) 15850 13 java CALL __gettimeofday50(0x7db1981ffc10,0) 15850 2 java RET lseek 17/0x11 15850 12 java RET __clock_gettime50 0 15850 13 java RET __gettimeofday50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe8b0) 15850 2 java RET fcntl 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff8d0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL fcntl(0x111,F_SETLK,0x7db1b97fe7c0) 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9a0) 15850 2 java RET fcntl 0 15850 13 java RET __clock_gettime50 0 15850 2 java CALL close(0x111) 15850 2 java RET close 0 15850 13 java CALL __clock_gettime50(3,0x7db1981ff9c0) 15850 13 java RET __clock_gettime50 0 15850 2 java CALL __clock_gettime50(3,0x7db1b97feca0) 15850 13 java CALL mmap(0x7db19333,0x4,PROT_READ|PROT_WRITE,0x1012,0x,0,0) 15850 13 java RET mmap 138201632276480/0x7db19333 15850 2 java RET __clock_gettime50 0 15850 12 java CALL __clock_gettime50(3,0x7db1989dbca0) 15850 2 java CALL write(0xfe,0x7db1b97fbd70,0x1c) 15850 12 java RET __clock_gettime50 0 15850 2 java GIO fd 254 wrote 28 bytes "2020-11-21T17:30:40.618+" 15850 2 java RET write 28/0x1c 15850 2 java CALL write(0xfe,0x7db1b97fbd70,2) 15850 2 java GIO fd 254 wrote 2 bytes " [" 15850 2 java RET write 2 15850 2 java CALL write(0xfe,0x7db1b97fbd70,5) 15850 2 java GIO fd 254 wrote 5 bytes "DEBUG" 15850 2 java RET write 5 15850 2 java CALL write(0xfe,0x7db1b97fbd70,3) 15850 2 java GIO fd 254 wrote 3 bytes "] [" 15850 2 java RET write 3 15850 2 java CALL
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
On 21.11.2020 03:49, ts1000 wrote:
Thank you for the follow up in regards to gradle on openjdk11 with
NetBSD 9.1
0) Running NetBSD 9.1 amd64 within Virtual Box on windows host.
Allocated to it the box 8gb and 4 cores
the underlying disk (that vbox is using is an Intel SSD)
1) following your suggestion I installed openJDK8 from binary packages
(I use pkgin)
and:
gradle status
worked with that older version of the openJDK (I tried both the most
recent gradle 6.7 and older gradle 5.4 .. both work)
2) OpenJDK11 from binary packages the above command does not work
3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not
work either
it basically hangs as I described earlier, the full message dump is:
nbsd1$ gradle -d status
2020-11-21T02:11:20.275+ [DEBUG]
[org.gradle.internal.nativeintegration.services.NativeServices]
Native-platform is not available.
2020-11-21T02:11:20.549+ [INFO]
[org.gradle.internal.nativeintegration.services.NativeServices]
Initialized native services in: /home/v/.gradle/native
2020-11-21T02:11:20.623+ [LIFECYCLE]
[org.gradle.launcher.cli.DebugLoggerWarningAction]
#
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
WARNING
Debug level logging will leak security sensitive information!
https://docs.gradle.org/6.7/userguide/logging.html#sec:debug_security
#
2020-11-21T02:11:21.000+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Native-platform file system integration is not available. Continuing
with fallback.
2020-11-21T02:11:21.108+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Using Jdk7Symlink implementation as symlink.
2020-11-21T02:11:22.275+ [DEBUG]
[org.gradle.launcher.daemon.client.DaemonClient] Executing build
04bc315f-ebb4-4e65-b3f9-60b4eb16d648 in daemon client {pid=6432}
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface lo0
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? true
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding
loopback address /127.0.0.1
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface wm0
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? false
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote
address /10.0.2.15
2020-11-21T02:11:22.387+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.408+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.424+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.434+ [DEBUG]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Getting
daemon stop events
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.441+ [INFO]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry]
Removing 0 daemon stop events from registry
2020-11-21T02:11:22.448+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
exclusive lock on daemon addresses registry.
2020-11-21T02:11:22.454+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.467+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.476+ [LIFECYCLE]
[org.gradle.launcher.daemon.client.DefaultDaemonConnector] Starting a
Gradle Daemon (subsequent builds will be faster)
2020-11-21T02:11:22.657+ [DEBUG]
[org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon
args: [/usr/pkg/java/openjdk11/bin/java, --add-opens,
java.base/java.util=ALL-UNNAMED, --add-opens,
java.base/java.lang=ALL-UNNAMED, --add-opens,
java.base/java.lang.invoke=ALL-UNNAMED, --add-opens,
java.prefs/java.util.prefs=ALL-UNNAMED, -XX:MaxMetaspaceSize=256m,
-XX:+HeapDumpOnOutOfMemoryError, -Xms256m, -Xmx512m,
-Dfile.encoding=US-ASCII, -Duser.country=US,
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Thank you for the follow up in regards to gradle on openjdk11 with
NetBSD 9.1
0) Running NetBSD 9.1 amd64 within Virtual Box on windows host.
Allocated to it the box 8gb and 4 cores
the underlying disk (that vbox is using is an Intel SSD)
1) following your suggestion I installed openJDK8 from binary packages
(I use pkgin)
and:
gradle status
worked with that older version of the openJDK (I tried both the most
recent gradle 6.7 and older gradle 5.4 .. both work)
2) OpenJDK11 from binary packages the above command does not work
3) OpenJDK11 from my rebuild (using pkgsrc) the above command does not
work either
it basically hangs as I described earlier, the full message dump is:
nbsd1$ gradle -d status
2020-11-21T02:11:20.275+ [DEBUG]
[org.gradle.internal.nativeintegration.services.NativeServices]
Native-platform is not available.
2020-11-21T02:11:20.549+ [INFO]
[org.gradle.internal.nativeintegration.services.NativeServices]
Initialized native services in: /home/v/.gradle/native
2020-11-21T02:11:20.623+ [LIFECYCLE]
[org.gradle.launcher.cli.DebugLoggerWarningAction]
#
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
WARNING
Debug level logging will leak security sensitive information!
https://docs.gradle.org/6.7/userguide/logging.html#sec:debug_security
#
2020-11-21T02:11:21.000+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Native-platform file system integration is not available. Continuing
with fallback.
2020-11-21T02:11:21.108+ [DEBUG]
[org.gradle.internal.nativeintegration.filesystem.services.FileSystemServices]
Using Jdk7Symlink implementation as symlink.
2020-11-21T02:11:22.275+ [DEBUG]
[org.gradle.launcher.daemon.client.DaemonClient] Executing build
04bc315f-ebb4-4e65-b3f9-60b4eb16d648 in daemon client {pid=6432}
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface lo0
2020-11-21T02:11:22.298+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? true
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding loopback
address /127.0.0.1
2020-11-21T02:11:22.299+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP
addresses for network interface wm0
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Is this a
loopback interface? false
2020-11-21T02:11:22.300+ [DEBUG]
[org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote
address /10.0.2.15
2020-11-21T02:11:22.387+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.408+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.424+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.434+ [DEBUG]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Getting
daemon stop events
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.435+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.441+ [INFO]
[org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Removing
0 daemon stop events from registry
2020-11-21T02:11:22.448+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
exclusive lock on daemon addresses registry.
2020-11-21T02:11:22.454+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on
daemon addresses registry.
2020-11-21T02:11:22.467+ [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on
daemon addresses registry.
2020-11-21T02:11:22.476+ [LIFECYCLE]
[org.gradle.launcher.daemon.client.DefaultDaemonConnector] Starting a
Gradle Daemon (subsequent builds will be faster)
2020-11-21T02:11:22.657+ [DEBUG]
[org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon
args: [/usr/pkg/java/openjdk11/bin/java, --add-opens,
java.base/java.util=ALL-UNNAMED, --add-opens,
java.base/java.lang=ALL-UNNAMED, --add-opens,
java.base/java.lang.invoke=ALL-UNNAMED, --add-opens,
java.prefs/java.util.prefs=ALL-UNNAMED, -XX:MaxMetaspaceSize=256m,
-XX:+HeapDumpOnOutOfMemoryError, -Xms256m, -Xmx512m,
-Dfile.encoding=US-ASCII,
Re: Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
ts1000 writes: > wanted to bump up my question to see if anybody could help. > Also, if I may, I wanted to ask if this group is the right question > about using NetBSD as a development environment (using OpenJDK11 in my > case). Or if there are other forums more specialized for this topic. This is the right place. Perhaps people didn't reply because your original message said OpenBSD, and perhaps because nobody else is trying to use this. I would suggest trying with all the JDKs you can. There are 6 in pkgsrc. My other suggestions use ktrace try to understand what kind of shared memory is needed and perhaps incrase that explain what you did exactly. You didn't address if this is from pkgsrc or where you got JDK and gradle. signature.asc Description: PGP signature
Bump [q] gradle on NetBSD 9.1 (amd64) with OpenJDK 11 -- does not work
Hello, wanted to bump up my question to see if anybody could help. Also, if I may, I wanted to ask if this group is the right question about using NetBSD as a development environment (using OpenJDK11 in my case). Or if there are other forums more specialized for this topic. thank you in advance On 2020-11-07 18:08, ts1000 wrote: Wanted to check if anybody has gradle working with OpenJDK 11 on OpenBSD 9.1 I cannot get it to work at all. not even: gradle status or gradle init I have tried going back to Gradle versions that are over 1 year old, and still same issue https://github.com/gradle/gradle/issues/15087 I am thinking that something might be wrong with my sysctl.conf or login.conf or something else. If there are suggestions on what to look for next, would very much appreciate. -- my sysctl.conf -- nbsd1$ cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.8 2011/09/25 21:47:22 christos Exp $ # # sysctl(8) variables to set at boot time. # Default on panic: dump core and reboot. See savecore(8) for information. # Switch this to 1 if you want to enter the kernel debugger on crashes # instead. See ddb(4) for an introduction and also try the "help" command # at the db> prompt. # If you understand the implication and want to change the behaviour before # /etc/rc.d/sysctl is run, use the kernel option DDB_ONPANIC, see options(4). ddb.onpanic?=0 # Default core name template: #kern.defcorename=%n.core # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 # Default tty/pty character queue sizes. Should be bumped to 32K or so if # used in networking (ppp/pppoe) kern.tty.qsize=32000 #v-start kern.ipc.shmmaxpgs=32768 kern.sbmax=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.init_win=10 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.init_win_local=10 net.inet.tcp.congctl.selected=cubic #this is invalidnet.inet.ip.ifq.maxlen = 4096 net.inet.tcp.delack_ticks=5 kern.maxfiles = 10 kern.maxproc = 10044 kern.posix.semmax = 10128 #v-endnbsd1$ -- my login .conf -- staff:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R7/bin /usr/pkg/bin /usr/pkg/sbin /usr/local/bin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=1024M:\ :maxproc-max=1044:\ :maxproc-cur=1024:\ :openfiles-cur=512:\ :openfiles-max=104512:\ :stacksize-cur=128M: :copyright=/dev/null: :ignorenologin:\ :requirehome@: -- ulimit -a -- time (-t seconds) unlimited file (-f blocks ) unlimited data (-d kbytes ) 1048576 stack (-s kbytes ) 114688 coredump (-c blocks ) unlimited memory(-m kbytes ) 8022248 locked memory (-l kbytes ) 2674082 thread(-r threads) 1024 process (-p processes ) 1024 nofiles (-n descriptors) 512 vmemory (-v kbytes ) unlimited sbsize(-b bytes ) unlimited -- java -version -- $ java -version openjdk version "11.0.8-internal" 2020-07-14 OpenJDK Runtime Environment (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1) OpenJDK 64-Bit Server VM (build 11.0.8-internal+0-adhoc.pkgsrc.openjdk-jdk11u-jdk-11.0.8-10-1, mixed mode)
