I want to shutdown weblogic server using command line FORCEFULLY. I have a specific scenario. I have written a batch file to do some stuff and then shutdown weblogic server using stopWebLogic.cmd as follows:
"%WEBLOGIC_DOMAIN_PATH%\bin\stopWebLogic.cmd"
I have gone through this document. But I can't follow the approach since I don't want to change stopWebLogic.cmd. Is there any way to achieve this?
A WLST script is probably the way to go. See the shutdown command which has an optional 'force' parameter.
N.B. On UNIX/Linux you can send a SIGTERM signal to the pid of a weblogic server which will perform a force shutdown. i.e. kill -term pid
You can use an existing file if you configure it to force the shutdown
head to bin/stopWebLogic.sh
Then modify the following line
echo "shutdown('${SERVER_NAME}','Server', ignoreSessions='true')" >>"shutdown.py"
to
echo "shutdown('${SERVER_NAME}','Server', ignoreSessions='true', force='true')" >>"shutdown.py"
Then execute the file using bash stopWeblogic.sh
The weblogic will be stopped, even if active sessions or listeners exist.
Related
I have a follow-up question to this issue: is it possible to finalize the AdminTask.createAuthDataEntry task in one wsadmin script?
I need to invoke this task so that WAS can establish a connection to a datasource that I have defined in the same script.
Defining an auth entry from the web console does not require a restart. Typically I would not expect that a restart would be required for authentication changes.
I have tried to use the task AdminControl.invoke(AdminControl.queryNames('WebSphere:*,type=Server,node=%s,process=%s' % ('node', 'server')), 'restart') inside the script, but this stops the instance without booting it up again. Also, I cannot verify the datasource connection within the same script because of these limitations.
Creating or modifying authentication data entries from wsadmin requires a server restart. We have an RFE to allow wsadmin to make dynamic updates to them without a server restart which you can vote for. In order to stop and start your server using wsadmin, it's probably easiest for the OS-level (bat or sh) script that invokes wsadmin to call two scripts.
Ansible seems to be sending SIGHUP signals at the end of (certain?) tasks. This is a problem as the tasks call a bash script which in turn starts a server instance.
Now if the closing of Ansibles SSH session sends a SIGHUP, this will actually shutdown the server - the start of which was the key point of the Ansible task in the first place.
So, is there a way I can guarantee that Ansible will use SSH in a way that will not send a SIGHUP signal when closing the task/session?
I could theoretically start the bashscript using nohup. But this seems to be just a dirty workaround, as I know that SSH is capable of doing what I want: if I manually compose and pass the script command via SSH as such:
ssh user#server "scriptToStartMyServer.sh params"
.. then it works fine and no SIGHUP is sent (thus the server survives and is not shutdown immediately after being started).
Edit:
Sadly we cannot avoid using these bash scripts to start servers and we cannot really change them as this is something given to us by the customer.
I've got problem with my Go server.
When I'm connected to my NAS via SSH and do ./gogs web, the server is starting. But when I close the SSH connection, the server is stopped.
How I can start my Go server permanently?
You have scripts in gogs allowing you to launch the server as a daemon:
scripts/init/debian/gogs (recently fixed with issue 519)
scripts/init/centos/gogs
That would allow the process to remain while the session is closed.
You have other options in issues 172.
This is not a Go-specifioc problem, what is happening is that the Go program is still attached to your terminal and when you log out, the kernel will trigger a SIGHUP to every binary still connected to that terminal session.
Your best option is probably to use nohup ./gogs web.
Second-best option would be to rewrite main, so that it intercepts and handles SIGHUP, stopping it from killing your program. However, doing so requires handling quite a few things properly (you really should close stdin, stdout and stderr; make sure all your logging is done through the log library, ...)
I am using some EC2 instances to run some large jobs I can not run locally. The issue I am seeing is that after a while (X hours since the process started) my connection on my shell gives me a broken pipe error
ubuntu#ip-10-122-xxx-xxx:~/stratto/ode$ Write failed: Broken pipe
The instance is still there because I can reconnect with no problems, but how can I reconnect and get back at seeing the logs of the process as before the 'Broken Pipe'
Any tip much appreciated,
Thanks!
Redirect your output to a file and then run the program "nohup ..." to ensure the disconnect doesn't kill it. Use "tail -f" to monitor the redirected file.
Note: Originally said to use "tee" but that won't work. I think a straight redirect and then tail on the file works.
You can use screen to run processes in the cloud even when you are not connected to the server.
sudo apt install screen
To specifically address the issue described in the original post (e.g. connecting to AWS EC2 instances) I a basic example and a more advanced example of using screen.
You can use "screen". Detach from it and ping to google.com. So there ssh session will be active through out the installation.
Is there a WLST command to stop a Weblogig deployment? (i.e. the opposite of the nmStart() command)
If so, what is it?
I am changing database passwords and I want to shutdown all deployments so all connections will close. Currently I have to log into the console to shut everything down and I am looking for a quicker way.
I'd say nmKill but I'm not sure about the terminology you are using. The nmStart is used to start a server in the current domain using Node Manager, not to start a "deployment".
By the way, the WLS Console provides a recording feature that writes out the edits you make in the console to a WLST script. This can be very handy if you are not a WLST expert. To turn on recording, click 'Record' (in the the toolbar near the top of the page). Then, make your edits in the console. Finally, turn the recording off when you're done.
The more usual method, which is independant of whether you're using node manager or not, would be the shutdown command which is also able to work at the cluster level.