whenever I try to run gradle I get this error:
`Starting a Gradle Daemon, 3 stopped Daemons could not be reused, use --status for details
FAILURE: Build failed with an exception.
What went wrong:
A new daemon was started but could not be connected to: pid=DaemonInfo{pid=15005, address=[0afc2481-e15f-4c14-ad0a-ab04bb464abe port:46235, addresses:[/127.0.0.1]], state=Busy, lastBusy=1673266156479, context=DefaultDaemonContext[uid=c8f84860-9dea-4853-8963-824fa63d8e54,javaHome=/usr/lib/jvm/java-17-openjdk-armhf,daemonRegistryDir=/home/pi/.gradle/daemon,pid=15005,idleTimeout=10800000,priority=NORMAL,daemonOpts=--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.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=UTF-8,-Duser.country=GB,-Duser.language=en,-Duser.variant]}, address= [0afc2481-e15f-4c14-ad0a-ab04bb464abe port:46235, addresses:[/127.0.0.1]]. See https://docs.gradle.org/7.5.1/userguide/troubleshooting.html#network_connection for more details.`
Everything was working fine until it suddenly broke without me making any changes in between.
I have tried the gradle troubleshooting guide, removing every gradle related file and reinstalling, different gradle versions, searching on the web also didnt give me any useful advice.
Any suggestions/ideas what might be causing this?
Related
I am trying to make a Minecraft mod. I have set the gradle.properties to use 3GB of ram. If I do this it is able to load the daemon process however it immediately displays
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/2.14/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Error occurred during initialization of VM
Could not reserve enough space for 3072000KB object heap
It is running out of RAM, and I have no idea why as I have 16GB installed.
I tried closing all other programs but got the same problem. Next up I changed the gradle.properties to use 1GB and then 2GB of RAM, and instead just got an error saying it ran out of memory (I googled this error and the common solution was to give it some more RAM)
* What went wrong: Execution failed for task ':decompileMc'. > Process 'command 'C:\Program Files (x86)\Java\jdk1.8.0_211\bin\java.exe'' finished with non-zero exit value 1
Francisco Mateo recommended I update my gradle version - sadly didn't help.
I tried changing the distributionUrl in the gradle-wrapper.properties to the new version of gradle I am using so it now reads distributionUrl=https\://services.gradle.org/distributions/gradle-5.5.1-bin.zip
I also tried running InteliJ as administrator. Still no luck.
Not a clue what is happening here - help appreciated. If it makes any difference the error occures at 10:08 of https://www.youtube.com/watch?v=RZ66HdNkank
When I was running the gradle clean command, I got the following message
Starting a Gradle Daemon, 1 busy and 6 stopped Daemons could not be
reused, use --status for details
For the investigation, I run the following command.
$ gradle --status
PID STATUS INFO
11506 BUSY 4.3.1
8027 STOPPED (stop command received)
9347 STOPPED (stop command received)
11727 STOPPED (by user or operating system)
4786 STOPPED (by user or operating system)
14569 STOPPED (by user or operating system)
31237 STOPPED (by user or operating system)
Only Daemons for the current Gradle version are displayed. See https://docs.gradle.org/4.3.1/userguide/gradle_daemon.html#sec:status
So, some questions have arisen in my mind.
How can I stop an existing daemon?
How to kill daemon process?
Stopping an existing Daemon:
If you want to explicitly stop running Daemon processes for any reason, just use the command gradle --stop.
Note: for your consideration the gradle --stop command won’t stop daemons running with a different version of Gradle.
How to kill all Daemon process on my machine?
Gradle will kill any Daemon that has been idle for 3 hours or more, so you don’t have to worry about cleaning them up manually.
Resource Link: Gradle Daemon Issue Details
So the command and output are given below:
$ gradle --stop
Stopping Daemon(s)
2 Daemons stopped
After stopping daemons, status will be look like below:
$ gradle --status
No Gradle daemons are running.
PID STATUS INFO
8027 STOPPED (stop command received)
9347 STOPPED (stop command received)
12448 STOPPED (stop command received)
11506 STOPPED (stop command received)
11727 STOPPED (by user or operating system)
4786 STOPPED (by user or operating system)
14569 STOPPED (by user or operating system)
31237 STOPPED (by user or operating system)
If you are stuck with gradle build running, you can to through this post: Stuck with Gradle Build Running
I solve it with another method in other post.
By removing folders like 4.4 4.6 5.4.1 5.5 in directory as below
/users/[username]/.gradle/daemon
java.lang.OutOfMemoryError: GC overhead limit exceeded
My problem solved only by changing gradle version from:
App\android\gradle\wrapper\gradle-wrapper.properties
old: distributionUrl=https://services.gradle.org/distributions/gradle-6.7-all.zip
new: distributionUrl=https://services.gradle.org/distributions/gradle-6.9-all.zip
just reboot ur computer then go to .gradle folder and delete the daemon folder
Just add two lines in your app -> Gradle Scripts -> gradle properties
org.gradle.daemon=true
org.gradle.parallel=true
For linux users
step 1 : cd ~ && rm -rf .gradle
step 2 : cd <to flutter working project directory>
step 3 : flutter run -v then kill process with ctrl+c .gradle dir will be created in /home/<user>/.gradle/wrapper/dists/gradle-<version>-all/9uukhhbclvbegdvsww0j0cr3p
step 4 : download gradle zip version on official website
step 5 : copy and paste the downloaded gradle inside /home/<user>/.gradle/wrapper/dists/gradle-<version>-all/9uukhhbclvbegdvsww0j0cr3p
step 6 : run flutter run -v
step 7 : everything is ok
I created a new flutter project and migrated the previous data to the new folder, now it's working perfectly
Happy coding guys...
I'm working on a fresh installation of stock DSpace 5.3 (Windows Server 2012, Tomcat 8.0, Maven 3.2.5, Ant 1.9.6). This particular instance will be a dark archive without Google Analytics enabled; we don't currently have a GA account or analytics key, although we plan to register one eventually for a separate public-facing instance.
As per the problem described in JIRA ticket DS-2718, DSpace hangs with the following message in dspace.log when I attempt to download a bitstream:
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# I/O exception (java.net.SocketException) caught when processing
request to {s}->https://www.google-analytics.com:443: Network is
unreachable: connect
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# Retrying request to {s}->https://www.google-analytics.com:443
Since we won't be using GA on this instance, disabling it in Spring is a good workaround until the issue is resolved. As per the instructions, I commented out the Google Analytics entry in dspace-5.3-src-release\dspace-xmlui\src\main\webapp\WEB-INF\spring\applicationContext.xml, disabled Tomcat and rebuilt DSpace. An initial attempt running mvn package -Dmirage2.on=true still produced the problem, so I tried a "ground up" rebuild:
cd d:\dspace-5.3-src-release\dspace
mvn clean package -U -Dmirage2.on=true
[successful build]
cd d:\dspace-5.3-src-release\dspace\target\dspace-installer
ant update
[successful update]
[copy webapps to Tomcat 8.0\webapps and start Tomcat]
Even after the rebuild, however, I'm still getting the same error, with the same java.net.SocketException in dspace.log.
Not sure why this isn't working. Have I missed a step or setting in the rebuild process so that the change to applicationContext.xml isn't being applied?
FWIW, I tried grepping for "google" in dspace-5.3-src-release\dspace-xmlui-mirage2 to see if this could be a Mirage 2 problem, but I don't see anything that looks relevant.
This isn't an answer to why you're still seeing the SocketException, but the real fix for the problem you're describing is to remove the default GA key from dspace-services/src/main/resources/config/dspace-defaults.cfg, see https://github.com/DSpace/DSpace/commit/5b84fef1ad789443d06c338558a92f854b20c8ef. Have you tried doing that?
The issue resolved itself after I ran mvn clean -Dmirage2.on=true in both [dspace-src] and [dspace-src]\dspace. I'm guessing that the issue originated on our end due to someone running a maven build from the wrong directory.
I've also removed the default key from dspace-defaults.cfg as suggested. Everything's now working.
I've been struggling with an annoying "Jenkins/Tomcat/Windows" problem for a while now without reaching any solution.
I've installed Tomcat version 7.0.25 in a Windows 7 Enterprise machine and Jenkins 1.451 as a webapplication
running under Tomcat. I have just 4 jobs configured right now and all of then are using the "Always chekout a fresh copy" checkout strategy,
so everytime a job runs the content in /jobs//workspace gets deleted. But, there are situations in which the job fails to run because
it is unable to delete the /jobs//workspace/pom.xml file like you can see in this (edited) stacktrace:
Building in workspace C:\.hudson\jobs\<task name>\workspace
Cleaning local Directory .
java.io.IOException: Unable to delete C:\.hudson\jobs\<task name>\workspace\.\pom.xml
at hudson.Util.deleteFile(Util.java:237)
at hudson.Util.deleteRecursive(Util.java:287)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:73)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745)
at hudson.FilePath.act(FilePath.java:788)
at hudson.FilePath.act(FilePath.java:770)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1409)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Retrying after 10 seconds
Here you can see Tomcat locking the file as I told:
After some time Jenkins/Tomcat releases the lock on the pom.xml and i can execute the job again without any problem.
Does anyone know how to get around this ? Am i missing something ? Thanks in advance!
I changed to Windows Service installation, and the pom.xml never gets locked anymore.
Seems that this caused by Tomcat that somehow locks the pom.xml, although the build has finished.
I downloaded Hudson, and am trying to install it as a service. I followed the steps from this page, but when I try to start the service, it always fails. I'm not really getting any defined error codes either. If I try to run the service from the command line (using net start) I get the following (unhelpful) message:
The hudson service could not be started.
The service did not report an error.
The install process seemed to work fine, as the hudson service is installed, and all the files are in the new directory, but the service won't start. Has anyone else run into this problem?
As documented on that page, they have a note of...
If a restart fails for some reason, check the output from Hudson, which is stored in the installation directory that you specified.
Is there anything to denote further errors?