I'm using VS Code to write and debug a C++ program binding to libfuse.
Unfortunately, if you kill a libfuse process with SIGKILL, you then have to use sudo umount -f <mountpoint> before you can start the program again. It's a minor nuisance if I have to do this every time I want to stop or restart debugging, especially as I shouldn't have to authenticate to do such a regular task (the sudo is somehow necessary despite the mount occurring as my user).
While I think this is mainly FUSE's fault (it should gracefully recover from a process being ungracefully killed and unmount automatically instead of leaving the directory saying Transport endpoint is not connected), I also think there should be a way to customise VS Code (or any IDE) to run some clean-up when you want to stop debugging.
I've found that entering -exec signal SIGTERM in the Debug Console will gracefully unmount the directory correctly, stop the process and tell VS Code it's no longer debugging (status bar changes back from orange to blue). But I can't seem to find a way to automate this. I've tried using a .gdbinit file, with some inspiration from this question:
handle SIGTERM nostop
# This doesn't work as hook-quit isn't run when quitting via MI mode, which VS Code uses...
define hook-quit
signal SIGTERM
end
But as noted in the linked question, GDB ignores quit hooks when in MI mode, and VS Code uses MI mode.
The ideal solution for me would be if I could put something in a .vscode configuration file telling it to send -exec signal SIGTERM when I click the stop or restart buttons (and then wait for whatever notification it's getting that debugging has stopped, before restarting if applicable) but I imagine there probably isn't an option for that.
Even if the buttons can't be customised, I'd be happy with the ability to have a keybinding that would just send -exec signal SIGTERM to the Debug Console without me having to open said console and enter the command, though the Command Palette doesn't show anything useful here (nothing that looks like it will send a specified Debug Console command), so I don't expect there's a bindable command for that either.
Does anyone have any suggestions? Or would these belong as feature requests over on the VS Code github? Any way to get GDB to respect its quit hook in MI mode, or to get FUSE to gracefully handle its process being killed would be appreciated too.
Related
When trying to use Gatling CLI mode, the gatling starts successfully and recording is also happening. But the problem is when stopping the recording. As mentioned by the documentation (https://gatling.io/docs/2.3/http/recorder/), it can be stopped either by CTRL-C or by killing the pid available in .gatling-recorder-pid file.
I have used the second approach. Though the recording is stopped successfully, it is unable to create the simulation file. After doing some trial and error the only understanding i have now is that unless CTRL-C is pressed, it can never create a simulation file and killing pid only stops the recorder just before the file creation. But i am unable to simulate the CTRL-C action in windows command prompt from java. Please help. Thanks in advance
The kill command sends a SIGTERM (termination) signal. The SIGINT (interrupt) signal is the one equivalent to Ctrl+C.
kill -SIGINT processPIDHere
I have a console program that is being debugged under Eclipse. Eclipse provides a Console Panel, but it does not appear to provide a terminal.
The program has a few signal handlers installed, including SIGHUP, SIGINT and SIGTRAP. When I try and send a CTRL+C to the program, the signal SIGINT never makes it to the debugee.
To date, I've had to open a separate terminal, do a ps, and then send the signal with kill (for example, kill -s SIGINT <pid>). But that's seems like overkill (not to mention a lot of extra work) since all I should need is a CTRL+C on a foreground window or terminal.
How does one send signals to a program under the debugger?
NonStop
Sets nonstop mode. If a terminal's already been set up, it's too late;
the debugger remembers the setting in case you restart, though. (source)
When is it useful,why do I need to debug if it doesn't ever stop?
As I understand it, you can use the debugger in rendez-vous-mode. In this setting, the debugger runs the application NonStop without a tty first, but when an event interrupt occurs, it stops the application and sets the tty up for you to debug.
Update: Rendez-vous-Mode is useful for attaching to a running perl process after it has been started (by something out of your control). If your application is prepared for dynamically loading the debugger, you can enter the debugger even if you did not start it with a -d option at all.
I'm working with an embedded computer that has a Debian on it. I already manage to run a command just before it has booted and play the "bell" to tell that is ready to work, and for example try to connect to a service.
The problem is that I need to play the bell (or run any command/program) when the system is halted so is safe to un-plug the power. Is there any runscript that run just after halt?
If you have a look in /etc/init.d, you'll see a script called halt. I'm pretty certain that when /sbin/halt is called in a runlevel other than 0 or 6, it calls /sbin/shutdown, which runs this script (unless called with an -n flag). So maybe you could add your own hook into that script? Obviously, it would be before the final halt was called, but nothing runs after that, so maybe that's ok.
Another option would be to use the fact that all running processes get sent a SIGTERM followed (a second or so later) by a SIGKILL. So you could write a simple daemon that just sat there until given a SIGTERM, at which point it went "ping" and died.
I am trying to find a hook in Emacs, which should fire right before emacs server graceful shutdown.
I tried kill-emacs-query-functions, kill-emacs-hook, server-done-hook with elisp like :
(add-hook 'server-done-hook
'(lambda ()
(savehist-save)
)
)
... but none of them is called when OS shuts down, so history is not saved.
Maybe someone could give a hint?
P.S. I am on Gentoo Linux, emacs-vcs-23.2.9999 package, terminal only. For testing desired behaviour Emacs is stopped using start-stop-daemon utility.
Since Emacs 24.1, Emacs runs kill-emacs which runs the functions in kill-emacs-hook. So the question, and the rest of this answer, are only relevant to older versions.
The right place to run something before Emacs shuts down is either kill-emacs-query-function if you want to be able to cancel the shutdown or kill-emacs-hook if you don't. The problem you're facing is that your OS does not notify Emacs to shut down gracefully in a way that Emacs understands, or to look at it the other way, Emacs does not understand your OS's request to suht down gracefully.
A graceful way of shutting down Emacs 23 from the outside is to run emacsclient -n -e '(kill-emacs)'. That's obviously not a generic way of telling a program to shut down gracefully.
The normal way to shut down a process gracefully on unix is to send it a SIGHUP or SIGTERM signal. Unfortunately, Emacs treats almost all signals as fatal, and only runs an emergency auto save and no lisp code when it receives them. This is not configurable from lisp. A different behavior has been requested, but turned down.
A partial workaround (found here) is to run session saving hooks in delete-frame-functions. This hook is likely to be run before the system shutdown sequence, either when you close your last frame or when the X server dies (taking your terminals with them if you run Emacs in a terminal). Make sure you don't run the hook that kills the server in delete-frame-functions.
By the way, if you were going to use this exact hook, note that your code is a complicated way of writing (add-hook 'server-done-hook 'savehist-save), and that's not useful since there's already savehist-autosave in kill-emacs-hook.