Re: SOLVED! (was: Re: What is wrong with this query?)
- Original Message -
From: "Mike Wexler" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, December 25, 2002 6:43 PM
Subject: Re: SOLVED! (was: Re: What is wrong with this query?)
> This is getting a little bit away from mysql
You are right, Mike, and, after this post, I will take the Perl argument
off-list. Just FYI, for those who thought my method of daemonizing was all
wrong, here is the documented way I used, and have been using for years.
http://www.perldoc.com/perl5.6/pod/perlipc.html#Complete-Dissociation-of-Chi
ld-from-Parent
They gave the following example, which is exactly what I do:
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: $!";
}
> but the easy way to
> do this is:
>
> use Proc::Daemon;# Available at a CPAN near you :-)
>
> Proc::Daemon::Init;
I will have a look at that. Thanks. :)
> But this still doesn't explain (at least to me) the lost connection.
>
> Unless the $dbh was created before daemonizing and the child
> process closed the connection on exiting.
No, $dbh is created inside the child. Basically the only purpose of my
parent is to fork and to write a PID.
I found another interesting article, at:
http://artsandtechnology.humber.ac.uk/~dcobham/Teaching/CMC041/unixproc.html
What is interesting about it, that they use a "sleep 5" too, directly after
the fork () call. Apparently they reason Perl needs just a wee time to gets
its signals / pipes in order for the child. And that may just really be all
there is to it. Though it took me a darn while to figure out. :)
- Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: SOLVED! (was: Re: What is wrong with this query?)
This is getting a little bit away from mysql but the easy way to do this is:
use Proc::Daemon;# Available at a CPAN near you :-)
...
Proc::Daemon::Init;
which takes care of all the details of daemonizing your program.
But this still doesn't explain (at least to me) the lost connection.
Unless the $dbh was created before daemonizing and the child process
closed the connection on exiting.
Mark wrote:
- Original Message -
From: "Rick Robinson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 24, 2002 12:03 PM
Subject: RE: SOLVED! (was: Re: What is wrong with this query?)
It's not a true daemon ...
No. It is only called a zombie if the child was brutally cut off from the
parent. If the parent/child take appropriate action, the stand-alone child
is called a daemon (if it waits for connections, of course). That is, the
parent closes its terminals and forks; the child, in turn, still has one
step to perform: it needs to become a session leader, so that it becomes a
parent himself. That is done with the "POSSIX::sessid ()" call. This is a
pretty standard way in Perl to daemonize.
Mike's comment on using a wait or waitpid is valid.
No. "wait" and "waitpid" are only useful when you want to wait for your
children. That does not apply here. The sole function of the parent here is
to close its terminals, fork, and write the child's PID to a file; after
that, it can exit, and the daemonized child remains running.
Your process is still associated with
a terminal and is not the process group leader and is not the session
leader.
You are mistaken on all counts. All terminals were closed, and the program
is certainly a session leader. Let me show what the daemonized "child"
(really a parent now) looks like in "ps -auxr":
news 34 0.0 1.1 12276 11580 ?? Ss 2:05PM 0:23.22 /usr/local/bin/news.pl
As you can see from the flags ("Ss"), this process is no longer a child, but
a sleeping ("S") session leader ("s"). And it has no terminals associated
with it ("??").
If I do a "ps -alxr", its PPID (Parent Process Id) is 1, the 'init' process.
With the exception of being a child of the init process (like pretty much
every other process), the child is fully stand-alone.
I am not sure how to go about in C, but this is how it is done in Perl.
- Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: SOLVED! (was: Re: What is wrong with this query?)
- Original Message -
From: "Rick Robinson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 24, 2002 12:03 PM
Subject: RE: SOLVED! (was: Re: What is wrong with this query?)
> It's not a true daemon ...
No. It is only called a zombie if the child was brutally cut off from the
parent. If the parent/child take appropriate action, the stand-alone child
is called a daemon (if it waits for connections, of course). That is, the
parent closes its terminals and forks; the child, in turn, still has one
step to perform: it needs to become a session leader, so that it becomes a
parent himself. That is done with the "POSSIX::sessid ()" call. This is a
pretty standard way in Perl to daemonize.
> Mike's comment on using a wait or waitpid is valid.
No. "wait" and "waitpid" are only useful when you want to wait for your
children. That does not apply here. The sole function of the parent here is
to close its terminals, fork, and write the child's PID to a file; after
that, it can exit, and the daemonized child remains running.
> Your process is still associated with
> a terminal and is not the process group leader and is not the session
> leader.
You are mistaken on all counts. All terminals were closed, and the program
is certainly a session leader. Let me show what the daemonized "child"
(really a parent now) looks like in "ps -auxr":
news 34 0.0 1.1 12276 11580 ?? Ss 2:05PM 0:23.22 /usr/local/bin/news.pl
As you can see from the flags ("Ss"), this process is no longer a child, but
a sleeping ("S") session leader ("s"). And it has no terminals associated
with it ("??").
If I do a "ps -alxr", its PPID (Parent Process Id) is 1, the 'init' process.
With the exception of being a child of the init process (like pretty much
every other process), the child is fully stand-alone.
I am not sure how to go about in C, but this is how it is done in Perl.
- Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: SOLVED! (was: Re: What is wrong with this query?)
It's not a true daemon...Mike's comment on using a wait or waitpid is valid. If you're interested, read up on daemon processes in APUE (chap. 13) from Stevens. Your process is still associated with a terminal and is not the process group leader and is not the session leader. I highly recommend it if you're going to write daemon processes. Best of luck, R -Original Message- From: Mark [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 02:51 PM To: Michael T. Babcock Cc: [EMAIL PROTECTED] Subject: Re: SOLVED! (was: Re: What is wrong with this query?) - Original Message - From: "Michael T. Babcock" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 8:14 PM Subject: Re: SOLVED! (was: Re: What is wrong with this query?) > >It seems that the parent exit-ing while the > >child is doing stuff, makes the child lose its query to MySQL (always > >more or less at the same point). And this is really strange; for the parent > >has nothing to do with MySQL. It is the child who makes the > >connection and does all queries. So, having the parent linger a bit > >should have no affect on the child. Yet it does. > > > > > > I'm not a PERL god, but from C experience, try looking up "wait" and > "wait" on your child instead of just exiting. I do not understand what you mean. This is not a parent process that uses a "waitpid" to reap its died-off children, but a daemon process where the parent spawns a stand-alone child, fully dissociated from the parent by closing STDIN, STDOUT, and setting its own session id, where the parent can exit as soon as $pid is defined. At least, that is how I always understood the process. But in light of recent events, maybe not... - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: SOLVED! (was: Re: What is wrong with this query?)
- Original Message - From: "Michael T. Babcock" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 8:14 PM Subject: Re: SOLVED! (was: Re: What is wrong with this query?) > >It seems that the parent exit-ing while the > >child is doing stuff, makes the child lose its query to MySQL (always > >more or less at the same point). And this is really strange; for the parent > >has nothing to do with MySQL. It is the child who makes the connection > >and does all queries. So, having the parent linger a bit should have no > >affect on the child. Yet it does. > > > > > > I'm not a PERL god, but from C experience, try looking up "wait" and > "wait" on your child instead of just exiting. I do not understand what you mean. This is not a parent process that uses a "waitpid" to reap its died-off children, but a daemon process where the parent spawns a stand-alone child, fully dissociated from the parent by closing STDIN, STDOUT, and setting its own session id, where the parent can exit as soon as $pid is defined. At least, that is how I always understood the process. But in light of recent events, maybe not... - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: SOLVED! (was: Re: What is wrong with this query?)
I do not understand why. It seems that the parent exit-ing while the child is doing stuff, makes the child lose its query to MySQL (always more or less at the same point). And this is really strange; for the parent has nothing to do with MySQL. It is the child who makes the connection and does all queries. So, having the parent linger a bit should have no affect on the child. Yet it does. I'm not a PERL god, but from C experience, try looking up "wait" and "wait" on your child instead of just exiting. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. SQL http://www.fibrespeed.net/~mbabcock - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
SOLVED! (was: Re: What is wrong with this query?)
- Original Message -
From: "Mark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 23, 2002 3:13 PM
Subject: What is wrong with this query?
> For month now I have been plagued by the "Lost connection to MySQ
> server during query" in a Perl program of mine that connects locally to
> /tmp/mysql.sock.
Dear folks,
At long last I found the cause of this nagging problem; it had nothing to do
with MySQL, but with Perl. The cause is so bizarre, that I feel other people
may benefit from my solution. If not, it makes for an interesting story. :)
Ok, her goes.
My own Perl news server, like any other daemon, daemonizes at some point;
like so:
chdir ('/') || exit 1;
open STDIN, '/dev/null';
open STDOUT, '>/dev/null';
if (my $pid = fork ()) {
open (USERLOG, ">".'/var/run/news.pid') || exit 1;
flock (USERLOG, 2);
seek (USERLOG, 0, 0);
print USERLOG " $pid";
close (USERLOG);
system ("/usr/sbin/chown news:news /var/run/news.pid");
exit 0;
}
POSIX::setsid () || exit 1;
Etc.
It is hard to spot, but the culprit was already in this block of code: the
system call to "chown". Literally having taken the program apart, line by
line, I found out, to my astonishment, that when I remove the "chown" line,
that then everything remains stable. If I leave it in, I get the imfamous
"Lost connection to MySQL server during query" within seconds; or, at least,
very regularly.
I solved this by adding a "sleep 5" after the chown command, and before the
"exit 0". For reasons beyond my grasp, having the parent wait an extra 5
seconds, while the child does its start-up stuff, makes all the difference.
I do not understand why. It seems that the parent exit-ing while the child
is doing stuff, makes the child lose its query to MySQL (always more or less
at the same point). And this is really strange; for the parent has nothing
to do with MySQL. It is the child who makes the connection and does all
queries. So, having the parent linger a bit should have no affect on the
child. Yet it does.
It may be that the extra system shell, before the parent exists, interferes
with the child upon exit. But I cannot see how (perhaps STDIN and STDOUT get
rearranged?). Still, adding a "sleep 5" after the parent system call solves
all the problems. Permanently. Just did a loop-test; 100 out of a 100
start-ups went ok. Remove the "sleep 5", and the child goes haywire again.
Perhaps this is trivial to you. In that case, more power to you! But it was
not trivial to me. It took me months to figure this one out.
And so we learn. :)
- Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
