Jenkins agent as Windows service starts and stops - windows

I am attempting to install a Jenkins agent as a Windows 10 service. I install the service with
jenkins-slave.exe install
and have configured the associated xml file, and the service appears to be properly installed. However, when I start the service, it stops immediately.
A jenkins-slave.wrapper.log file is generated, containing
2021-09-09 11:30:53,503 DEBUG - Starting WinSW in the CLI mode
2021-09-09 11:30:54,191 INFO - Installing the service with id 'JenkinsAgent'
2021-09-09 11:30:54,238 DEBUG - Completed. Exit code is 0
2021-09-09 11:31:02,164 DEBUG - Starting WinSW in the service mode
2021-09-09 11:31:02,211 INFO - Downloading: https://<jenkins-server>/jnlpJars/slave.jar to C:\jenkins-agent\slave.jar. failOnError=False
2021-09-09 11:31:02,321 INFO - Skipped downloading unmodified resource 'https://<jenkins-server>/jnlpJars/slave.jar'
2021-09-09 11:31:02,321 INFO - Starting java.exe -Xrs -jar "C:\jenkins-agent\slave.jar" -jnlpUrl https:/<jenkins-server>/computer/jetdamdev2/jenkins-agent.jnlp -secret <secret> -workDir "C:\jenkins-agent"
2021-09-09 11:31:02,336 DEBUG - Completed. Exit code is 0
This seems to indicate that the java process is started, but exits about 115ms later.
If I copy the java-launch line into a command-line terminal, it successfully connects to the Jenkins master and stays running.
I have been chasing this issue for quite a while now, with no success. Can someone please tell me what I have done wrong with the service and help me fix this?

I know I am late for the party, but maybe it comes handy for others:
I was following this article: https://hayato-iriumi.net/2019/05/23/how-to-install-jenkins-slave-as-windows-service/
I have faced the same problem with WinSW, and ended up wrapping the whole agent startup command line in a batch file, and run the batch from WinSW. So my jenkins-slave.xml looks like this:
<service>
<id>JenkinsSlave</id>
<name>Jenkins agent</name>
<description>This service runs an agent for Jenkins automation server.</description>
<executable>c:\jenkins\agent.bat</executable>
<logmode>rotate</logmode>
</service>
And agent.bat like this:
java -jar agent.jar -jnlpUrl http://<jenkins master URL>/jenkins-agent.jnlp -secret <secret> -workDir "c:\jenkins"
For me this solved the problem. I am stuck at an older, 2.319.1 version of Jenkins for legacy reasons.

Related

"Failed creating Java" when using Windows Services to start Cassandra

I have had Cassandra 3.11.1 up and running correctly with no Java issues. I've been trying to set it up as a service using Apache Commons Daemon as recommended in the install guide. I was able to install it as a service, but when I attempt to start the service through Windows Services Manager it fails. The log reads:
Commons Daemon procrun (64-bit) started
Running 'cassandra' service...
Starting Service...
Failed creating Java
ServiceStart returned 1
Run Service finished.
Through cassandra config I am pointing to the 64 bit daemon prunsrv application.
Since cassandra seems to be working perfectly on its own it seems like it's a problem with prunsrv, but I have no idea how to track that down. I've seen similar problems, but it always seems to be a 32 vs 64 bit issue or the wrong environment paths for cassandra. Those seem fine for me.
Thank you!

Windows Service created with apache commons not starting correctly and errors with path to jvm.dll not found

