process forking

Hi! I’m writing a web-based application in Perl that will be running on a Linux machine. At a user's request, the program needs to do some calculations that are supposed to be running on the background. I'm wondering if perl allows to fork a process if it is actually running on a webserver (i know it's not a problem if you start a program through prompt). Thanks a lot
izloch2Asked:
Who is Participating?
 
jhurstCommented:
fork works fine on such a server

I do it all the time.  

However, I would actually suggest a shell out of some type to a background process, using &, instead.  This way you will not have the problem of the first process remaining defunt until the second completes.
0
 
ravenplCommented:
> This way you will not have the problem of the first process remaining defunt until the second completes.
This is somewhow wrong. Father never enters <defunc> state. Its the child, if father will not gather it after it's dead.

But even if You meant that it's child who will not be waited become zombie - it's not really problem if it will be gathered eventually.
0
 
jhurstCommented:
I agree on the zombies going away eventually, however it is really better not to have them.  And actually the parent does remain until the signal comes from the child.
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

 
ravenplCommented:
> And actually the parent does remain until the signal comes from the child.
Disagree. In fact if the father dies before it's children, children get new parent - init process. And init will gather them immediatelly, so no zombies...
0
 
jhurstCommented:
just checked the O'Reilly book and also the perldoc -f fork.  In both cases it says:

"If you fork witjout ever waiting for your children..."

Basically, the parent is expected to wait for the child to send its signal.  I suspect that where we may be disagreeing here is which process.  The important facts are:

1) fork is VERY efficient - makes it desirable to use
2) sadly it leaves zombies until both jobs are done


0
 
ravenplCommented:
Of course books are saying so.
But on the other hand, I saw many applications, which are spawning children to do the job and exitig. No zombies (Your 2). As I said it before - init becomes the father of any orphanted child. It's perfectly fine to use this feature.
0
 
yaakovbCommented:
Please read `perldoc perlipc` or `man perlipc` and search for the word "zombie":

On most Unix platforms, the "CHLD" (sometimes also known as "CLD")
signal has special behavior with respect to a value of 'IGNORE'.  Setting
$SIG{CHLD} to 'IGNORE' on such a platform has the effect of not
creating zombie processes when the parent process fails to "wait()" on
its child processes (i.e. child processes are automatically reaped).
Calling "wait()" with $SIG{CHLD} set to 'IGNORE' usually returns "-1"
on such platforms.

Thus, setting $SIG{CHLD}="IGNORE" will resolve the zombie problem.

You also might want to detach your child from the parent ---- so that terminating
the parent will not kill the child.  For that, search for "daemonize" in the same
perlipc manpage:

  In some cases (starting server processes, for instance) you'll want to
  completely dissociate the child process from the parent.  This is often
  called daemonization.  A well behaved daemon will also chdir() to the
  root directory (so it doesn't prevent unmounting the filesystem con-
  taining the directory from which it was launched) and redirect its
  standard file descriptors from and to /dev/null (so that random output
  doesn't wind up on the user's terminal).

           use POSIX 'setsid';

           sub daemonize {
               chdir '/'               or die "Can't chdir to /: $!";
               open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
               open STDOUT, '>/dev/null'
                                       or die "Can't write to /dev/null: $!";
               defined(my $pid = fork) or die "Can't fork: $!";
               exit if $pid;
               setsid                  or die "Can't start a new session: $!";
               open STDERR, '>&STDOUT' or die "Can't dup stdout: $!";
           }

   The fork() has to come before the setsid() to ensure that you aren't a
   process group leader (the setsid() will fail if you are).  If your sys-
   tem doesn't have the setsid() function, open /dev/tty and use the
   "TIOCNOTTY" ioctl() on it instead.  See tty(4) for details.

In addition, you might want do
    close STDOUT;

in the parent process: This will inform the web server that the response is finished, even though the child process is still running.

I use these three techniques combined for starting background processes through CGI scripts.  The biggest remaining problem is to get some diagnostic output from the child process back to the browser.  

While this is not included in your question, it is a real problem: One wrong character in the program could simply get you no response --- with no clue where to start looking for the problem.

Here is what I do:
* set $SIG{"__WARN__"} and $sig{__DIE__} to a routine that writes the message to some file on the disk.
* In some applications, I also re-direct STDOUT/STDERR to a file (in fact, I do this rarely).
* Write a simple chi-script to inspect these message files and to delete them when they are no longer needed.

0
 
ozoCommented:
use Proc::Daemon
or see
Complete Dissociation of Child from Parent
in
perldoc perlipc
or
perldoc -q background
or
perldoc -q fork
0
 
jhurstCommented:
do the split if ozo does not get a respomse
0
 
ravenplCommented:
Strange You are going accept somehow wrong answers - I pointed some issues.
0
 
ravenplCommented:
Bad thing happen on the EE if wrong answer gets accepted by Moderator...
0
 
jhurstCommented:
ravenpl, what exactly do you think is wrong in the accepted answer, please be specific, no "many application..." type comments.  I may learn something from this, thanks in advance
0
 
ravenplCommented:
> This way you will not have the problem of the first process remaining defunt until the second completes.
This is untrue. I assume first is the father, and second is the child. I already pointed that out. Seems not only moderator skipped my comment but You also.
0
 
jhurstCommented:
I would just like to add to this that this is the first time in many years of using experts-exchange that I have seen such unpleasantness and quibllig.
0
 
ravenplCommented:
Uh oh - I'd like to note that it's not the first time here, that I see wrong answers! Should I be quiet about that?!? So I will not be unpleasant? That's Your idea for Expert-Exchange?
Don't bother to answer - I already have my idea. And don't bother to write here anything else - like I got prejudiced...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.