speedycgi-users — Speedycgi user discussion

Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red Hat 9

[Sam H. <sa...@da...>]

I'll look at it once I can get an RH-9 system.  I downloaded the CD's
yesterday, so now I just need to find some time to install it.  RH-8 has
the same version of perl (5.8), and it compiles there, so I don't know
where the RH-9 problem is yet.

You could probably comment out that setdefout() call if you're desperate
to get something working right away.  All it does is essentially
"select(STDOUT);", in case the previous run of the perl code selected another
filehandle as the default output.

 > Details of this problem have been logged as a bug, but I'm hoping someone
 > has a suggestion to solve this as SpeedyCGI is an important component of a
 > system I'm putting together.
 > 
 > Any responses would be of interest.
 > 
 > Regards,
 > 
 > Ron
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by: If flattening out C++ or Java
 > code to make your application fit in a relational database is painful, 
 > don't do it! Check out ObjectStore. Now part of Progress Software.
 > http://www.objectstore.net/sourceforge
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users
 > 

[Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red Hat 9

[<re...@th...>]

Details of this problem have been logged as a bug, but I'm hoping someone
has a suggestion to solve this as SpeedyCGI is an important component of a
system I'm putting together.

Any responses would be of interest.

Regards,

Ron

RE: [Speedycgi-users] open temp file: Permission denied

[Jesper D. <da...@cy...>]

> I don't know what the instructions say, but you've got an=20
> extraneous space in there after the Speedycgi -T option. =20
> Your shebang line should read:
>=20
>  #!/usr/local/bin/speedy_suid -T -- -T/tmp/speedy
>=20
> Actually, there's no reason for that option at all since=20
> /tmp/speedy is the default temp-base.  You can just use:
>=20
>  #!/usr/local/bin/speedy_suid -T
>=20
>=20

Hmm, ok. If that was the problem, then the expected behavior would be
that it would never work. That is not the case, onle every third request
or so fails. Actually I think I allready tried ...

#!/usr/local/bin/speedy_suid -T

... cause the speedy man page said that /tmp/speedy was the default.

/Jesper

RE: [Speedycgi-users] open temp file: Permission denied

[Jesper D. <da...@cy...>]

> Which version of openwebmail do you use?
> Openwebmail before 2.00 won't work with speedycgi because of=20
> the problem you=20
> stated. Please try the openwebmail-current.tgz.

Im using OpenWebmail 2.01 on FreeBSD 4.8

/Jesper

Re: [Speedycgi-users] open temp file: Permission denied

[Sam H. <sa...@da...>]

I don't know what the instructions say, but you've got an extraneous space
in there after the Speedycgi -T option.  Your shebang line should read:

 #!/usr/local/bin/speedy_suid -T -- -T/tmp/speedy

Actually, there's no reason for that option at all since /tmp/speedy is the
default temp-base.  You can just use:

 #!/usr/local/bin/speedy_suid -T


 > Hi,
 > 
 > Im new to the list, so please forgive me if this problem has been
 > discussed before. I didn't find any useful information in the archives
 > though.
 > 
 > Here goes..
 > 
 > Im installing openwebmail, and want to use speedyCGI, s=E5 I follow the
 > openwebmail instructions and use
 > 
 > #!/usr/local/bin/speedy_suid -T -- -T /tmp/speedy
 > 
 > At first it seemed to work, backend threads were started, but every
 > other time I request a script, I get an internal server error, with the
 > following in the apache error log..
 > 
 > speedy_backend[51086]: open temp file: Permission denied
 > 
 > 
 > Is this a common problem? Openwebmail gets some of the backend threads
 > started as root, and some of them as the user logged in, which I think
 > might be the problem, I mean if the su'ed user tries to alter some of
 > the temp files that root created and so on..
 > 
 > in /tmp/, I have several speedy.whatever files.
 > 
 > Any help would be appriciated,
 > 
 > 
 > best regards,
 > 
 > Jesper Dalberg,
 > Cybercity Internet

[Speedycgi-users] open temp file: Permission denied

[Jesper D. <da...@cy...>]

Hi,

Im new to the list, so please forgive me if this problem has been
discussed before. I didn't find any useful information in the archives
though.

Here goes..

Im installing openwebmail, and want to use speedyCGI, s=E5 I follow the
openwebmail instructions and use

#!/usr/local/bin/speedy_suid -T -- -T /tmp/speedy

At first it seemed to work, backend threads were started, but every
other time I request a script, I get an internal server error, with the
following in the apache error log..

speedy_backend[51086]: open temp file: Permission denied


Is this a common problem? Openwebmail gets some of the backend threads
started as root, and some of them as the user logged in, which I think
might be the problem, I mean if the su'ed user tries to alter some of
the temp files that root created and so on..

in /tmp/, I have several speedy.whatever files.

Any help would be appriciated,


best regards,

Jesper Dalberg,
Cybercity Internet

[Speedycgi-users] Configuring Perl version used by speedy.

[2pin <2p...@di...>]

SGksDQoNCkkgaGF2ZSBpbnN0YWxsZWQgdGhlIGxhdGVzdCBzcGVlZHkgb24gYSByZWQgNy4zIG1h
Y2hpbmUuIFRoaXMgbWFjaGluZSBoYXMgYSBudW1iZXIgb2YgZGlmZmVyZW50IHZlcnNpb25zb2Yg
cGVybCBpbnN0YWxsZWQuIEJ5IGRlZmF1bHQgc3BlZWR5IGlzIHVzaW5nIG9uZSBvZiB0aGVtLiBJ
cyBpdCBwb3NzaWJsZSB0byBzcGVjaWZ5IHdoaWNoIHZlcnNpb24gKHBhdGgpIHNwZWVkeSBzaG91
bGQgdXNlIGZvciBwZXJsPw0KDQpUaGFua3MuDQoNCjJwaW4uDQoNClAuUy4gSXQgd2FzJ250IG1l
IHdobyBpbnN0YWxsZWQgYWxsIG9mIHRoZSB2ZXJzaW9ucyBvbiB0aGUgbWFjaGluZSBjYXVzaW5n
IHRoaXMgbWVzcyEK

[Speedycgi-users] mod_speedy and setuid scripts

[Chung-Kie T. <tu...@tu...>]

Hi Sam,

Does mod_speedyCGI support setuid root? 

Since mod_speedy is at the same process space as apache and apache is not 
recommended to run with root uid, the mod_speedy won't have the root 
permission. But the script is actually compiled and executed by the 
speedy_backend, so it seems the backend can just run the script with any 
permission it wants no matter what the euid of mod_speedy is.

My suggestion is to have a option in mod_speedy to specify the names of 
scripts that are allowed to be executed with root. Than speedy_backend can 
check the script setuid bit to determine if the script should be executed 
with setuid.

Regards.

tung
--
Distributed System Laboratory (http://dslab.ee.ncku.edu.tw)
Department of Electrical Engineering
National Cheng Kung University, Tainan, Taiwan, R.O.C.

[Speedycgi-users] an option for speedy to sepcify the path of script

[Chung-Kie T. <tu...@tu...>]

Hi Sam,

I have tried the SpeedyCGI with setuid scripts on solaris before I know that
is not supported. The message I got was

speedy_backend[9787]: /dev/fd/3: Bad file number
speedy[9785]: Cannot spawn backend process

According to this error msg and since solaris passes the /dev/fd/N instead of
the path of the setuid script to the interpreter for security reason, I guess
this may be one of the reasons why speedyCGI doesn't support setuid on solaris.

Amd if this is the only reason, how about an option for speedy to specify the
full pathname of the script itself, and this option can be passed to
speedy_backend by speedy. 

Regards.

tung
--
Distributed System Laboratory (http://dslab.ee.ncku.edu.tw)
Department of Electrical Engineering
National Cheng Kung University, Tainan, Taiwan, R.O.C.

Re: [Persistentperl-users] RE: [Speedycgi-users] Help with STDOUT

[Sam H. <sa...@da...>]

How about putting a frontend in front of your script like this:

    (sed "s/^/MAIL/"; sed "s/^/ENVELOPE/" 0<&1) | yourscript.pl

Then in yourscript.pl do this:

    while (<STDIN>) {
	s/^(MAIL|ENVELOPE)//;
	if ($1 eq 'MAIL') {
	    # $_ is a line from the mail message
	}
	else {
	    # $_ is a line from the envelope
	}
    }

 > Here is the problem...
 > 
 > SYNOPSIS
 >        qmail-queue
 > 
 > DESCRIPTION
 >        qmail-queue  reads a mail message from descriptor 0.  It then reads envelope information from descriptor 1.  It
 >        places the message into the outgoing queue for future delivery by qmail-send.
 > 
 > qmail-queue is what I am replacing with my own custom script.  qmail-queue is written in C, and can read descriptor 0 (the message) from qmail-smtpd, and read descriptor 1 (the envelope) from qmail-smtpd.   A script written in perl can read both descriptors also, but once I try to write the script in perperl, it wont work because it cannot read descriptor 1, and I cant get everything to pass out of qmail-smtpd on descriptor 0 without a major rewrite of the qmail-smtpd code.
 > 
 > Thanks,
 > Dallas
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by:Crypto Challenge is now open! 
 > Get cracking and register here for some mind boggling fun and 
 > the chance of winning an Apple iPod:
 > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
 > _______________________________________________
 > Persistentperl-users mailing list
 > Per...@li...
 > https://lists.sourceforge.net/lists/listinfo/persistentperl-users
 > 

RE: [Persistentperl-users] RE: [Speedycgi-users] Help with STDOUT

[Dallas E. <da...@nm...>]

> -----Original Message-----
> From: Sam Horrocks [mailto:sa...@da...]
> Sent: Thursday, March 13, 2003 3:22 PM
> To: Dallas Engelken
> Cc: per...@li...;
> spe...@li...
> Subject: Re: [Persistentperl-users] RE: [Speedycgi-users] Help with
> STDOUT=20
>=20
>=20
> You should be able to do email filtering with the current=20
> implementation.
> Just read from STDIN.
>=20

Here is the problem...

SYNOPSIS
       qmail-queue

DESCRIPTION
       qmail-queue  reads a mail message from descriptor 0.  It then =
reads envelope information from descriptor 1.  It
       places the message into the outgoing queue for future delivery by =
qmail-send.

qmail-queue is what I am replacing with my own custom script.  =
qmail-queue is written in C, and can read descriptor 0 (the message) =
from qmail-smtpd, and read descriptor 1 (the envelope) from qmail-smtpd. =
  A script written in perl can read both descriptors also, but once I =
try to write the script in perperl, it wont work because it cannot read =
descriptor 1, and I cant get everything to pass out of qmail-smtpd on =
descriptor 0 without a major rewrite of the qmail-smtpd code.

Thanks,
Dallas

Re: [Persistentperl-users] RE: [Speedycgi-users] Help with STDOUT

[Sam H. <sa...@da...>]

You should be able to do email filtering with the current implementation.
Just read from STDIN.


 > ah, ignore my other post.  it looks like it's impossible at this point.   it would be cool if perperl could act like perl and suidperl in this case... it would speed up my email processing tremendously because i would have no overhead for the perl invocation or establishing a DBI connection on each email for logging.   
 > 
 > i'll keep an eye out for future releases.. i hope it is something you will consider. 

[Speedycgi-users] Re: [Persistentperl-users] Followup to my STDOUT issue

[Sam H. <sa...@da...>]

 > My question to you is, why can I read the STDOUT when I use the perl or suidperl interpreter but not perperl.  

 Because PersistentPerl does not support reading input from STDOUT.  The
 PersistentPerl code is not written to accomodate that.

 The reasons PersistentPerl doesn't support reading from STDOUT are:

 	1) It's not trivial to implement in the current way of doing things.

	2) An overwhelming majority of the the perl programs out there
	   use STDOUT only for output.  They do this because, by Unix
	   convention, STDOUT is used for output, not input.

RE: [Speedycgi-users] Help with STDOUT

[Dallas E. <da...@nm...>]

> -----Original Message-----
> From: Sam Horrocks [mailto:sa...@da...]
> Sent: Thursday, March 13, 2003 1:04 PM
> To: Dallas Engelken
> Cc: per...@li...;
> spe...@li...
> Subject: Re: [Speedycgi-users] Help with STDOUT=20
>=20
>=20
> Your script is trying to read input from STDOUT, is that=20
> correct?  That
> won't work - STDOUT works only for output, not input.
>=20
> This might work, if and when I add code to pass filehandles,=20
> but at the
> moment, PersistentPerl won't do that.
>=20

ah, ignore my other post.  it looks like it's impossible at this point.  =
 it would be cool if perperl could act like perl and suidperl in this =
case... it would speed up my email processing tremendously because i =
would have no overhead for the perl invocation or establishing a DBI =
connection on each email for logging.  =20

i'll keep an eye out for future releases.. i hope it is something you =
will consider.=20

thanks,
dallas

[Speedycgi-users] RE: [Persistentperl-users] Followup to my STDOUT issue

[Dallas E. <da...@nm...>]

> -----Original Message-----
> From: Sam Horrocks [mailto:sa...@da...]
> Sent: Thursday, March 13, 2003 1:11 PM
> To: Dallas Engelken
> Cc: per...@li...;
> spe...@li...
> Subject: Re: [Persistentperl-users] Followup to my STDOUT issue=20
>=20
>=20
>  > When I look at Step 3 on how speedy works, I see that it=20
> does not pipe STDOUT to the backend?
> =20
> That's true.  STDOUT is sent from the backend to the frontend=20
> as output
> from the script.  STDOUT, is not sent from the frontend to the backend
> for input.  STDOUT is an output channel.
>=20
> > How am I supposed to read STDOUT from a previous pipe into=20
> my script??
>=20
> With STDIN.
> =20
> > Like the one I posted before.  I'm trying to write a filter=20
> that mail pipes through, but I dont want to invoke a perl=20
> interpreter for each email!   In order to get the envelope=20
> addresses, I have to read STDOUT from the qmail-smtpd pipe to=20
> my script.
>=20
> That should work.  In pipes, the STDOUT of the previous command
> (qmail in this case) becomes STDIN for the next command (your script).
> Should work fine.  STDIN is passed by the frontend from the=20
> pipe to the
> backend's STDIN, the backend reads it, produces output on STDOUT, then
> STDOUT is copied from the backend to the frontend, where the frontend
> emits it on its STDOUT.
>=20
>=20

Thanks for the response Sam.  My question to you is, why can I read the =
STDOUT when I use the perl or suidperl interpreter but not perperl. =20

Did you see my DEBUG output from my first post?  perl and suidperl can =
read the  =20

> SOUT LINE: Fda...@nm...@nmgi.com=20

but perperl cannot.

Thanks,
Dallas

[Speedycgi-users] Re: [Persistentperl-users] Followup to my STDOUT issue

[Sam H. <sa...@da...>]

 > When I look at Step 3 on how speedy works, I see that it does not pipe STDOUT to the backend?
 
That's true.  STDOUT is sent from the backend to the frontend as output
from the script.  STDOUT, is not sent from the frontend to the backend
for input.  STDOUT is an output channel.

> How am I supposed to read STDOUT from a previous pipe into my script??

With STDIN.
 
> Like the one I posted before.  I'm trying to write a filter that mail pipes through, but I dont want to invoke a perl interpreter for each email!   In order to get the envelope addresses, I have to read STDOUT from the qmail-smtpd pipe to my script.

That should work.  In pipes, the STDOUT of the previous command
(qmail in this case) becomes STDIN for the next command (your script).
Should work fine.  STDIN is passed by the frontend from the pipe to the
backend's STDIN, the backend reads it, produces output on STDOUT, then
STDOUT is copied from the backend to the frontend, where the frontend
emits it on its STDOUT.

Re: [Speedycgi-users] Help with STDOUT

[Sam H. <sa...@da...>]

Your script is trying to read input from STDOUT, is that correct?  That
won't work - STDOUT works only for output, not input.

This might work, if and when I add code to pass filehandles, but at the
moment, PersistentPerl won't do that.


 > I have a problem grabbing STDOUT with PersistentPerl.  It works fine when called via /usr/bin/perl or /usr/bin/suidperl.  The script, and the debug output is below.   
 > 
 > perl and suidperl both have a line of STDOUT.  perperl does not.  WTF.
 > 
 > Thanks for any advice!
 > 
 > --------------
 > 
 > #!/usr/bin/suidperl -w
 > #!/usr/bin/perl -w 
 > #!/usr/bin/perperl -w -- -M20 -r5
 > # START TEST, RUN 3 TIMES USING DIFFERENT INTERPRETERS LISTED ABOVE
 > 
 >  select(STDIN); $|=1;
 > 
 >  while (<STDIN>) {
 >    chomp($_);
 >    &debug("STDIN LINE: $_");
 >  }
 >  close(STDIN);
 > 
 >  select(STDOUT); $|=1;
 >  open(SOUT,"<&STDOUT");
 >  while (<SOUT>) {
 >    &debug("SOUT LINE: $_");
 >  }
 > 
 > exit;
 > 
 > ##############################
 > 
 > sub debug {
 > 
 >  my $log = shift;
 > 
 >   open (T,">>/tmp/debug.log");
 >   flock(T,2);
 >   print T $log . "\n";
 >   close (T);
 > }
 > 
 > ##############################
 > # EOF
 > 
 > 
 > DEBUG OUTPUT UNDER PERPERL
 > ----------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:40:22 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:40:21 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN:
 > 
 > 
 > DEBUG OUTPUT UNDER PERL
 > ------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:42:08 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:42:07 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN: 
 > SOUT LINE: Fda...@nm...@nmgi.com 
 > 
 > 
 > DEBUG OUTPUT UNDER SUIDPERL
 > --------------------------
 > STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
 > STDIN:   by 0 with SMTP; 13 Mar 2003 15:43:06 -0000
 > STDIN: Message-ID: <3E7...@nm...>
 > STDIN: Date: Thu, 13 Mar 2003 09:43:06 -0600
 > STDIN: From: Dallas Engelken <da...@nm...>
 > STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212
 > STDIN: X-Accept-Language: en-us, en
 > STDIN: MIME-Version: 1.0
 > STDIN: To:  da...@nm...
 > STDIN: Subject: hi
 > STDIN: X-Enigmail-Version: 0.72.0.0
 > STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
 > STDIN: Content-Type: text/plain; charset=us-ascii; format=flowed
 > STDIN: Content-Transfer-Encoding: 7bit
 > STDIN: 
 > STDIN: hi
 > STDIN: 
 > SOUT LINE: Fda...@nm...@nmgi.com
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by:Crypto Challenge is now open! 
 > Get cracking and register here for some mind boggling fun and 
 > the chance of winning an Apple iPod:
 > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
 > _______________________________________________

[Speedycgi-users] Followup to my STDOUT issue

[Dallas E. <da...@nm...>]

I was reading the docs on how speedy works, and seen

When executed, the speedy frontend does the following:
   1. Looks for an available backend to run this script.
   2. If no backends are available, starts a new one.
   3. As soon as a backend is located, connects to it and starts to send =
over %ENV, @ARGV and the STDIN data.
   4. Brings back the STDOUT and STDERR data from the backend and sends =
it to its output.=20

The speedy backend does the following:
   1. Initializes the perl interpreter and compiles the perl script
   2. Waits for a frontend to contact it
   3. Once a frontend contacts it, reads in and initializes %ENV and =
@ARGV
   4. Sets up STDIN, STDOUT and STDERR so that they are connected to the =
frontend via Unix sockets.
   5. Executes the perl code.
   6. Goes back and waits for another frontend to contact it.=20


When I look at Step 3 on how speedy works, I see that it does not pipe =
STDOUT to the backend?  How am I supposed to read STDOUT from a previous =
pipe into my script??  Like the one I posted before.  I'm trying to =
write a filter that mail pipes through, but I dont want to invoke a perl =
interpreter for each email!   In order to get the envelope addresses, I =
have to read STDOUT from the qmail-smtpd pipe to my script.

Is this impossible with perperl or should I maybe look into fastcgi?

Thanks.
Dallas

[Speedycgi-users] Help with STDOUT

[Dallas E. <da...@nm...>]

I have a problem grabbing STDOUT with PersistentPerl.  It works fine =
when called via /usr/bin/perl or /usr/bin/suidperl.  The script, and the =
debug output is below.  =20

perl and suidperl both have a line of STDOUT.  perperl does not.  WTF.

Thanks for any advice!

--------------

#!/usr/bin/suidperl -w
#!/usr/bin/perl -w=20
#!/usr/bin/perperl -w -- -M20 -r5
# START TEST, RUN 3 TIMES USING DIFFERENT INTERPRETERS LISTED ABOVE

 select(STDIN); $|=3D1;

 while (<STDIN>) {
   chomp($_);
   &debug("STDIN LINE: $_");
 }
 close(STDIN);

 select(STDOUT); $|=3D1;
 open(SOUT,"<&STDOUT");
 while (<SOUT>) {
   &debug("SOUT LINE: $_");
 }

exit;

##############################

sub debug {

 my $log =3D shift;

  open (T,">>/tmp/debug.log");
  flock(T,2);
  print T $log . "\n";
  close (T);
}

##############################
# EOF


DEBUG OUTPUT UNDER PERPERL
----------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:40:22 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:40:21 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:


DEBUG OUTPUT UNDER PERL
------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:42:08 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:42:07 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:=20
SOUT LINE: Fda...@nm...@nmgi.com=20


DEBUG OUTPUT UNDER SUIDPERL
--------------------------
STDIN: Received: from unknown (HELO nmgi.com) (64.217.128.161)
STDIN:   by 0 with SMTP; 13 Mar 2003 15:43:06 -0000
STDIN: Message-ID: <3E7...@nm...>
STDIN: Date: Thu, 13 Mar 2003 09:43:06 -0600
STDIN: From: Dallas Engelken <da...@nm...>
STDIN: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; =
rv:1.3a) Gecko/20021212
STDIN: X-Accept-Language: en-us, en
STDIN: MIME-Version: 1.0
STDIN: To:  da...@nm...
STDIN: Subject: hi
STDIN: X-Enigmail-Version: 0.72.0.0
STDIN: X-Enigmail-Supports: pgp-inline, pgp-mime
STDIN: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed
STDIN: Content-Transfer-Encoding: 7bit
STDIN:=20
STDIN: hi
STDIN:=20
SOUT LINE: Fda...@nm...@nmgi.com

