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.
Related
Recently I ecountered situation where my WebSphere's admin console stop responding (tired to open it and got timeout). It happened after I've made some changes and saved them.
All the WebSphere application server and nodeAgent was working (checked in serverStatus.sh -all). I could still access my Web Application.
Is there a way to restart just admin console with a script or do I have to restart everything?
In my case the WebSphere works on linux.
I found a solution if someone will be interested. My dmgr process couldn't stop so I have to kill it manualy. Then I had to run startManager.sh script in IBM websphere dmgr location. It's done without restart the whole server.
What's the difference of amqsvc and strmqsvc?
I have installed IBM MQ and configured for multi instance. It uses amqsvc.exe to start the service as installed, the service is logon from a domain account, and the account is a member of group mqm.
It was working fine but yesterday for some unknown reason the service is not starting properly, here is what happened:
when amqsvc is run on automatic or manual, amqzxma0 runs on full cpu usage until timeout and windows prompted the service not starting with error 1053, but the MQ service is started, then I tried to start the queue manager but fail to start, however it can be started on interactive.
However I can start the service fine with strmqsvc and can start the queue manager normally. So what's the difference between these two and what is the problem behind it?
amqsvc is the actual windows service.
strmqsvc is the command used to start the above service.
The IBM v7.5 Knowledge Center documents the error 1053 as:
Windows: amqmsrvn.exe process removed
The amqmsrvn.exe DCOM process was replaced by a Windows service,
amqsvc.exe, in Version 7.1. This change is unlikely to cause any
problems. However, you might have to make some changes. You might have
configured the user that runs the IBM® WebSphere® MQ Windows service
MQSeriesServices without the user right to Log on as a service.
Alternatively, the user might not have List Folder privilege on all the subdirectories from the root of the drive to the location of the
service amqsvc.exe.
If you omitted the Log on as a service user privilege, or one of
the subdirectories under which IBM WebSphere MQ is installed does not
grant the List Folder privilege to the user, the MQ_InstallationName
IBM WebSphere MQ Windows services in Version 7.5 fails to start.
...
If you did not give the user the List Folder privilege, the Windows Service Control Manager adds an event: 7009: Timed out waiting for the
service to connect. The strmqsvc command reports error 1053.
Ensure that you have provided List Folder privilege on all the subdirectories from the root of the drive to the location of the service amqsvc.exe. This should resolve the issue.
I got a Glassfish 4.1.1 copy with two domains on Win2012R2 (no clusters, no instances). I've set a windows service for each of those.
Both services run regularly up until the moment when I restart either or both of them thru their admin web console (server (Admin Server) -> Restart). The following happens:
The domain-related service stops, but does not start again,
The allegedly stopped domain is perfectly functional (deployed apps and admin console are there) (!!!),
When I try to start the win service manually, I get Error 1067 (GF reports "something" is already listening on required ports and that's the domain itself that is now, somehow, NOT run as a service!),
I can start the service again only after I've stopped the domain thru server (Admin Server) -> Stop.
Why did I mention two domains? Because this does not happen when I have just one domain with its' service.
Domains do not share ports, only things in common are the JDK/JRE and general GF files.
Is this a bug in Glassfish or did I set something wrong?
This is a limitation, rather than a bug. The problem is that GlassFish has no way to tell whether or not it is running as a service (and, if it is, what the name of that service would be).
The restart command means that GlassFish is restarting itself, so Windows detects that the process it started has been terminated and shows the service as stopped, but GlassFish spawns a new JVM itself. It has no capability to tell Windows to start the service again.
Essentially, the behaviour you are seeing is expected.
After some more testing, I realized what was going on:
Glassfish is definitively capable of restarting its' own Windows service,
The thing that was happening is it takes GF a few seconds do this on its' own,
But, before GF domain could restart as a service, I clicked the URL to return to admin console, every time. That forced it to run as an ordinary executable.
It does seem like the restart happens faster with just one win service, but I won't claim that as an absolute truth without more testing, for which I have no time now.
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.
I have installed WebSphere portal in my local machine , it was running fine till now.Today i installed IBM HTTP server and suddenly my web sphere portal is not starting .
I have a WAS profile, web sphere portal server and ibm http server in my local machine which is running windows xp. All these are configured to run as windows service , now when i attempt to start the portal server i get below message:
WASService running at the same time for 'IBMWAS70Service -WebSphere_Portal_V$AIN' Service not started
Any input on this will be appreciated.
I restarted my machine and things worked fine :). Mostly likely there was some services created in windows services with same name or something of that sought which was rectified once i restarted my machine.