I am running a java program as a windows service on windows server 2019 build 1809.
I am using apache commons procrun to create a windows service.
This is my configuration to start a service
"C:\Users\Public\agent\commons-daemon-1.2.1-bin-windows\amd64\prunsrv.exe" //IS//ic^
--DisplayName "Agent"^ --Description "This is a Agent Windows Service."^
--Startup=auto^
--Install="C:\Users\Public\agent\commons-daemon-1.2.1-bin-windows\amd64\prunsrv.exe"^
--Jvm="C:\Users\Public\agent\jre\bin\server\jvm.dll"^
--Classpath "C:\Users\Public\agent\agent-jar-with-dependencies.jar"^
++Environment="PATH='C:\Windows\system32';'C:\Users\Public\agent\jre\bin'"^
--JavaHome="C:\Users\Public\agent\jre"^
--StartPath=C:\Users\Public\agent\^
--StartMode=jvm^
--StartClass=com.agent.int.Runner^
--StdOutput=C:\Users\Public\agent\service-stdout.log^
--StdError=C:\Users\Public\agent\service-stderr.log
When i start the service, it fails with below error
2020-06-26 07:27:52 Apache Commons Daemon procrun stderr initialized.
[2020-06-26 07:27:52] [error] [5716] Failed creating Java 'C:\Users\Public\agent\jre\bin\server\jvm.dll'.
[2020-06-26 07:27:52] [error] [ 5716] The specified module could not be found.
[2020-06-26 07:27:52] [error] [ 5716] ServiceStart returned 1.
[2020-06-26 07:27:52] [error] [ 5716] The specified module could not be found.
Note - jvm.dll has correct path in configuration and in error log as well.
My configurations
apache commons procrun is 64 bit
JRE which i am supplying is also 64 bit
Windows server is also 64 bit
Let me know if any other details required
Thanks in advance.
I was not able to find root cause of the issue.
The way i solved the issue is i changed StartMode from jvm to Java.
--StartMode=Java
It worked on Windows 2016 Server, Windows 2019 Server and Windows 10 workstation.
Let me know if anyone has a reason for why it didn't work with jvm option.
We faced a similar issue lately and the root cause seemed to be a missing or too old installation of the Microsoft Visual C++ Redistributable package:
https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads
After installation/update of the package services could be started with --StartMode=Jvm again.

Error while starting dmgr of websphere in Solaris

Hi I tried the below command to start the dmgr.
~Websphere/Appserver/profiles/CORPDWAS70DepMgr/bin
$ ./startManagaer.sh
I got the below error.
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/CORPDWAS70DepMgr/logs/dmgr/startServer.log
ADMU0128I: Starting tool with the CORPDWAS70DepMgr profile
ADMU3100I: Reading configuration for server: dmgr
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3011E: Server launched but failed initialization. startServer.log,
SystemOut.log(or job log in zOS) and other log files under
/opt/IBM/WebSphere/AppServer/profiles/CORPDWAS70DepMgr/logs/dmgr
should contain failure information.
I opened the systemout.log
I am unable to understand the error.
Please help.

Develop a new Opendaylight application which includes nc-mount