Re: [Speedycgi-users] FIXED!!!

[Sam H. <sa...@da...>]

When the backend is forked it keeps a copy of fd-2 from the frontend
(a direct copy of that fd, not a socket), and then if that's duped, the
backend can hold it open, even if the frontend exits.  It's probably a
pipe into the web-server, and the web-server is waiting for EOF on that
fd before considering the cgi done.  Since the backend is still running
and still hanging onto the other end of that pipe, it just hangs.

The reason the backend is given a direct copy of fd-2 is so that perl
compile errors will show up on stderr.

Maybe we could turn fd-2 into a pipe that is closed when the first frontend
exits.  That would fix the hang, but later runs of the perl code wouldn't
be able to write on that duped stderr file.



 > I found the problem - it was Parse::RecDescent (which is included by
 > Spreadsheet::WriteExcel).  Parse::RecDescent is dup-ing STDERR on _MODULE
 > LOAD_, which is screwing something up in speedy.  Adding the following
 > code to the beginning of my program fixed the problem.
 > 
 > BEGIN {
 > 	close(STDERR);
 > }
 > 
 > This prevented Parse::RecDescent from dup-ing a valid file descriptor, but
 > also screws up error reporting.  Is this a feature or a bug with speedy?
 > 
 > Alternatively, to keep STDERR, I might dup it, close it, load
 > Parse::RecDescent, dup it back, and then reclose the dup-d one.
 > 
 > Any ideas from users?
 > 
 > Jon
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.NET email is sponsored by: Geek Gift Procrastinating?
 > Get the perfect geek gift now!  Before the Holidays pass you by.
 > T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users

