I am interested how systemd tracks child of main process that remains after main process exists?
Systemd is using cgroups for this. Before starting any executable that is defined with a service file, systemd creates a cgroup and puts the executable in it[*]. After that, it doesn't matter how many child processes or how many times the processes in the cgroup have forked. For systemd, they all belong to the same cgroup.
Another good thing to know is that when the parent process dies, child processes of that parent process inherits PID 1 (systemd) as their parent process. This is a unix rule.
[] System first creates a cgroup. Then forks it self and puts the new process in this cgroup. Then calls exec() family calls for your service's ExecStart= binary.
Related
Usually when a program is run from the Windows console, the console will wait for the process to exit and then print the prompt and wait for user input. However, if the process starts a child process, the console will still only wait for the first process to exit. It will not wait for the child as well.
Is there a way for the program to get the console to wait on another child process instead of (or as well as) the current process.
I would assume it's impossible because presumably the console is waiting on the process' handle and there's no way to replace that handle. However, I'm struggling to find any confirmation of this.
Is there a way for the program to get the console to wait on another child process instead of (or as well as) the current process.
No. As you noted, as soon as the 1st process the console creates has exited, the console stops waiting. It has no concept of any child processes being created by that 1st process.
So, what you can do instead is either:
simply have the 1st process wait for any child process it creates before then exiting itself.
if that is not an option, then create a separate helper process that creates a Job Object and then starts the main process and assigns it to that job. Any child processes it creates will automatically be put into the same job as well 1. The helper process can then wait for all processes in the job to exit before then exiting itself. Then, you can have the console run and wait on the helper process rather than the main process.
1: by default - a process spawner can choose to break out a new child process from the current job, if the job is setup to allow that.
I have .exe application in GO that spawns a child process in windows.
When i terminate my parent process for some reason the child process terminates too.
However when my parent.exe panics and crashed, the child process continue to execute and does not shutdown.
Ideally I was expecting the child process to keep on living if the parent process shuts down(normally or forcefully)
Is the the default behavior of processes in windows?
In addition to above.
I added code to capture any Signal the child process receives if I terminate the Parent Process, It seems that every time i terminate the parent process the child receives an interrupt signal.
What is the difference between systemd service Type oneshot and simple?
This link states to use simple instead of oneshot for timers. I am not able to understand it correctly.
The Type=oneshot service unit:
blocks on a start operation until the first process exits, and its state will be reported as "activating";
once the first process exits, transitions from "activating" straight to "inactive", unless RemainAfterExit=true is set (in which case it becomes "active" with no processes!);
may have any number (0 or more) of ExecStart= directives which will be executed sequentially (waiting for each started process to exit before starting the next one);
may leave out ExecStart= but have ExecStop= (useful together with RemainAfterExit=true for arranging things to run on system shutdown).
The Type=simple service unit:
does not block on a start operation (i. e. becomes "active" immediately after forking off the first process, even if it is still initializing!);
once the first process exits, transitions from "active" to "inactive" (there is no RemainAfterExit= option);
is generally discouraged because there is no way to distinguish situations like "exited on start because of a configuration error" from "crashed after 500ms of runtime" and suchlike.
Both Type=oneshot and Type=simple units:
ignore any children of the first process, so do not use these modes with forking processes (note: you may use Type=oneshot with KillMode=none, but only do this if you know what you are doing).
From systemd's point of view, Type=simple is kind of fire and forget. Systemd just forks a process defined in ExecStart= and goes on its way, even if the process fails to start.
I have tried to kill PPID process which terminate process (also kills child pid's) immediately sends signal back in seconds to one of my console, but child process are taking time to respond back termination response. Any one has any idea why it is happening..?
Whenever the parent process gets killed, the child processes become ORPHAN processes so the INIT process becomes the parent of the ORPHAN processes. As INIT process is created in such a way that whenever any process gets killed all of it's children are taken care by the INIT process until the processes finish.
It looks like the parent process did not catch any signals, while the child processes did.
Alternatively, the child processes had resources open and are attempting a graceful exit, making sure those resources are properly taken care of.
In this case you may need to rewrite the parent process to catch the signal, forward it to its children, and then wait() for them to finish, and exit.
In Ruby, how do I ensure that child processes spawned from my program don't keep running when my main process exits or is killed?
Initially I thought I could just use at_exit in the main process, but that won't work if my main process gets kill -9ed or calls Kernel.exec. I need a solution that is (basically) foolproof, and cross-platform.
If you have to handle kill -9 termination for your parent app, then you have only a couple of choices that I can see:
Create a work queue manager and spawn/kill child processes from work queue manager. If you can't guarantee that the work queue manager won't also be killed without warning, then option 2 is your only choice I think, since the only thing you know for sure is that the child processes are still running.
http://www.celeryproject.org/
http://aws.amazon.com/elasticbeanstalk/
More aggressive approach - basically spawn off whole OS instances but they'll definitely get killed off within your parameters for operation
Have the child processes check a "heartbeat" from the parent process through RPC or monitoring parent PID in memory or watching a date/time on keep-alive file in /tmp to make sure it's current.
If the child processes fail to see the parent processes doing it's job of either responding to RPC messages, staying in memory itself, or keeping a file date/time current the child processes must kill themselves.