[dancer-users] How can a fork+system() Dancer app not create zombie processes?

Andrew Beverley andy at andybev.com
Mon Apr 3 12:21:36 BST 2017

On Mon, 3 Apr 2017 13:22:16 +0300 Shlomi Fish wrote:
> > Forking a web app is not as simple as it first seems. 
> Do you mean forking any web app or just Dancer apps? 

Yes, any web application, and probably any application that runs
continuously. The parent process needs to reap the child processes.

> > You need to take
> > an approach like the following (hopefully the comments will explain
> > without me regurgitating here, but feel free to ask for
> > clarification):
> > 
> > https://github.com/ctrlo/GADS/blob/cb8c9478dee8eac1f40a44486634173bed8d666d/lib/GADS/Record.pm#L1068
> > 
> I don't understand the code there in part because it uses too many
> custom APIs

As Racke says, you just need to use that concept. I.e. the parent
process forks a child; the child process terminates immediately after
it has spawned a grandchild, which allows the parent to reap the child.
The grandchild is then left hanging and becomes init's responsibility.

> like "guard"s

You should consider a guard, to ensure that nothing in the grandchild
causes it to hang around. For example, if there is an exception which
is then caught before the _exit(), you can end up with the grandchild
hanging around serving web requests to nobody ;-)

> and "try".

You can ignore that.

> Furthermore, the licence is the AGPLv3 which cannot be used inside my
> MIT Expat code.

IANAL, but I wouldn't say that small snippet of code is copywritable.
Nonetheless, I can speak with authority for Ctrl O, and you are welcome
to freely copy without condition that whole forking section if you want.


More information about the dancer-users mailing list