Is there a way to shutdown Eclipse cleanly from the command line, such that files and workspaces are saved? kill -3 doesn't do anything. kill -1 and kill -15 (default) causes Eclipse to exit abruptly with JVM termination popup. kill -9 does the same thing.
The use case is that I'm working remotely on a machine with Eclipse loaded on it, and I want to save memory by closing Eclipse, but I want Eclipse to save its state first.
I could use VNC or some alternative desktop sharing software, but that's really heavy-weight, and I'd much prefer a command line solution.
EDIT: System info: RHEL5.1 64-bit using GNOME
I figured this out with the help of gigi's answer and another question. You're going to need the wmctrl and xdotool utilities from your package manager.
Unless you're running in a terminal emulator on the same display, you need to set the right display:
$ export DISPLAY=:0.0
Then (irrelevant windows elided from example):
# List windows
$ wmctrl -l
...
0x030000fa 0 kcirb Java - Eclipse
# Tell Eclipse window to close gracefully
$ wmctrl -c eclipse
# Darn, there's a confirmation dialog
$ wmctrl -l
...
0x030000fa 0 kcirb Java - Eclipse
0x03003c2d 0 kcirb Confirm Exit
# Send return key to the window
$ xdotool key --window 0x03003c2d Return
Worked for me on Ubuntu 12.04, at least.
EDIT: See Scarabeetle's answer for the tweaks you need to make it work from a script.
Not enough reputation to comment on pidge's answer above...
It almost works, but I needed to wait for some Gnome3 animation to finish and then give focus to the "Confirm Exit" window:
export DISPLAY=:0.0 # Do this in main X session
wmctrl -c "Eclipse SDK" # Close main window
sleep 1 # Wait for animation
wmctrl -a "Confirm Exit" # Give focus to the dialog
# Send a Return keypress to press the OK button
xdotool key --window $(xdotool search "Confirm Exit") Return
Any added ShutdownHooks (more info here) should be executed by the JVM when terminated by SIGTERM. Therefore, I think the problem is the way Eclipse is programmed to deal with such signals.
As I don't know how the cleanup process is implemented in Eclipse, I can only assume that it is not called by any ShutdownHook (and rather by an Action or something similar).
Edit: pidge has provided an answer below however which details steps which should allow you to shutdown Eclipse cleanly from the command line.
Try killing java process(es). Do ps -ea | grep java
Did you tried with wmctrl?
wmtrl -l
lists the windows and
wmlctrl -c -P
should close the window.
Anyway you could have problems with the confirmation dialog of eclipse.
Did you try kill -HUP (kill -1)? -- that's the canonical way to tell a process that whoever was interacting with it has gone away and it should clean up appropriately
The answer to this question was helpful to me in a similar issue: Eclipse hanging, how to kill it properly?
After I killed the eclipse process the Eclipse window kept there until I killed the java process (I didn't have a javaw process as in the answer above. I had only one "java" process that when killed fixed the problem).
Related
I have a script which launches multiple gvim windows. I want to position them in a certain way. wmctrl can do this, but because there are multiple instances, the window names are ambiguous. I figure: use pids.
gvim /tmp/xxx &
X=$!
wmctrl -lp | grep $X
echo $X
wmctrl -lp | grep GVIM
echo sleeping
sleep 3
wmctrl -lp | grep GVIM
The output is:
5211
sleeping
0x03400062 0 5218 localhost xxx (/tmp) - GVIM
It seems gvim starts out with pid 5211 but launches a new process for the actual window. Also, that process doesn't exist yet.
How can I unambiguously get the wmctrl window handle of the gvim instance I just started? Or should I use something else?
The --echo-wid option looks nice but I am using KDE.
I just ran into the same problem, and solved it by running
gvim -f &
pid=$!
just as n.m. suggested in the comments above.
The manpage of gvim sais:
-f Foreground. For the GUI version, Vim will not fork and detach from the
shell it was started in. On the Amiga, Vim is not restarted to open a new
window. This option should be used when Vim is executed by a program that
will wait for the edit session to finish (e.g. mail). On the Amiga the
":sh" and ":!" commands will not work.
which explains why it works.
I don't know if you tried this, or if the answer even matters anymore, but I hate leaving a good question unanswered :)
credit goes to n.m. for pointing out the -f switch
I am using Ubuntu 12.04 and Octave:
$ octave
octave:1> _
I set my editor to gedit:
octave:1> edit editor "gedit %s"
I edit a function:
octave:2> edit someFunction
gedit opens someFunction.m as expected and prompt returns while gedit still has the file open:
octave:3> _
I run some other long-running function:
octave:3> runAllTests
While runAllTests is executing I press CTRL-C to interrupt it.
The observed behavior is that runAllTests is interrupted AND gedit is killed.
The expected behavior is that runAllTests is interrupted AND gedit is NOT killed.
Does anyone know how to stop CTRL-C from killing gedit in this circumstance? Alternatively is there another way to interrupt runAllTests without killing gedit?
The setting:
edit editor "gedit %s &"
causes octave to place the editor "in the background", so CTRL-C does not effect it and has the expected behaviour.
Try:
edit mode async
which specifies asynchronous mode of execution of the edit command
The problem is CTRL+C is also a copy command. IT may need to be customized as in Octave GUI Xoctave. They claim that customization is available.
Unfortunately, putting the forked process in background with '&' is not enough when working with the command line (octave-cli).
There is a bug open on the GNU Octave development webpage about this issue.
Of course it is not only an editor problem, but any new forked process is affected. For instance
octave> system("$TERM&")
creates a terminal in a new window, which would be killed by subsequent <ctrl-c>.
I propose a shell-based workaround. This consists in adding an additional layer of "forking in background", which would protect the final terminal (or text editor or whatever) from the signals sent to octave. In brief, I launch a terminal which launches another terminal in background, from which I kill the first terminal (so that it does not bother us).
Create an executable:
term-kill.sh
-----------------------------
#!/bin/sh
$TERM&
sleep 0.01
kill $1
-----------------------------
(note the sleep commands without which the second terminal does not have time to get detached from the first before the latter gets killed). Then, the command
octave> system("$TERM -e term-kill.sh $$&")
creates a single terminal which won't get killed.
To open a text editor, simply consider the executable
term-edit-kill.sh
------------------------
#!/bin/sh
$TERM -e $EDITOR $1&
sleep 0.01
kill $2
------------------------
and change the octave edit command through
octave> EDITOR('$TERM -e term-edit-kill.sh %s $$')
N.B.: I assumed that your system knows how to find term-kill.sh and term-edit-kill.sh, and that the variables $TERM and $EDITOR exist and suit your needs. The terminal emulator must support the -e option.
I have a DOSEMU process running on Linux (Mint 11). The process modify data over the network, and I'm afraid that if a user close the program using the [X] button of the window instead of properly shutdown the program, then the shared data can be corrupted.
In Windows, I can use NoClose to disable the [X] close button. Is there any way to do it in Linux?
Use -t switch to run DOSEMU not in a window but inside your console. There is no need to run it from X at all - you can just switch to a text-mode console (Ctrl-Alt-1...6) and run dosemu -t from there, your users will never notice it.
You could also run
sudo nohup dosemu -t your_command
and close your console safely - it would result in DOSEMU execute your_command in the background in case you don't need to do manual input
I have installed tmux from source on my localspace in Fedora. It was working nicely so far. But suddenly can not run it anymore, when run tmux, it just halts. Tried different command options like ls-sessions, none works. Killed all the processes of my user, deleted all the files of tmux and libevnet, and reinstalled them again from scratch. Still same, and tmux command in terminal just freezes without any actual error.
I had faced this problem for a long time and after a bit of searching I figured out that this was being caused because I accidently hit Ctrl+S (Ctrl+A+S is my shortcut for switching panes), and this turns off flow control in terminals and stops the terminal from accepting input. It can be reenabled by pressing Ctrl+Q.
Source: https://superuser.com/a/553349/137226
Had a similar issue, where I had a tmux session with two buffers. I didn't see anything I typed, but when I switched between buffers what I had typed previously would appear onscreen. stty sane didn't work.
I detached Ctrl-b+d, and noticed that there was still a client attached when I looked at tmux list-clients. tmux detach-client removed it, and then I could reattach and the everything worked again.
If it is ok to lose your sessions, try deleting the tmux-NNNNNNN directory, where NNNNNNN is a number, under your /tmp directory. According to the tmux manual, if the TMPDIR environment variable is set, the tmux-NNNNNNN will be put in the TMPDIR.
tmux stores the server socket in a directory under /tmp (or TMPDIR if set);
This solved my problem of not being able to run tmux commands that are related to sessions. I also tried the following, but they did not work:
killall -9 tmux
reinstall tmux
restart shell session
I could not easily restart the operating system, because it's a shared server managed by others.
tmux was halting right after I started it. Ctrl-Q and Ctrl-C didn't do anything.
Fixed with
killall -9 tmux
(May be a different problem, but this question showed up in Google.)
I had the same issue. The cause is that the tmux buffer is full, and it also may happens cause of multi clients to the tmux session.
To solve it you need to detach all the clients from the session, and reattach it.
The best way I found to solve it is to add to the ~/.bashrc file this functions:
check_params() {
if [[ $1 < $2 ]]; then
echo -e "Usage:\n${3}"
ok=0
else
ok=1
fi
}
# detach all the clients from this session, and attach to it.
reattach_client() {
check_params $# 1 "reattach_client <tmux_session_name>"
if [[ $ok == 1 ]]; then
tmux list-client | grep $1 | awk '{split($1, s, ":"); print s[1]}' | xargs tmux detach-client -t | true
tmux attach -t $1
fi
}
then run source ~/.bashrc to make these changes in the terminal.
Now to attach the session type:
reattach_client <session_name>
solved my issue.
Thanks to Alex Zelichenko for help me with this!
You should be able to narrow down your problem a bit with a few of these tests:
Give it a shot from outside X11: Ctrl+Alt+F2 (or use ssh from another computer)
Test if other terminal emulators work: script and screen
Try another complicated terminal application: htop and mc
Reset your TTY settings: stty sane
Check that your terminal identified: echo $TERM (it should be something like "xterm" or "linux")
Make that your terminal capabilities file exists: ls -lh /usr/share/terminfo/*/$TERM
Thanks.
I found the problem. The tmux process were in D state, and I had no choice but to reboot the system.
The problem came from kerberos ticket expiring after a while. And find a scripts that solves this problem:
https://iain.cx/src/ktmux/
A less drastic action (to try before killing the tmux process) is to ssh into the machine and run the following command.
kill -CONT `pidof tmux`
Source: https://github.com/tmux/tmux/issues/507#issuecomment-271502093
This happened to me because I accidentally tried to create two parallel tmux sessions with the same name.
What worked for me was to enter htop, checking pid's of the two running commands that created the sessions, and killing both by using kill -9 pid1 and kill -9 pid2
I've got a program running in a GNOME Terminal, but the screensaver is acting up and won't let me back in with my password. While waiting for a fix for the gnome-screensaver bug, is there some way to see the output (or even take over the process) in a virtual console (Ctrl-Alt-F1) without being able to interact with the GNOME Terminal?
Clarification: The original issue was the screensaver, but the question I'd like answered is how to see the output from a process running in another terminal, after starting the process without any logging to file. I'm guessing it should be possible to set the output device of a process from a different shell? Or is it possible to put a process in another shell into background mode, and get it into the foreground in the current shell? Or even ask GNOME Terminal to redirect or copy the output?
I've had luck in the past killing the screensaver from a virtual console, unlocking X session.
# Get the pid (xscreensaver, gnome-screensaver, etc.)
ps -f -u $(whoami) | grep screensaver
kill -9 12345 # Replace 12345 with the real pid
EDIT: Seems like this has been thought of, and you should use one of these commands, depending on which screensaver program you use:
xscreensaver-command -exit
gnome-screensaver-comand --exit
See the man page for those commands for more details.
Usual way is to pipe the output to a file, like program > program.log
Do tail -f program.log in another tab of Gnome console, and the same in the non-X console.
Alternatively, use tee to duplicate the output in the same console: program | tee program.log
ssh in to the box. kill the screensaver. su to become root and kill -9 if it's really acting up.
Usually Gnome-Terminal displays the output of one vty out of /dev. So just connect your console to that vty.
Launch program with screen.
Open another terminal, launch screen -x and you have two terminals acting like one. Try it, it's fun :)