[Speedycgi-users] FIXED!!!

[Jonathan B. <jo...@es...>]

I found the problem - it was Parse::RecDescent (which is included by
Spreadsheet::WriteExcel).  Parse::RecDescent is dup-ing STDERR on _MODULE
LOAD_, which is screwing something up in speedy.  Adding the following
code to the beginning of my program fixed the problem.

BEGIN {
	close(STDERR);
}

This prevented Parse::RecDescent from dup-ing a valid file descriptor, but
also screws up error reporting.  Is this a feature or a bug with speedy?

Alternatively, to keep STDERR, I might dup it, close it, load
Parse::RecDescent, dup it back, and then reclose the dup-d one.

Any ideas from users?

Jon

[Speedycgi-users] Maybe not...

[Jonathan B. <jo...@es...>]

Hmmm...  Further tests indicate something else is going on here (the
examples are no longer working for me.  Will report back with more
information).

Jon

[Speedycgi-users] Speedy with Spreadsheet::WriteExcel

[Jonathan B. <jo...@es...>]

There's something wierd with Spreadsheet::WriteExcel.  If you use it, the
_first_ speedy connection will never end (subsequent ones are fine,
though).

Try the following two programs:

1)

#!/usr/bin/speedy

use Spreadsheet::WriteExcel

