Is there any way to run an app from the main app as a separate process without binding it's output?
The situation is next. I am doing simple micros-service monitor. Every 10 minutes it checks if the other 5 micro-services are working. If not, it should start them. The problem that when I am using spawnProcess it's output is binding with MonitorApp. But I do not want it. I need to just run them as separate threads.
Important moment I need a way to get the PID of every micro-service running.
Now if I am closing MonitorApp it's children are dying. So I think that they shouldn't be children, but separate processes.
https://dlang.org/phobos/std_process.html
Related
I am using named pipes on windows (C++). I was able to send data from one unrelated process to another process.
But for this I have to start the server first. and use "CreateNamedPipe" before I run the client. Client connects to the server using "CreateFile".
Is there a way I could run the client first before starting the server? (without trying to use the "CreateFile" inside a loop till it succeed)
Thank you.
IMO, it depends on your use case. My answer will be based on a case your software doesn't require the named pipe to work. For example, let's say a software which use a named pipe to log activities. This way we can understand your software can work perfectly without logging.
It should be possible if you start up your program without requiring the named pip to exist. Then, once everything is loaded up and functional, you could have sub-routine periodically checking for the named pipe existence (let's say every 5 seconds in order to not overload your CPU) and once created, you start using it.
Note: it will still looks like an infinite "a loop till it succeed" but I don't see anything wrong with that since you do it properly, says, you run it with non-blocking mechanism.
Note: it doesn't necessarily implies multi-process techniques. You can imagine a single main loop with a periodic checking (not every iteration).
After starting a process with QProcess::startDetached, how can I stop it later?
Say the main program runs, then starts the detached process, which runs independently. The user closes the main program, then later opens it up again and wants to stop the process. How would I find the process and then stop it?
Is there a way I could prevent the application from the same process twice?
No, it will be decoupled from your application. You could get the the PID of it and then send a SIGSTOP on Linux, but this is platform specific and will not work without POSIX support, like with msvc. You would need to hand-craft your version therein.
Is there a way I could prevent the application from the same process twice?
Yes, by using lock file in the detached process. If that detached process happens to be written in at least partially Qt, you could use the QLockFile class.
If you happen to detach some platform specific process, then you have the same recurring issue again, for sure.
Here's the answer I figured out:
I first start the detached process that generates a unique id. That process write to a file whenever it runs (was a 1 minute timer). When it runs, it writes its id to a file. Then, if there happens to be another one that ran, if it sees a previous one ran, it just writes its id to the file and doesn't run, then, when the next one runs, it sees if its id is already in the file and if it is, it shuts itself off and clears the file, then the next run ends up running freely, being the only one running. This may end up skipping some time.
You can add a timestamp, too, as that might indicate it wasn't run recently and help with deciding whether or not to shut it down. The issue was if I just write the id to a file, when I turn the phone off, the file will say it's still running. The same applies to if it crashes.
I'm maintaining an MFC application in some points it stop responding for 30 seconds , some times 1 minute or more. I'm supposed to fix that issue, I tried tracking the code[all methods in this class] and also the issue is still, I tried to pause debugging during this time and I got nothing as in this image
I want to know how to track the code that cause the application to stop responding
add watch variable for any separate thread event
increment each watch variable inside its thread
also very useful can be flag if the thread/event is executing (especially for events)
you must set this flag on enter
end clear before exit
visualize watch variables somehow.
either use some debug print inside your App.
or use separate Window
or even better separate App connected with any IPC method. (this will work even if your App UI hangs)
When the app hangs just see which variables are incrementing and which not
with flags you can determine exact what is hanging up on you ...
Good luck with debuging.
Is it possible to create a windows service to create and maintain another process? Like I'm writing a program, and say a virus killed the process, could I have my window service running and basically 'watching' it? I already have the code for a regular application that stays running and executes a program if it's not currently running, to keep it running.
I've never written a service before, but would it be that hard to just write this simple program, which basically runs a check to see if the process is running, if not, it executes it and sleeps for a few minutes?
Thanks.
Yes, it is possible. It is not uncommon to see third-party apps have watchdog services to keep them running in case of crashes. A service can enumerate running processes using EnumProcesses(), and if the desired executable is not running then start a new copy of it using CreateProcessAsUser().
If the service is the one starting the executable process in the first place, or can find it after an enumeration, one optimization would be to keep an open handle to the process (returned by CreateProcess...(), or use OpenProcess() on the process ID an enumeration returns), and then use a wait function, like WaitForSingleObject(), to detect when the process stops running. That way, you don't have to enumerate processes to find out if the intended process is still running or not.
So here is the situation, we have a C++ datafeed client program which we run ~30 instances of with different parameters, and there are 3 scripts written to run/stop them: start.sh stop.sh and restart.sh (which runs stop.sh and then start.sh).
When there is a high volume of data the client "falls behind" real time. We test this by comparing the system time to the most recent data entry times listed. If any of the clients falls behind more than 10 minutes or so, I want to call the restart script to start all the binaries fresh so our data is as close to real time as possible.
Normally I call a script using System(script.sh), however the restart script looks up and kills the process using kill, BUT calling System() also makes the current program execution ignore SIGQUIT and SIGINT until system() returns.
On top of this if there are two concurrent executions with the same arguments they will conflict and the program will hang (this stems from establishing database connections), so I can not start the new instance until the old one is killed and I can not kill the current one if it ignores SIGQUIT.
Is there any way around this? The current state of the binary and missing some data does not matter at all if it has reached the threshold, I also can not just have the program restart itself, since if one of the instances falls behind, we want to restart all 30 of the instances (so gaps in the data are at uniform times). Is there a clean way to call a script from within C++ which hands over control and allows the script to restart the program from scratch?
FYI we are running on CentOS 6.3
Use exec() instead of system(). It will replace your process with the new one. Note there is a significant different in how exec() is called and how it behaves: system() passes its string argument to the system shell to run. exec() actually executes an executable file, and you need to supply the arguments to the process one at a time, instead of letting the shell parse them apart for you.
Here's my two cents.
Temporary solution: Use SIGKILL.
Long-term solution: Optimize your code or the general logic of your service tree, using other system calls like exec or by rewritting it to use threads.
If you want better answers maybe you should post some code and or degeneralize the issue.