Am using windows Jboss 7.10 final. For shutdown the jboss linux server commands are available, but I cannot able to find the commands for windows. Ctrl+C will terminate the process, but i require shutdown commands for windows. I have tried below mentioned commands but not working.
./jboss-cli.bat --connect controller=<IP>:<PORT> command=:shutdown
Hope below mentioned linux command will not work in windows version.
./jboss-cli.sh --connect command=:shutdown
I need to shutdown the server using IP and port level, because i am running more than one containers in the same server.
Help me to find the right one.
Thanks in advance!
The way that you stop JBoss depends on how it was started. This task covers stopping an instance that was started interactively, stopping an instance that was started by a service, and stopping an instance that was forked into the background by a script.
This task does not address stopping a server or server group in a Managed Domain. For those scenarios, see Section 2.8.3, “Stop a Server Using the Management Console”
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Stop_a_Server_Using_the_Management_Console1.html
Procedure 2.1. Task:
Stop an instance which was started interactively from a command prompt.
Press Ctrl-C in the terminal where JBoss Enterprise Application Platform 6 is running.
Stop an instance which was started as an operating system service.
Depending on your operating system, use one of the following procedures.
Red Hat Enterprise Linux
For Red Hat Enterprise Linux, if you have written a service script, use its stop facility. This needs to be written into the script. Then you can use service scriptname stop, where scriptname is the name of your script.
Microsoft Windows Server
In Microsoft Windows, use the net service command, or stop the service from the Services applet in the Control Panel.
Stop an instance which is running in the background (Red Hat Enterprise Linux)
Locate the instance from the process list. One option is to run the command ps aux |grep "[j]ava -server". This returns one result for each JBoss Enterprise Application Platform 6 instance that is running on the local machine.
Send the process the TERM signal, by running kill process_ID, where process_ID is the number in the second field of the ps aux command above.
Go to bin folder in the JBoss location
E.g. (In my PC) - Windows 8, 8.1 and 10
D:\Servers\jboss-4.2.3.GA\bin
Press Shift key in the keyboard and right click
Select Open Command Window Here
Then type, shutdown.bat -S and enter
It will take some to down the server and then you are good to go.
Related
My Python application has windows is client and server as Linux. My aim is to automate windows GUI application with pywinauto from Linux server.
Can pywinauto be made cross platform?
It's not possible using pywinauto immediately. But you may copy pywinauto script to the target Windows machine and run it remotely using Jenkins, for example. Or any other CI server. Master node can be on Linux. So Windows node can run as a slave. But there are several requirements for the Windows slave (this check list is based on my recent experience).
Windows slave can be set up with auto logon.
VNC server software (TightVNC or UltraVNC, for example) should be installed.
Video card drivers should be up-to-date for better screen resolution (and for black screen prevention).
Jenkins slave process must run as not a service (i.e. in the existing desktop, so Jenkins task would have an access to the GUI). Just do NOT click menu "Run as a service" in JNLP agent window.
Do not use Remote Desktop connection from another Windows machines (reboot may be required to restore GUI session with VNC client/server pair).
Of course, Python+pywinauto must be installed on Windows node. Just in case.
If UAC is enabled on Windows node, in some cases it should be disabled (if you have to deal with admin access like GUI installers do).
On Linux you need to set up the VNC client and Jenkins. For other CI servers steps may be similar but with some differences.
I have a jenkins agent set up on window 7 and a jenkins server on Linux. I am running GUI testing on the windows agent. It runs fine if I have a remote desktop connection connected to it, but fails otherwise. I found this link, Jenkins on Windows and GUI Tests without RDC
But the solution provided there is pretty vague.. It seems like the only solution is to somehow make Jenkins server to have a remote desktop connection open at all times. But I can't find such an option to do so.
Could anyone please clearly teach me how to solve this issue?
Much appreciated!
Your slave machines have to be at a desktop before the test can run
properly. We had the same problem.
Solution was to have the test machine start up and auto-logon to the
desktop. To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start. That way,
Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
This is the winning answer to the question you linked to and it is very clear on what to do. The whole setup is outside of Jenkins. Jason Swager discribed on how he automated a user logging into a windows desktop machine and then starting the Jenkins slave in the user session.
And now Step by step:
1. make sure you have a GUI evailable
Solution was to have the test machine start up and auto-logon to the desktop
Configure a standard Windows desktop to login a specific user automatically when windows start. This way nobody needs to physically log into the desktop. (see How to turn on automatic logon in Windows 7)
2. start Jenkins slave
You need to start the Jenkins slave within this user setting. Otherwise, the Jenkins slave won't have access to the Windows UI components (or in other words can not interact with the desktop).
To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start.
So you have to create a scheduled task and configure it to start your Jenkins client using Java Web Start.
3. use it
That way, Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
When the slave is online, you can use it to run your UI tests.
To solve it, set Windows Auto-Logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins slave (place it in Jenkins directory), which will launch it's console on desktop, and will allow GUI jobs to run:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
The following thing did the trick for me:
In Jenkins execute windows shell command:
cmdkey /generic:TERMSRV/<servername> /user:<username> /pass:<password>
mstsc /v:<servername> /w:<width> /h:<height>
cd <path to your pom.xml>
<maven command>(e.g. mvn test -Dfiles_to_run=groupLaunch.xml
cmdkey /delete:TERMSRV/<servername>
It creates real mstsc session (Win-to-Win) with specified width and height in your virtual mstsc session (Jenkins-to-Win) powered by Jenkins.
I tried the solutions provided here but nothing worked for me. At the end, I came up with a workaround.
I opened an RDP connection to the VM in a different VM (VM2).
I left the first connection open inside VM2 and disconnected from it.
It worked but that implies having two virtual machines available.
You still need to use RDP but in my case, we can use loopback of the RDP in same VM.
The procedure:
In a VM, create two different accounts, and create Jenkins slave for both of account.
Now you'll have two Jenkins slave for two accounts in one VM
slave 1 - account 1
slave 2 - account 2
Enable multiple RDP follow guide
https://www.serverwatch.com/server-tutorials/how-to-enable-concurrent-remote-desktop-sessions-in-windows.html
In slave 2(with account 2), run rdp command to connect to slave 1(with account 1), like following
Start /b "" "C:\RDP\rdp.exe" /v:127.0.0.2 /domain:\ /u:admin /p:xxxx /fullscreen /w:1920 /h:1200
127.0.0.2 is very important, it's a loopback connection for RDP
Put above command into Jenkins job with the name such as "OpenRDP_ToVMXXX, and then you can run any test on slave 1 with GUI enabled, enjoy.
As the solutions above seemed a bit overkill, I used this approach:
Disable Jenkins service
Start Jenkins from command line using java -jar C:\Program Files (x86)\Jenkins\jenkins.war
For some reason I had to install all plugins and everything when starting it this way, so I recommend creating a backup, there is a plugin for that. Good luck. :)
very quick question regarding an issue I never seen before. I've being using RAD 6 for java development, with Websphere portal server 5.0 installed. When I trying to start the server, I get the following error in a popup:
Which none of what's described is the true in my case...and still the case even though I rebooted the PC, as well as checking for any redundant javaw.exe processes.
Thanks for you help
I asked a colleague, they suggested that you have a server set up which is defined to run as a service. Since the service will start automatically with Windows, rebooting won't help.
Check your services.msc and see if there's a service for WebSphere, then try stopping it and starting your server from within RAD.
Do one thing, if it's possible. Just go to running programs and check for any java.exe and stop/delete all of them. And try restarting your server. And check if it makes any sense.
Hope it helps.
//HP
Start command prompt (if you're on Windows Vista and up, ensure you start it in admin mode).
Type:
netstat -a -b
This will show you all ports being listened. Look for 9081, and then you'll be able to see the process that is capturing that port.
Which process was it?
An easiest way to do so is kill the jawa/javaw process from the taskmanager.
And then start the server.
Hi i am very new to Jprofiler & Linux.
I am trying to Monitor my Apache Tomcat server installed on a linux machine from Jprofiler remote profiling which is installed on windows machine. Kindly help me in the procedure in detail.
I tried all the Help i could get from google but still stuck..any help will is appreciated. Thanks in advance.
In any case, you should extract the JProfiler tar.gz file for Linux on the remote machine. No further configuration is required on the remote side. On the local side you need a full installation of JProfiler.
There are two ways to get remote profiling to work:
A. Attach to the running Tomcat process
Execute the command line utility bin/jpenable in the JProfiler distribution on the remote machine and select the Tomcat process. The JVM will then be ready for profiling. If the profiled JVM is not listed, execute jpenable as the same user that runs the Tomcat JVM. If that does help, use alternative B.
On the local machine, create a session of type "Attach to profiled JVM (local or remote)", specify the host name of the remote machine and the profiling port that was set with jpenable.
When you start session, the JProfiler GUI will connect to the remote machine and you will see profiling data.
B. Use the integration wizard
Execute the command line uutility bin/jpintegrate in the JProfiler distribution on the remote machine and select your application server and follow the subsequent steps.
Then, proceed as in alternative A. This option is actually preferable to alternative A and unless you have to profile an already running JVM, you should take this route.
I want to get a heap dump (suspected memory leak) of a certain Java process. However, when I start the jvisualvm tool, I cannot see any of the running Java processes.
I have Google'd around about this and have already found a couple of articles saying that you have to run the Java processes using the same JDK that you start the jvisualvm tool with in order for it to be able to see them. However, as far as I can see, this is already the case. I'm doing everything locally (I have remote access to the machine).
A couple of things to consider:
The processes are running on a firewalled Windows 2008 server
The processes are running using renamed versions of the JDK java.exe executable
As far as I can see the processes are running using the 1.6.0_18 JDK
One of the running processes starts an RMI registry
I'm waiting on a virtualized copy of the server so I can mess around with it (this is a production server). But in the meanwhile; any ideas as to why I cannot see any of the processes in jvisualvm (or jconsole for that matter)?
Well after I did a little research, it would appear that Peter's comment was correct. Because the JVM processes were launched by another user (the NETWORK SERVICE account because they were being started by a Windows service) they didn't show up in jvisualvm.
Workaround
Since I have access to the application configuration, I have found the following workaround, which involves explicitly enabling unsecured JMX for the target JVM:
Add the following JVM parameters:
-Dcom.sun.management.jmxremote.port=3333 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
Add the remote process to jvisualvm using JMX by click File -> Add JMX Connection. You can connect to the process using port 3333. Obviously you can change the port if you want.
Link to article explaining this in a little more detail: http://download.oracle.com/javase/6/docs/technotes/guides/visualvm/jmx_connections.html
Notes
It's probably not a good idea to keep the JVM settings permanently, as they would allow anyone to connect to the JVM via JMX.
You can also add authentication to the JMX JVM parameters if you want to.
The simplest way is to execute jvisualvm as administrator (win: "run as administrator"). Which is not ideal but works. All java processes are visible then.