print(<<EOF);
Content-Type: text/html

<html>
<head>
<title>Test</title>
</head>
<body>
test
</body>
</html>
EOF

2)

#!/usr/bin/speedy

print(<<EOF);
Content-Type: text/html

<html>
<head>
<title>Test 2</title>
</head>
<body>
Test 2
</body>
</html>
EOF

When you first load it in your web browser, program #1 will never
terminate unless you reload it (the world keeps on spinning), or program
#1 won't ever display anything at all, depending on your setup.

Any ideas?  I'm pretty stumped.

Jonathan Bartlett

[Speedycgi-users] building speedy binary that supports dynamic loading?

[David G. <dav...@ic...>]

perl 5.8.0 (threaded), redhat 7.2 on i386

i can't seem to do this; there's no hint. i've also searched the archive.

with my speedy binary tries to run a script that uses a dynamically 
loaded module, it croaks as such:

Can't load module Sys::Hostname, dynamic loading not available in this 
perl. (You may need to build a new perl executable which either supports
dynamic loading or has the Sys::Hostname module statically linked into it.)

but once reverting to perl 5.6.0 and using the provided binary rpm at 
http://daemonic.com/SpeedyCGI/, all is well.

will there be a binary rpm for perl 5.8.0? or if not, could i get a hold 
to the spec file?

thanks in advance.

-- 
dave

Re: [Speedycgi-users] did you create the gateway between PersistentPerl & SpeedyCGI yet ?

[Sam H. <sa...@da...>]

No, the gateway isn't in place yet.

 > I hadn't seen traffic on the SpeedyCGI list in a long time, 
 > then I saw where someone had added a SpeedyCGI port to the 
 > OpenBSD ports system.
 > 
 > Wandering over to the SpeedyCGI page I see you have a new 
 > project called PersistentPerl, which is exactly what I've 
 > always used SpeedyCGI for.  You mentioned in the SpeedyCGI 
 > list that you were going to create a mail gateway between 
 > the 2 lists.  Has that happened yet?
 > 
 > thanks
 > 
 > diana eichert
 > 
 > 
 > 
 > -------------------------------------------------------
 > This sf.net email is sponsored by:ThinkGeek
 > Welcome to geek heaven.
 > http://thinkgeek.com/sf
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users