I was able to install and run jenkins on my linux subsystem in Windows 10.
It listens on 8082.
But unfortunately, for an unknown reason, it hangs up infinitely after a few minutes (or to be precise after a I've made a change in a job config and execute a build).
Then, I checked in the terminal:
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
root#jup1t3r /h/navds# service jenkins stop
Correct java version found
* Stopping Jenkins Automation Server jenkins
...done.
root#jup1t3r /h/navds# service jenkins status
Correct java version found
2 instances of jenkins are running at the moment
but the pidfile /var/run/jenkins/jenkins.pid is missing
So there is no way to stop Jenkins. How can I restart it ?
Related
I've had this problem where I send a job to one of my nodes and sometimes the job would stuck on
[EnvInject] - Loading node environment variables.
The issue started when I moved my Jenkins machine from Amazon EC2 to Azure VM. Everytime it occured, I have stopped and relaunched the agent on the node, just so in a few minutes/hours it would freeze again. Usually I would stop the job after a few minutes, but if I let it run, in ~15 minutes I would receive the following:
FATAL: java.io.IOException: Unexpected termination of the channel
I have tried the following solutions, but with no help:
Rename the job
Create a new job (which runs just a basic command)
Uncheck the 'Use TCP_NODELAY flag on the SSH connection'
Adding '-Dhudson.slaves.ChannelPinger.pingInterval=2' to the JVM options
My architecture at the time was:
Jenkins as docker container on Azure VM (Ubuntu 18.04)
Jenkins ver 2.202
SSH Build Agents plugin version 1.31.1
Node on MacOS Mojave
The solution that sort of solved the problem, (now it occurs once in a few days, or even better) was adding ClientAliveInterval 120 to /etc/ssh/sshd_config and relaunch the com.openssh.sshd
sudo launchctl stop com.openssh.sshd
sudo launchctl start com.openssh.sshd
I'm running a java test suite on a windows jenkins agent with gradle
When it's running, the jenkins master is reporting this
Starting a Gradle Daemon, 84 busy and 2 stopped Daemons could not be reused, use --status for details
Here's the command it's running
cmd.exe /C "C:\development\jenkins\apppath\gradlew.bat -DenvName=testserver -DenvDriver=ie -PenvName=testserver -PenvDriver=ie regression && exit %%ERRORLEVEL%%"
The number of busy gradle daemons keeps increasing, and I think is affecting the performance of the tests, they keep taking longer and longer.
If I go onto the windows slave and run
C:\development\jenkins\apppath\gradlew.bat --status
It shows as 0 gradle daemons running or busy.
I need to be able to stop all those busy daemons.
Anyone got any ideas how to achieve this?
I've tried restarting the jenkins agent and the master, to no avail.
I've also tried running the following command on the windows agent, still no luck
WMIC PROCESS where "Name like 'java%' AND CommandLine like '%GradleDaemon%'" Call Terminate
The session logging we have in {{/etc/profile}} can interfere with services that launch sub-shells as new users - specifically, it always launches an interactive terminal, regardless of the context, which can cause certain key processes (e.g. Jenkins) from being able to perform critical tasks.
We had a Jenkins version upgrade and after hte upgrade, Jenkins seems to not be able to restart. Here’s what’s happening
```ubuntu#hoatname:~$ sudo service jenkins status
Correct java version found
Jenkins Automation Server is not running
ubuntu#hostname:~$ sudo service jenkins start
Correct java version found
Starting Jenkins Automation Server jenkins jenkins#hostname:~$
jenkins#hostname:~$
jenkins#hostname:~$ sudo service jenkins status
[sudo] password for jenkins:
jenkins#hostname:~$ exit
exit
[fail]
ubuntu#hostname:~$
```
Essentially, it seems that “service jenkins start” is somehow causing a session to be created, which dumps it into a script. I suspect this is due to how /etc/profile contains a script-based session logger, and i suspect that Jenkins is attempting to execute this script when it su’s into its own jenkins user
What should I do to alleviate this?
I have setup a lot of jobs while Jenkins is running as windows service.When i try to start Jenkins from command line , none of the jobs are showing up.
Can some one let me know how to make sure all jobs are loaded when i start Jenkins from CLI on windows machine.
Make sure you have the same Jenkins home directory when you run it from CLI.
You can use JENKINS_HOME variable to control that:
set JENKINS_HOME=C:/myJenkins
java -jar jenkins.war
I'm trying to get a Jenkins slave to open a session on a windows server.
Basically, What I'm try to achieve is:
Jenkins slave is running as a service on a windows 2003 server. When master calls slave, it will open a desktop session on the server and kick off an .exe that will perform GUI testing
What I have done:
Jenkins node created (Node A). Dumb slave. Remote FS root set to path on Windows 2003 server. ("C:\Jenkins\Node"). Launch method Java Web Start
Slave 'Node A' installed from Jenkins master using Java Web Start on windows 2003 server
Jenkins slave now running as a service on server
Jenkins project created and 'Restrict where this project can be run' is set to 'Node A'
Project windows batch command 'C:\GUITest.exe'
When I build the project in Jenkins I was expecting that the slave would be able to open a session and run C:\GUITest.exe. But, I'm missing something.
Anyone any ideas, or know if it is possible (plugins I may need ??)
Any advise / direction much appreciated.
Looks like you want to run GUI test on windows session. It won't work if you run Jenkins Slave as service, you have to run JNLP agent on your windows server. Also if you want to run in unattended mode, meaning that the windows remote session would be disconnected, you need some other setup as well. Please provide more information on what you are trying to do.
You must ensure that whatever process runs the GUI tests (might be a java / cmd / ssh process if you're connected to Jenkins) is not running on session 0 as it won't have access to Desktop and the Windows UI in general. I was in a similar situation and running the same process as a scheduled task instead of service solved it for me.