Teamcity build agent in disconnected state (Agent has unregistered (will upgrade)) on the server UI.
The build agent service was in hung state tried reboot but still didn't work so manually upgraded the TC build agent with the version server had. Rebooted the build agent service. Still disconnected. Please suggest.
I ran into this issue and found a solution, but I'm going to make a few assumptions about your setup.
This fixed an issue I had with a TeamCity build agent on Windows and running as a user account (as opposed to a System Account).
Stopped the TeamCity service and changed the account to a System Account
Started the TeamCity service and waited about 10 minutes for the upgrade to complete. The build agent showed up in the "Connected" agents tab indicating a successful upgrade.
Stopped the TeamCity service and switched back to the user account
Started the TeamCity service
The other option is to grant the user account permissions to start/stop services, but I went this route instead. See this article for those steps.
Old question but someone might find my comments useful. If you cant read the upgrade logs, check the buildAgent/update/ folder, If files and files sizes are changing in this particular folder then It means that the Agent is updating and you only need to wait. If this is not the case but you still see Agent has unregistered (will upgrade) in Team city under Agents --> Disconnected then the agent is either hung or there is some problem with it. Stop the agent from the services and then by running the agent.bat(Windows) and agent.sh (nix) by giving stop argument and then start it from the same script using start argument. You can also see the status of the agent using status argument. If this also does not work then you will have to read all the logs.
This worked for me:
In the Agents tab, I removed the build agent by clicking "Remove Agent".
I restarted the service.
I refreshed the Agents tab and it the build agent appeared in the Unauthorized Agents.
I authorized the agent and it's now connected.
For the one who kept restarting build agent service and see the "Agent has unregistered(will upgrade)", please check the log under BuildAgent/logs to see the upgrade process and wait.
I just encountered this problem too on Ubuntu Linux 19.10 and it is related to systemd. My TeamCity agents are started and stopped using a systemd script and apparently this is what prevents them from upgrading. When I stopped teamcity systemd services and started agents manually with agent.sh start agents successfully updated and worked just fine since that.
It could be the permissions on the account under which the agent is running. In BuildAgent\Logs\Upgrade.txt, you may find this
Upgrade failed: Failed to stop TeamCity build agent service. Please check TeamCity build agent service user have enough permissions to stop and start the service.
java.io.IOException: Failed to stop TeamCity build agent service. Please check TeamCity build agent service user have enough permissions to stop and start the service.
Although the service appears to be running fine on the machine (windows in my case), it produces the error in it's log rather than event viewer or failing to start, and disconnects from TeamCity on upgrade.
I gave higher privileges and it started to work. +1 to Lemtronix's way if you do not want to restrict permissions of your service account.
I had the same issue. I triggered a build and the agent was automatically changed to connected status.
Looks like the agent tries to upgrade itself, but if your Windows service is set up running from non-admin account, it fails.
Options are:
Temporary change service account to System as proposed by #Lemtronix
Add user to administrators group and restart service.
I resolved this issue with TeamCity 2019.2.4 on Windows Server 2016 by completing the following steps listed below:
Stop the TeamCity Build Agent service.
Stop the TeamCity Server service.
Start the TeamCity Server service.
Start the TeamCity Build Agent service.
Refresh the TeamCity UI tab in your browser window, and wait a few moments for the status to reflect Connected in green.
Changing the service user did not fix the issue for me :
but this method worked (Windows, with Teamcity server and agents on the same machine).
Stop these services : Teamcity server, all the Teamcity agents.
Open a cmd.exe instance as Administrator.
Run these (adapt to you own paths / number of agents). It will start Teamcity server and agents as simple processes (i.e. not as services) :
cd C:\Teamcity\bin
.\runAll.bat start
cd C:\Teamcity\BuildAgent1\bin
.\agent.bat start
cd C:\Teamcity\BuildAgent2\bin
.\agent.bat start
cd C:\Teamcity\BuildAgent3\bin
.\agent.bat start
Check in the UI that the agents have registered again.
Kill the processes created in 3. ; and start the Teamcity services again.
Related
I have a IBM WebSphere 8.5.5.13 ND on Windows 2016 standard edition with JDK 1.7 enabled. I see that, node agent and server1 (application server) are getting stopped everyday but the deployment manager is still up and running (i.e. admin console can be accessed). So, I have to start nodeagent and the associated server manually everyday. Investigation done so far
Checked if the windows servers are getting restarted everyday? No they are not
Checked nodeagent start and stop server logs but there are no entries to see, some command was issued for stopping
Checked application server profile (server1) logs but nothing is there.
FYI, I don't have clustering done on WAS but it is planned for the future.
I don't no where else I can look for the reason the node agent and server1 is getting stopped everyday.
okay, this is what I found out. In my case I have
Dmgr01 - registered under windows service
Node agent - not registered under windows service
application server - no need or never register application server if you have deployment manager
Since my node agent was not registered under windows service, whenever I log-off or my session is killed due to in-activity, the default behavior is that, all running processes (jave.exe) associated with WebSphere will be crashed and there will not be any trace of it. This is why, I was unable to find the any logs.
I registered my node agent as windows service and everything worked.
My company is using VSTS builds for continuous integration. Every commit triggers a build which runs on a Linux agent. The problems is after the build is finished, I need the agent to restart a service(which requires root). How can I automatically restart the service via the agent with minimal security risks?
You can add a new user to build agent machine and grant the necessary security to restart service, then configure/change the build agent running account to that user.
An article about deploying an agent on linux.
Currently, I am starting a container with bamboo remote agent on it and every time I need to manually approve the bamboo agent on the bamboo server. The idea is to automate the whole process starting with running a container which launches a bamboo remote agent and performs the build and then to kill the container. Since bamboo server expects manual approval, this is posing as a challenge. So I am looking for a way to auto approve the agent to register it.
Thank you!
I don't think there's an option to automatically auto-approve agents. Agent approval requirement is an security feature so auto approving any remote agent wouldn't be a security feature anyhow.
That being said, there's an option to disable agent authentication which will effectively mean that any new agent is approved right away -> actually what you're asking for.
You can disable agent authentication by visiting Bamboo administration pages
I'm using TFS Express and trying to set up the environment. I create the project and then it hangs saying its 'Waiting for Service to Start"
What service is it waiting for to start?
Check TFS Background Job Agent service is running or not.
Check Event log in Event Viewer to see whether there is useful information.
Scenario:
I set up successfully TFS2010 webdeploy task for solution. Everything worked fine until suddendly something went wrong in the deployment task.
Solution has 2 web projects..those are configured to deploy on build and publish it to the dev-server.
Does anybody have a knowledge what is wrong in build (information below)?
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
(3847): Web deployment task failed.
((4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer.)
(4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer. Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings.
I can give more information if someone needs it.
I encountered the same issue when building via TFS. When I tried to manually import the website I got a more informative error: "not able to log on the user \WDeployConfigWriter".
Turns out that when you install web deploy it sets up two local accounts WDeployConfigWriter and WDeployAdmin. The passwords on these accounts are set to expire. So reset the passwords on the web server and set to "never expire". Then go to Management Service Delegation in IIS. Each of the presented rules has a UserName field. Where it is WDeployAdmin or WDeployConfigWriter right click and update the credentials to the new passwords.
A full explanation with screenshots can be found here: http://workinghardinit.wordpress.com/2011/07/18/wdeployconfigwriter-account-issues-trouble-shooting-web-deploy-2-0-with-lessons-learned/
All you have to do is re-run the script "AddDelegationRules.ps1" located in "C:\Program Files\IIS\Microsoft Web Deploy V3\Scripts\"
This is the script that is run when web deploy is first installed. It will re-create any missing delegations, re-set the passwords for both WebDeployAdmin and WebDeployConfigWriter, and add WebDeployAdmin back to the Administrators group.
You would still need to set the password on each account not to expire after re-running the script.
We had the same issue-- in our case we are only using MSDeploy (without TFS). Resetting the password for those 2 local accounts (WDeployConfigWriter and WDeployAdmin) solved the problem as their passwords had expired. We attempted to change the password policy to never expire, but only a local Administrator can do that.
run this command lusrmgr.msc
double click on user and
double click the account name, and tick "password never expires".
Done.
In my case it was a botched install of Web Deploy.
Uninstalling then re-installing Web Deploy fixed it for me -- Repairing didn't help.