I'm using vs code with calva on Ubuntu. My clojure app listens on a port and I find that if I exit vs code, it leaves a java process bound to that port which I have to locate and kill before I can start again.
Is there any calva command to stop the repl?, or better still, a way of stopping the repl automatically when I exit vs code?
You are right to expect that the process (if started by Calva) should be owned by Calva/VS Code and that exiting VS Code should kill it. Please report this as a bug on Calva: https://github.com/BetterThanTomorrow/calva This works on MacOS (and I think on Windows too) so please report this from VS Code's help menu so that your system info gets attached.
As for how to kill the REPL. You can press Ctrl+C in the terminal where the process is started. We should add a proper command for it as well, but that's for another day. 😀 (That it gets killed when you disconnect the REPL is a also a bug, I would say.)
From the comments I've figured out that I was really asking the wrong question. I was under the impression that the repl was "owned by" to the vs code process that started it and that not terminating it when you quit vs code was a bug, but really my understanding wasn't right.
So to solve my original problem of leaving a process bound to the port, there are 3 options:
Terminate the repl using clojure (System/exit 0)
Use the calva command to reconnect to the existing repl after restarting vs code
Use calva to disconnect from the repl, then you have the choice of
starting a new one (which automatically will kill the old one) or re-connecting later
Related
I try to ask here if somebody has encountered such a problem.
From time to time, I have a situation: I launch my Qt app on Windows (in debug mode, but I am not sure if it matters) via cmd.exe and then I work with it and then I stop working with it for some time. Then I return it to be focused and very rarely I experience this: the app is Not Responding even though I do not have any logic for it to react on being returned to be focused. Then I wait and wait and noting happens and then I press any key in my cmd.exe, and instead of being killed, my app suddenly wakes up and continues to work, and then I do not experience any problems anymore.
What can be the problem? On Linux I do not experience such a problem. I ask because I cannot trace the problem, as it happens not very often. Also, I am not very good acquainted with Windows. If it was Linux I would use gdp -p and try to see where the app hangs. But what can I do on Windows? Any advice on how to catch this?
UPDATE: I can press any key in my cmd.exe to unfreeze the program.
UPDATE:
It looks like it freezes on one of my debug-printfs:
STACK_TEXT:
: ntdll!NtWriteFile+0x14
: KERNELBASE!WriteFile+0x76
!write_text_ansi_nolock+0x183
!_write_nolock+0x451
!_write_internal+0x377
!__acrt_stdio_flush_nolock+0xc4
!__acrt_stdio_end_temporary_buffering_nolock+0x54
!__acrt_stdio_temporary_buffering_guard::~__acrt_stdio_temporary_buffering_guard+0x28
!<lambda_303760bc4008a2b3ec4768a30b06a80c>::operator()+0x104
!__crt_seh_guarded_call<int>::operator()<<lambda_d854c62834386a3b23916ad6dae2782d>,<lambda_303760bc4008a2b3ec4768a30b06a80c> &,<lambda_4780a7ea4f8cbd2590aec34bd14e2bbf> >+0x35
!__acrt_lock_stream_and_call<<lambda_303760bc4008a2b3ec4768a30b06a80c> >+0x58
!common_vfprintf<__crt_stdio_output::standard_base,char>+0x21a
!__stdio_common_vfprintf+0x5c
!_vfprintf_l+0x3f
!printf+0x58
! MyClass::myfunc -- that executes my handler of the button pressed (which freezes)
Why can be so? I mean it's just a printf writing to cmd.
Here is the answer to my question:
https://stackoverflow.com/a/33883532/4781940
I really have that Select Command Prompt title when the freeze happens.
I have a console application that runs some temperamental hardware. If I don't detach from it nicely, windows tends to bluescreen five minutes later. I can catch when the application is closed by using SetConsoleCtrlHandler. But when I hit 'stop debugging' in visual studio, it skips this process and just kills the program brutally. As of 2009 it appears nobody has a solution for this problem.
Is this still the case? Do I really have to live with a bluescreen if I accidentally hit the wrong button?
Killing the process is what that button is for. If you want the program to terminate gracefully, you need to let it run to completion. You can use the debugger's "continue" button, or just detach from the process, and then quit the program in the normal way. Or you can use the debugger to do something that makes the program quit itself, such as setting a "done" flag that controls a main loop.
You might consider splitting your program into two parts: a service that deals with the hardware's peculiarities and presents a "clean" interface to the console application, and the console application which talks to the service instead of directly to the hardware.
You immediate problem is the TerminateProcess function that even Task Manager can execute which gives you no recourse to shutdown cleanly. Even if you could solve the Visual Studio problem, someone could right click and "End Process" and you be in the same boat.
Your root problem is poorly-written device drivers. These driver should not blue-screen even if you are abruptly terminated. If you have choice but to use them then you can try to bulletproof your process by running with administrative privileges, running as a service, or confining operations to short windows of time. Or you can simply train your operators not to do the things that will cause your delicate system to blow up. And hope.
I developed a software (in C++) which needs to be continuously running. That basically means that it has to be restarted each time it stops.
I was thinking about using cron jobs to check every minutes if it is still alive, but there might be a cleaner way or standard way of doing this.
Thanks in advance
Fedora and Ubuntu use upstart, which has a the ability to automatically restart your deamon if it exits.
I believe the easiest way to do this is to have a script that will start your program and if it gets returned to it just restarts it.
#!/bin/sh
while true; do
./Your_program
done
Monit can do what you want and much more.
cron is an option if your app will be smart enough to check for itself running (this is to avoid many copies of it running). This is usually done in a standard way via PID files.
There are two proper ways to do it on *nix:
Use the OS infrastructure (like smf/svc on solaris, upstart on Ubuntu, etc...). This is the proper way as you can stop/restart/enable/disable/reconfigure at any time.
Use "respawn" in /etc/inittab (enabled at boot time).
launchtool is a program I used for this purpose, it will monitor your process and restart it as needed, it can also wait a few seconds before reinvocation. This can be useful in case there are sockets that need to be released before the app can start again. It was very useful for my purposes.
Create the program you wish to have running continually as a child of a "watcher" process that re-starts it when it terminates. You can use wait/waitpid (or SIGCHILD) to tell when the child terminates. I would expect someone's written code to do this (it's pretty much what init(8) does)
However, the program presumably does something. You might want not only to check the application is running, but that it is not hung or something and is providing the service that it is intended to. This might mean running some sort of probe or synthetic transaction to check it's operating correctly.
EDIT: You may be able to get init to do this for you - give it a type of 'respawn' in inittab. From the man page:
respawn
The process will be restarted whenever it terminates (e.g. getty).
How about a script that check about every 10 minutes to see if the application is running and if it isn't it will restart the computer. If the application is running, then it just continues to check.
Here is my script using PrcView is a freeware process viewer utility. And I used notepad.exe as my example application that needs to be running, I am not sure the command for checking every 10 minutes and where it would go in my script.
#echo off
PATH=%PATH%;%PROGRAMFILES%\PV;%PROGRAMFILES%\Notepad
PV.EXE notepad.exe >nul
if ERRORLEVEL 1 goto Process_NotFound
:Process_Found
echo Notepad is running
goto END
:Process_NotFound
echo Notepad is not running
shutdown /r /t 50
goto END
:END
This is not so easy. If you're thinking "I know, I'll write a program to watch for my program, or see if such a program already exists as a standard service!" then what if someone kills that program? Who watches the watcher?
Consider the following situation: -
I am using Linux.
I have doubt that my application has crashed.
I had not enabled core dump.
There is no information in the log.
How can I be sure that, after the system restart my app was started, but now it is not running, because it has crashed.
My app is configured as a service, written in C/C++.
In a way: how can I get all the process/service names that have executed since the system start? Is it even possible?
I know, I can enable logging and start the process again to get the crash.
This feature is included in Linux Kernel. It's called: BSD process accounting.
Standard practice is to have a pid file for your daemon (/var/run/$NAME.pid), in which you can find its process id without having to parse the process tree manually. You can then either check the state of that process, or make your daemon respond to a signal (usually SIGHUP), and report its status. It's a good idea to make sure that this pid still belongs to your process too, and the easiest way is to check /proc/$PID/cmdline.
Addendum:
If you're only using newer fedora or ubuntu, your init system is upstart, which has monitoring and triggering capabilities built in.
As #emg-2 noted, BSD process accounting is available, but I don't think it's the correct approach for this situation.
I would recommend that you write the fact that you started out to some kind of log file, either a private one which get's overwritten on each start up or one via syslogd.
Also, you can log a timestamp heartbeat so that you know exactly when it crashed.
you probably can make a decoy, ie an application or shell script that is just a wrapper around the true application, but adds some logging like "Application started".
Then you change the name of your original app, and give the original name to your decoy.
As JimB mentions, you have the daemon write a PID file. You can tell if it's running or not by sending it a signal 0, via either the kill(2) system call or the kill(1) program. The return status will tell you whether or not the process with that PID exists.
Daemons should always:
1) Write the currently running instance's process to /var/run/$NAME.pid using getpid() (man getpid) or an equivalent command for your language.
2) Write a standard logfile to /var/log/$NAME.log (larger logfiles should be broken up into .0.log for currently running logs along with .X.log.gz for other logs, where X is a number with lower being more recent)
3) /Should/ have an LSB compatible run script accepting at least the start stop status and restart flags. Status could be used to check whether the daemon is running.
I don't know of a standard way of getting all the process names that have executed; there might be a way however to do this with SystemTap.
If you just want to monitor your process, I would recommend using waitid (man 2 wait) after the fork instead of detaching and daemonizing.
If your app has crashed, that's not distinguishable from "your app was never started", unless your app writes in the system log. syslog(3) is your friend.
To find your app you can try a number of ideas:
Look in the /proc filesystem
Run the ps command
Try killall appname -0 and check the return code
How do I stop a GDB execution without a breakpoint?
Just use a regular interrupt Ctrl-c will work just fine. GDB just forwards the SIGINT to the debugging process which then dies. GDB will catch the non-standard exit and break the process there, so you can still examine all the threads, their stacks and current values of variables. This works fine, though you would be better off using break points. The only time I find myself doing this is, if I think I've gotten into some sort of infinite loop.
GUI applications don't react to ^C and ^Break the way console applications do. Since these days most non-trivial projects tend to be GUI applications or libraries primarily used in GUI applications, you have two options:
Send SIGSTOP to the application from a separate terminal. This is cumbersome.
If you press ^C or ^Break on the GDB prompt, GDB will terminate but the application will remain running. You can then run GDB again to attach to it using the -p command-line switch. This loses debugger state.
In both cases, you might find this helpful: tasklist | grepProcessName| sed -e 's/ProcessName*\([0-9]*\).*/gdbModuleName-pid=\1/' > rungdb.sh You can modify this for use in shell scripts, makefiles or to send a signal instead of attaching GDB.
info threads will help you figure out which thread you want to look at. Then use threadThreadNumber to switch to it.
Start a shell, find the process ID using ps and send it SIGSTOP or SIGINT by using the kill command (e.g. kill -INT pid).
Just type BREAK without any arguments.
Break, when called without any arguments, break sets a breakpoint at the next instruction to be executed in the selected stack frame
Ctrl + Z seems to work for me (but only in some cases - I'm not sure why).