I'm new to develop Opendaylight(ODL) applications. I'm planning to develop our application, which interacts Netconf devices. So, I expect using nc-mount. However, I can't develop application now because there are some problems.
I've tried the follows so far:
I tried the tutorial. I made the example application following this, but I didn't know how to install nc-mount into startup-archetype.
And currently, I tried this tutorial again after Neon released, but the build was failed.
I think that maybe there is some trouble on the repository now.
In order to know the behavior of nc-mount, I confirmed netconf repository. I've checked out release/fluorine-sr2 and the build succeeded. I've confirmed existing of netconf-connector-all. But Netconf testtool was not worked correctly... So that, I cannot confirm the behavior of nc-mount...
Also, I don't know how to import own application into ODL controller even if I've read this document.
Questions are the follows:
About the development of applications:
Do you know recommended ways to develop the application including nc-mount?
Or, If you know the proper documents, please let me know...
About Netconf testtool:
Have you had the same experience when you use Netconf testtool?
The build succeeded. But probably the tool was not worked correctly.
If you have some solution to solve this problem, please let me know...
Netconf testtool starting logs and ssh connection logs are the follows:
$ java -jar netconf-testtool-1.7.0-SNAPSHOT-executable.jar &
[1] 13108
15:22:07.155 [main] INFO o.o.n.t.tool.NetconfDeviceSimulator - Starting 1, SSH simulated devices starting on port 17830
15:22:07.199 [main] INFO o.o.n.t.tool.NetconfDeviceSimulator - Custom module loading skipped.
15:22:08.254 [main] INFO o.o.n.t.tool.NetconfDeviceSimulator - using OperationsProvider.
15:22:08.543 [main] INFO o.a.s.c.u.s.b.BouncyCastleSecurityProviderRegistrar - getOrCreateProvider(BC) created instance of org.bouncycastle.jce.provider.BouncyCastleProvider
15:22:08.684 [main] WARN io.netty.bootstrap.ServerBootstrap - Unknown channel option 'SO_BACKLOG' for channel '[id: 0x10ab3fa2]'
15:22:08.875 [main] INFO o.o.n.t.tool.NetconfDeviceSimulator - All simulated devices started successfully from port 17830 to 17830
$ ssh admin#localhost -p 17830 -s netconf
15:22:30.832 [sshd-netconf-ssh-server-nio-group-thread-1] WARN o.a.s.s.session.ServerSessionImpl - exceptionCaught(ServerSessionImpl[null#/0:0:0:0:0:0:0:1:48026])[state=Opened] SshException: sendKexInit() no resolved signatures available
15:22:30.835 [sshd-netconf-ssh-server-nio-group-thread-1] INFO o.a.s.s.session.ServerSessionImpl - Disconnecting(ServerSessionImpl[null#/0:0:0:0:0:0:0:1:48026]): SSH2_DISCONNECT_HOST_KEY_NOT_VERIFIABLE - sendKexInit() no resolved signatures available
Received disconnect from ::1 port 17830:9: sendKexInit() no resolved signatures available
Disconnected from ::1 port 17830
If you need more information to answer my questions, please let me know.
I really expect using Opendaylight, but it is too difficult to develop own ODL apps. I'm confused because there are so many documents... However, I'll be earnest to ODL App development.
Any help would be greatly appreciated.
For your second question about netconf test tool, you can check this recent thread: https://lists.opendaylight.org/pipermail/netconf-dev/2019-April/002116.html

TeamCity Build Agent won't upgrade

We are trying to setup a build agent and every time we start it the log shows the following messages:
[2012-09-18 12:52:01,805] INFO - jetbrains.buildServer.AGENT - Starting agent shutdown sequence, reason: Restart agent, failed to download upgrade from server
[2012-09-18 12:52:01,821] INFO - jetbrains.buildServer.AGENT - Host configuration for downloading updates: HostConfiguration[host=http://localhost:8000]
[2012-09-18 12:52:01,821] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/teamcity-agent.xml ==> E:\buildAgent\temp\m8a1mAwTuLIngev3yRUMPUuaYWZFmMSh
[2012-09-18 12:52:01,849] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/agentSystemInfo.zip ==> E:\buildAgent\update\plugins\agentSystemInfo.zip
[2012-09-18 12:52:01,880] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/amazonEC2.zip ==> E:\buildAgent\update\plugins\amazonEC2.zip
[2012-09-18 12:52:01,921] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/ant.zip ==> E:\buildAgent\update\plugins\ant.zip
[2012-09-18 12:52:02,056] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/antPlugin.zip ==> E:\buildAgent\update\plugins\antPlugin.zip
[2012-09-18 12:52:02,078] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/assembly-info-patcher.zip ==> E:\buildAgent\update\plugins\assembly-info-patcher.zip
[2012-09-18 12:52:02,098] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/clearcase-agent.zip ==> E:\buildAgent\update\plugins\clearcase-agent.zip
[2012-09-18 12:52:02,106] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/commandLineRunner.jar ==> E:\buildAgent\update\plugins\commandLineRunner.jar
[2012-09-18 12:52:02,118] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/coveragePlugin.zip ==> E:\buildAgent\update\plugins\coveragePlugin.zip
[2012-09-18 12:52:02,151] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/crashDetector.zip ==> E:\buildAgent\update\plugins\crashDetector.zip
[2012-09-18 12:52:02,163] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/cvsAgent.zip ==> E:\buildAgent\update\plugins\cvsAgent.zip
[2012-09-18 12:52:02,183] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/dotCover.zip ==> E:\buildAgent\update\plugins\dotCover.zip
[2012-09-18 12:52:02,308] INFO - jetbrains.buildServer.AGENT - Downloading http://localhost:8000/update/plugins/dotNetPlugin.zip ==> E:\buildAgent\update\plugins\dotNetPlugin.zip
[2012-09-18 12:52:03,830] INFO - agent.impl.AgentPortFileWriter - Delete agent runtime file from E:\buildAgent\logs\buildAgent.port
[2012-09-18 12:52:03,831] INFO - jetbrains.buildServer.AGENT - Unregistering from build server: 5
Has anyone seen anything like this before? We've looked at the server logs and aren't seeing anything on them to indicate what could be wrong.
I ran into the same issue. Both the build agent and the server are installed on Windows Server 2012.
I stopped the build agent service and deleted the logs from BuildAgent\logs and restarted the build agent service so I could see a fresh log.
upgrade.log showed me that the build agent received a call from the teamcity server to upgrade. The log also showed the following:
"Please check TeamCity build agent service user have enough permissions to stop and start the service."
Using the Local Security Policy, I granted the build agent service user "logon as a service" rights but this is not sufficient to start and stop a service. By default, only members of the Administrators group can start, stop, pause, resume or restart a service. After I added the build agent service user to the Administrator group and restarted the build agent service, the upgrade finished successfully and the agent connected again.
Alternatively, as described by BatteryBackupUnit and https://web.archive.org/web/20171019005501/http://windowsitpro.com/security/letting-user-start-and-stop-services-without-granting-user-administrator-privileges, it's possible to give the TeamCity Windows user account the start, stop and pause permissions on the TeamCity Build Agent service. The article says that something like
subinacl /service spooler /grant=contoso\cortana=top
will suffice.
Or, if you don't want to use a tool that Microsoft no longer makes available, then you can use Process Explorer, as described at https://superuser.com/a/315709/12337.
I had this problem when running the agent with systemd on Ubuntu 18.04. The agent exits with code 143 when upgrading and this is interpreted as an error. It needs to be added to the list of acceptable error codes with SuccessExitStatus=143 0
Here's the full configuration:
[Unit]
Description=TeamCity Build Agent
After=network.target
[Service]
Type=forking
RemainAfterExit=yes
PIDFile=/build-agent/logs/buildAgent.pid
ExecStart=/build-agent/bin/agent.sh start
ExecStop=/build-agent/bin/agent.sh stop
User=build
Group=build
Restart=on-failure
RestartSec=5s
# agent will exit with 143 during upgrade process
SuccessExitStatus=143 0
[Install]
WantedBy=multi-user.target
The TeamCity build agent can sometimes take a long time to upgrade. If you believe that the upgrading takes too long with no positive results do as follows:
Uninstall the build agent
Download the build agent pack from your server
Reinstall the agent
Upgrading process should go faster after this. If it does not help it is better to contact JetBrains tech support.
A really simple way of doing this if your enterprise security policy doesn't allow you to add users to the 'Administrators' group, but the user your logged on as does have elevated rights. Stop the service running, via the Services.msc and then open a command prompt (with elevated rights) in the agent bin directory and run
agent.bat start
Let the agent update with this user and then once it has finished and you can see it successfully registered in the Teamcity UI. Kill the processes and restart the Service.
If you're using a "jailed" build user like we are, you'll see "Please check TeamCity build agent service user have enough permissions to stop and start the service."
There are workarounds but no graceful solution to this. Here's why:
Workaround 1: "TCBuildAgent" service needs "jailed" needs start/stop service credential access assigned to it. SubinACL is your best tool for assigning this (lengthy but full discussion).
TeamCity removes "TCBuildAgent" and installs a new one, effectively eliminating the service credentials assigned to it. So, you must issue SubinACL grant access commands every time you upgrade. Clumsy and annoying
Workaround 2: Aforementioned tip of adding "jailed" to Administrators group is viable and permits a proper upgrade, though violates the concept of a "jailed" user.
After much fiddling with SubinACL, I've thrown in the towel and just temporarily add "jailed" to Administrators group for the upgrade process then remove it afterward.
I trust that Jetbrains isn't gonna do something awful and malicious with TCBuildAgent... not during upgrade, anyway ;)
I had a similar problem. helped me to reinstall the antivirus.
http://devnet.jetbrains.com/thread/440728
Stop the agent:
./agent.bat stop
Reinstall agent.
Start the agent:
./agent.bat start

Resources