speedycgi-users — Speedycgi user discussion

Re: [Speedycgi-users] speedy-CGI and Command 'apxs -q CC' failed

[Lars T. <la...@th...>]

Sam Horrocks wrote:
 > I don't know where this port came from.  Try using the offical source 
code at:

The gentleman is most likely having trouble with his Apache 
installation, since 'apxs -q CC' returned a non-zero exit code. No reply 
when I asked him about this, back in March. It probably has nothing to 
do with the FreebBSD port of SpeedCGI, of which I am the humble maintainer.

 >  > FreeBSD-STABLE-4.9
 >  >
 >  > errors building CGI-SpeedyCGI-2.22 from /usr/ports  - any clues 
what I am
 >  > doing wrong here?
 >  >
 >  > ===>  Configuring for p5-CGI-SpeedyCGI-2.22
 >  > ERROR: Command 'apxs -q CC' failed.
 >  > *** Error code 2
 >  >
 >  > Stop in /usr/ports/www/p5-CGI-SpeedyCGI.

/Lars

Re: [Speedycgi-users] CGISpeedy: Browser not returning "DONE" when done.

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

THis is usually caused by a process started by the CGI that continues
running after the CGI is done.  If the background process continues to
keep stdout open, your web server won't see an EOF on the pipe, so it
just hangs.

Oracle is known to do this - this is documented with a workaround in the
SpeedyCGI documentation under Frequently Asked Questions.


 > Greetings,
 > 
 > 	CGI Speedy has been a really great addition to my Perl toolkit.  It
 > speeds up my CGI scripts tremendously.  Thanks!  I am however having one
 > small side-effect which I am hoping you could explain or offer tips on how
 > to fix:  When the CGI script loads for the 1st time, the browser (it does
 > not matter which one I use - IE, Firebird, Mozilla, Netscape), does not
 > return "Done" until you hit the "Stop" button or follow another link or the
 > "-T<sec>" value is reached (the little browser icon continues to spin, even
 > though the entire page content has been displayed).  However, on subsequent
 > hits on the same instance, it works fine.  This seems to only happen on our
 > "webfarm" servers (a cluster of Solaris servers, any of which can service a
 > request and this happens no matter which machine services the request).  It
 > does not matter which CGO script I run.  (And of course on our "test"
 > Solaris servers, this does not happen)  It's not a major problem, but is an
 > annoyance to my users and It generates calls.  I am running Speedy v2.11,
 > and the admins will resist upgrading.
 > 
 > Thanks in advance.
 > 
 > Jim Turner
 > Jim...@lm...
 > 
 > 
 > -------------------------------------------------------
 > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
 > Build and deploy apps & Web services for Linux with
 > a free DVD software kit from IBM. Click Now!
 > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users
 > 

Re: [Speedycgi-users] speedy-CGI and Command 'apxs -q CC' failed

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

I don't know where this port came from.  Try using the offical source code at:

http://daemoninc.com/SpeedyCGI/download.html

 > 
 > Hi!
 > 
 > FreeBSD-STABLE-4.9
 > 
 > errors building CGI-SpeedyCGI-2.22 from /usr/ports  - any clues what I am
 > doing wrong here?
 > 
 > 
 > ===>  Configuring for p5-CGI-SpeedyCGI-2.22
 > ERROR: Command 'apxs -q CC' failed.
 > *** Error code 2
 > 
 > Stop in /usr/ports/www/p5-CGI-SpeedyCGI.
 > 
 > 
 > 
 > thanks in advance,
 > 
 > Noah
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.Net email is sponsored by: IBM Linux Tutorials
 > Free Linux tutorial presented by Daniel Robbins, President and CEO of
 > GenToo technologies. Learn everything from fundamentals to system
 > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users

[Speedycgi-users] limiting memory usage for PHP as CGI

[Florian E. <fl...@ar...>]

Hello PHP users,

I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with
a huge PHP file involving some diagram creation, I can "kill" the machine if
I re-load the
script for five seconds continuously. It soaks up all my memory and runs for
nearly a minute multiple times. I've tried to limit that via php.ini's
memory limit setting and via Apache's RLimitCPU/RLimitNPROC/RLimitMEM
directive, but it does not seem to work.

Do you have any idea of what can be done in order to protect myself from
such an "attack"?

Thanks!
Florian

Re: [Speedycgi-users] speedy-CGI and Command 'apxs -q CC' failed

[Lars T. <la...@th...>]

Noah wrote:
> ===>  Configuring for p5-CGI-SpeedyCGI-2.22
> ERROR: Command 'apxs -q CC' failed.
> *** Error code 2

What happens if you run 'apxs -q CC' by hand?

/Lars

[Speedycgi-users] speedy-CGI and Command 'apxs -q CC' failed

[Noah <ad...@en...>]

Hi!

FreeBSD-STABLE-4.9

errors building CGI-SpeedyCGI-2.22 from /usr/ports  - any clues what I am
doing wrong here?


===>  Configuring for p5-CGI-SpeedyCGI-2.22
ERROR: Command 'apxs -q CC' failed.
*** Error code 2

Stop in /usr/ports/www/p5-CGI-SpeedyCGI.



thanks in advance,

Noah

[Speedycgi-users] CGISpeedy: Browser not returning "DONE" when done.

[Turner, J. (N-S. T. Resources) <jim...@lm...>]

Greetings,

	CGI Speedy has been a really great addition to my Perl toolkit.  It
speeds up my CGI scripts tremendously.  Thanks!  I am however having one
small side-effect which I am hoping you could explain or offer tips on how
to fix:  When the CGI script loads for the 1st time, the browser (it does
not matter which one I use - IE, Firebird, Mozilla, Netscape), does not
return "Done" until you hit the "Stop" button or follow another link or the
"-T<sec>" value is reached (the little browser icon continues to spin, even
though the entire page content has been displayed).  However, on subsequent
hits on the same instance, it works fine.  This seems to only happen on our
"webfarm" servers (a cluster of Solaris servers, any of which can service a
request and this happens no matter which machine services the request).  It
does not matter which CGO script I run.  (And of course on our "test"
Solaris servers, this does not happen)  It's not a major problem, but is an
annoyance to my users and It generates calls.  I am running Speedy v2.11,
and the admins will resist upgrading.

Thanks in advance.

Jim Turner
Jim...@lm...

[Speedycgi-users] speedy_suid and openwebmail

[Boreal A. <ja...@bo...>]

Hi,

BSDI - 4.3.1
Perl v5.8.1 built for i386-bsdos
Openwebmail 2.30
SpeedyCGI 2.22

I have openwebmail installed and running suidperl with no problems.
I'm trying to run it using SpeedyCGI suid-root, following instructions in 
openwebmail readme.txt
SpeedyCGI makes and makes install without errors.
When, via a browser, I call openwebmail.pl, I get Internal Server Error 
with 'Premature end of script header' error in my Apache 1.3.29 error_log. 
If I hit the refresh button a few times on my browser the page will load 
without errors. Each  openwebmail .pl script that I try to call will, after 
multiple hits of the refresh button, finally load. Once the scripts have 
loaded successfully calling them again will load them without error...as 
long as the entry for each Speedy process remains in the tmp file all works 
fine, even for other openwebmail users. If they are gone the scripts won't 
run until you hit the refresh button multiple times.

Anyone have any idea what might be causing this and how I might fix it?

Thanks

jack

Re: [Speedycgi-users] SpeedyCGI crashes in Mac OS X Panther

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

I'm not sure I follow - are you saying all scripts using
"#!/usr/bin/speedy" at the top will crash under this OS?

What version of SpeedyCGI is this?

Can you send a small script that demonstrates the problem?

 > Hello list
 > 
 > I managed to install SpeedyCGI on Mac OS X 10.3.2 (Panther), albeit only=20
 > by applying Sam's patch, which b.t.w. is not yet incorporated in the=20
 > latest release source. However, SpeedyCGI crashes whenever it gets=20
 > called by a script. I run SpeedyCGI via the Apache module. On Linux, the=20
 > same combo runs smooth. I have attached CrashReporter's output=20
 > concerning SpeedyCGI.
 > 
 > Thanks!
 > 
 > Best regards
 > 
 > Ph. Wiede
 > 
 > 
 > **********
 > 
 > Host Name:      xxx
 > Date/Time:      2004-01-07 01:01:09 +0100
 > OS Version:     10.3.2 (Build 7D24)
 > Report Version: 2
 > 
 > Command: speedy
 > Path:    /usr/bin/speedy
 > Version: ??? (???) -> 2.
 > PID:     846
 > Thread:  0
 > 
 > Exception:  EXC_BAD_ACCESS (0x0001)
 > Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc
 > 
 > Thread 0 Crashed:
 > 0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
 > 1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
 > 2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
 > 3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
 > 6)
 > 4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
 > (speedy_frontend.c:569)
 > 5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
 > 6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
 > 7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
 > 8   speedy     0x00001b28 start + 0x30
 > 
 > PPC Thread State:
 >    srr0: 0x00003328 srr1: 0x0200d030                vrsave: 0x00000000
 >      cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
 >      r0: 0x00003320   r1: 0xbfffed50   r2: 0x00000000   r3: 0x00000002
 >      r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
 >      r8: 0x00000000   r9: 0xbfffeda7  r10: 0x7f4eb9d0  r11: 0x0000a24c
 >     r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
 >     r16: 0xbffff9a4  r17: 0xbffff9a0  r18: 0x00000000  r19: 0x00000000
 >     r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
 >     r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa7c
 >     r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed90  r31: 0x00003284
 > 
 > Binary Images Description:
 >      0x1000 -     0x9fff speedy     speedy
 > 0x7f430000 - 0x7f508fff libperl.dylib=20
 > /System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
 > 0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
 > 0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
 > 0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
 > /usr/lib/system/libmathCommon.A.dylib
 > 
 > **********
 > 
 > Host Name:      guest.intra.megapublic.net
 > Date/Time:      2004-01-07 01:02:55 +0100
 > OS Version:     10.3.2 (Build 7D24)
 > Report Version: 2
 > 
 > Command: speedy
 > Path:    /usr/bin/speedy
 > Version: ??? (???)
 > PID:     851
 > Thread:  0
 > 
 > Exception:  EXC_BAD_ACCESS (0x0001)
 > Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc
 > 
 > Thread 0 Crashed:
 > 0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
 > 1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
 > 2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
 > 3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
 > 6)
 > 4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
 > (speedy_frontend.c:569)
 > 5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
 > 6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
 > 7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
 > 8   speedy     0x00001b28 start + 0x30
 > 
 > PPC Thread State:
 >    srr0: 0x00003328 srr1: 0x0200f030                vrsave: 0x00000000
 >      cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
 >      r0: 0x00003320   r1: 0xbfffed30   r2: 0x00000000   r3: 0x00000002
 >      r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
 >      r8: 0x00000000   r9: 0xbfffed87  r10: 0x7f4eb9d0  r11: 0x0000a24c
 >     r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
 >     r16: 0xbffff984  r17: 0xbffff980  r18: 0x00000000  r19: 0x00000000
 >     r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
 >     r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa60
 >     r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed70  r31: 0x00003284
 > 
 > Binary Images Description:
 >      0x1000 -     0x9fff speedy     speedy
 > 0x7f430000 - 0x7f508fff libperl.dylib=20
 > /System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
 > 0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
 > 0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
 > 0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
 > /usr/lib/system/libmathCommon.A.dylib
 > 
 > **********
 > 
 > Host Name:      guest.intra.megapublic.net
 > Date/Time:      2004-01-07 01:14:40 +0100
 > OS Version:     10.3.2 (Build 7D24)
 > Report Version: 2
 > 
 > Command: speedy
 > Path:    /usr/bin/speedy
 > Version: ??? (???)
 > PID:     860
 > Thread:  0
 > 
 > Exception:  EXC_BAD_ACCESS (0x0001)
 > Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc
 > 
 > Thread 0 Crashed:
 > 0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
 > 1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
 > 2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
 > 3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
 > 6)
 > 4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
 > (speedy_frontend.c:569)
 > 5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
 > 6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
 > 7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
 > 8   speedy     0x00001b28 start + 0x30
 > 
 > PPC Thread State:
 >    srr0: 0x00003328 srr1: 0x0200f030                vrsave: 0x00000000
 >      cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
 >      r0: 0x00003320   r1: 0xbfffed50   r2: 0x00000000   r3: 0x00000002
 >      r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
 >      r8: 0x00000000   r9: 0xbfffeda7  r10: 0x7f4eb9d0  r11: 0x0000a24c
 >     r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
 >     r16: 0xbffff9a4  r17: 0xbffff9a0  r18: 0x00000000  r19: 0x00000000
 >     r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
 >     r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa88
 >     r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed90  r31: 0x00003284
 > 
 > Binary Images Description:
 >      0x1000 -     0x9fff speedy     speedy
 > 0x7f430000 - 0x7f508fff libperl.dylib=20
 > /System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
 > 0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
 > 0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
 > 0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
 > /usr/lib/system/libmathCommon.A.dylib
 > 
 > --=20
 > Mit freundlichen Gr=FCssen
 > 
 > Philippe Wiede
 > 
 > megapublic=AE Inc.
 > Senior Consultant for Global Corporate Branding and Integrated=20
 > Communications
 > Base station: Gemsberg 11, CH-4051 Basel, Switzerland
 > Phone +41-61-263-33-36, Fax +41-61-263-33-37
 > www.megapublic.com, www.megapublic.ch, www.novience.com
 > 
 > Confidentiality Notice:
 > This E-mail and any attachment may contain confidential and privileged
 > material intended for the addressee only. If you are not the addressee,
 > you are notified that no part of the E-mail or any attachment may be
 > disclosed, copied or distributed, and that any other action related to
 > this E-mail or attachment is strictly prohibited, and may be unlawful.
 > If you have received this E-mail by error, please notify the sender
 > immediately by return E-mail, and delete this message. megapublic, its
 > subsidiaries and/or its employees shall not be liable for the incorrect
 > or incomplete transmission of this E-mail or any attachments, nor
 > responsible for any delay in receipt.
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF.net email is sponsored by: IBM Linux Tutorials.
 > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
 > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
 > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users
 > 

RE: [Speedycgi-users] File descriptors > 2 and SpeedyCGI

[Japheth C. <cl...@ix...>]

At 06:17 AM 1/7/2004, Dallas L. Engelken wrote:
> > I've run into a problem where I'm trying to use SpeedyCGI to
> > replace a
> > script that needs to access some previously-opened file
> > descriptors that
> > are greater than 3 to read and write from. (It's something
> > that's going to
> > get inserted into a qmail server stream, if anyone cares.)
> >
> > It looks like SpeedyCGI though, uses the file descriptors --
> > especially
> > those starting around 15 or so -- for communicating
> > environment or other
> > things to the backend processes (is that right? was trying to
> > examine the
> > code...) and in the process apparently closes any descriptors
> > above #2.
> >
>
>see the thread i created last march regarding reading STDOUT from qmail
>to grab envelope headers...
>http://sourceforge.net/mailarchive/forum.php?thread_id=1825647&forum_id=
>12206
>
>unless things have changed since then, i dont know what to do to make it
>work.  it would be very cool if i could get this going, since starting a
>perl interpreter for each message gets expensive.
>
>d


Hmm.. ya, looks to be cause by the same factor. Sam: any idea when this 
ability might be added? Or suggestions for anyone wanting to tackle it on 
their own?

-jc

RE: [Speedycgi-users] File descriptors > 2 and SpeedyCGI

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

> I've run into a problem where I'm trying to use SpeedyCGI to=20
> replace a=20
> script that needs to access some previously-opened file=20
> descriptors that=20
> are grater than 3 to read and write from. (It's something=20
> that's going to=20
> get inserted into a qmail server stream, if anyone cares.)
>=20
> It looks like SpeedyCGI though, uses the file descriptors --=20
> especially=20
> those starting around 15 or so -- for communicating=20
> environment or other=20
> things to the backend processes (is that right? was trying to=20
> examine the=20
> code...) and in the process apparently closes any descriptors=20
> above #2.
>=20

see the thread i created last march regarding reading STDOUT from qmail
to grab envelope headers...
http://sourceforge.net/mailarchive/forum.php?thread_id=3D1825647&forum_id=
=3D
12206

unless things have changed since then, i dont know what to do to make it
work.  it would be very cool if i could get this going, since starting a
perl interpreter for each message gets expensive.

d

[Speedycgi-users] SpeedyCGI crashes in Mac OS X Panther

[PW <sub...@me...>]

Hello list

I managed to install SpeedyCGI on Mac OS X 10.3.2 (Panther), albeit only=20
by applying Sam's patch, which b.t.w. is not yet incorporated in the=20
latest release source. However, SpeedyCGI crashes whenever it gets=20
called by a script. I run SpeedyCGI via the Apache module. On Linux, the=20
same combo runs smooth. I have attached CrashReporter's output=20
concerning SpeedyCGI.

Thanks!

Best regards

Ph. Wiede


**********

Host Name:      xxx
Date/Time:      2004-01-07 01:01:09 +0100
OS Version:     10.3.2 (Build 7D24)
Report Version: 2

Command: speedy
Path:    /usr/bin/speedy
Version: ??? (???) -> 2.
PID:     846
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc

Thread 0 Crashed:
0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
6)
4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
(speedy_frontend.c:569)
5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
8   speedy     0x00001b28 start + 0x30

PPC Thread State:
   srr0: 0x00003328 srr1: 0x0200d030                vrsave: 0x00000000
     cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
     r0: 0x00003320   r1: 0xbfffed50   r2: 0x00000000   r3: 0x00000002
     r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
     r8: 0x00000000   r9: 0xbfffeda7  r10: 0x7f4eb9d0  r11: 0x0000a24c
    r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
    r16: 0xbffff9a4  r17: 0xbffff9a0  r18: 0x00000000  r19: 0x00000000
    r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
    r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa7c
    r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed90  r31: 0x00003284

Binary Images Description:
     0x1000 -     0x9fff speedy     speedy
0x7f430000 - 0x7f508fff libperl.dylib=20
/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
/usr/lib/system/libmathCommon.A.dylib

**********

Host Name:      guest.intra.megapublic.net
Date/Time:      2004-01-07 01:02:55 +0100
OS Version:     10.3.2 (Build 7D24)
Report Version: 2

Command: speedy
Path:    /usr/bin/speedy
Version: ??? (???)
PID:     851
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc

Thread 0 Crashed:
0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
6)
4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
(speedy_frontend.c:569)
5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
8   speedy     0x00001b28 start + 0x30

PPC Thread State:
   srr0: 0x00003328 srr1: 0x0200f030                vrsave: 0x00000000
     cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
     r0: 0x00003320   r1: 0xbfffed30   r2: 0x00000000   r3: 0x00000002
     r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
     r8: 0x00000000   r9: 0xbfffed87  r10: 0x7f4eb9d0  r11: 0x0000a24c
    r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
    r16: 0xbffff984  r17: 0xbffff980  r18: 0x00000000  r19: 0x00000000
    r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
    r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa60
    r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed70  r31: 0x00003284

Binary Images Description:
     0x1000 -     0x9fff speedy     speedy
0x7f430000 - 0x7f508fff libperl.dylib=20
/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
/usr/lib/system/libmathCommon.A.dylib

**********

Host Name:      guest.intra.megapublic.net
Date/Time:      2004-01-07 01:14:40 +0100
OS Version:     10.3.2 (Build 7D24)
Report Version: 2

Command: speedy
Path:    /usr/bin/speedy
Version: ??? (???)
PID:     860
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x000000cc

Thread 0 Crashed:
0   speedy     0x00003328 just_die + 0xb8 (speedy_util.c:105)
1   speedy     0x000033dc speedy_util_die + 0x30 (speedy_util.c:120)
2   speedy     0x000078a4 speedy_script_open + 0x40 (speedy_script.c:66)
3   speedy     0x00007970 speedy_script_getstat + 0x1c (speedy_script.c:8=
6)
4   speedy     0x00005484 speedy_frontend_mkenv + 0x88=20
(speedy_frontend.c:569)
5   speedy     0x00002448 doit + 0xd4 (speedy_main.c:204)
6   speedy     0x00002c78 main + 0x1c (speedy_main.c:484)
7   speedy     0x00001cb4 _start + 0x188 (crt.c:267)
8   speedy     0x00001b28 start + 0x30

PPC Thread State:
   srr0: 0x00003328 srr1: 0x0200f030                vrsave: 0x00000000
     cr: 0x22000248  xer: 0x00000004   lr: 0x00003320  ctr: 0x7f4eb8c4
     r0: 0x00003320   r1: 0xbfffed50   r2: 0x00000000   r3: 0x00000002
     r4: 0x00000048   r5: 0x00000048   r6: 0xfefefeff   r7: 0x80808080
     r8: 0x00000000   r9: 0xbfffeda7  r10: 0x7f4eb9d0  r11: 0x0000a24c
    r12: 0x7f4eb8c4  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
    r16: 0xbffff9a4  r17: 0xbffff9a0  r18: 0x00000000  r19: 0x00000000
    r20: 0x00000000  r21: 0x00000000  r22: 0x00000000  r23: 0x00000000
    r24: 0x00000000  r25: 0x00000000  r26: 0x00100264  r27: 0xbffffa88
    r28: 0xa000a230  r29: 0x00000000  r30: 0xbfffed90  r31: 0x00003284

Binary Images Description:
     0x1000 -     0x9fff speedy     speedy
0x7f430000 - 0x7f508fff libperl.dylib=20
/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE/libperl.dylib
0x8fe00000 - 0x8fe4ffff dyld     /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
0x939d0000 - 0x939d4fff libmathCommon.A.dylib=20
/usr/lib/system/libmathCommon.A.dylib

--=20
Mit freundlichen Gr=FCssen

Philippe Wiede

megapublic=AE Inc.
Senior Consultant for Global Corporate Branding and Integrated=20
Communications
Base station: Gemsberg 11, CH-4051 Basel, Switzerland
Phone +41-61-263-33-36, Fax +41-61-263-33-37
www.megapublic.com, www.megapublic.ch, www.novience.com

Confidentiality Notice:
This E-mail and any attachment may contain confidential and privileged
material intended for the addressee only. If you are not the addressee,
you are notified that no part of the E-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to
this E-mail or attachment is strictly prohibited, and may be unlawful.
If you have received this E-mail by error, please notify the sender
immediately by return E-mail, and delete this message. megapublic, its
subsidiaries and/or its employees shall not be liable for the incorrect
or incomplete transmission of this E-mail or any attachments, nor
responsible for any delay in receipt.

[Speedycgi-users] File descriptors > 2 and SpeedyCGI

[Japheth C. <cl...@ix...>]

Hello everyone...

I've run into a problem where I'm trying to use SpeedyCGI to replace a 
script that needs to access some previously-opened file descriptors that 
are grater than 3 to read and write from. (It's something that's going to 
get inserted into a qmail server stream, if anyone cares.)

It looks like SpeedyCGI though, uses the file descriptors -- especially 
those starting around 15 or so -- for communicating environment or other 
things to the backend processes (is that right? was trying to examine the 
code...) and in the process apparently closes any descriptors above #2.

Is there an easy way to get around this? Or if I wanted to patch this, 
where might I start poking around?

Why is this needed? Well, qmail uses DJB''s ucspi protocol 
at  http://cr.yp.to/proto/ucspi.txt -- and at various points it 
communicates to other programs over decriptors #6 and #7.


If you have tcpclient installed, a test case is included below. Called 
properly, it connects to localhost port 25 and issues a QUIT command after 
the  SMTP ok message. It works under standard Perl but under SpeedyCGI I 
get a "Bad file descriptor" at line 16.


Any help would be much appreciated =)


Sincerely,

Japheth Cleaver
cl...@ro...



---- BEGIN SAMPLE CODE ----
#!/usr/bin/perl
#!/usr/bin/speedy

# This script attempts to speak SMTP, reading from from file descriptor
# 6 and writing to file descriptor 7; should be called using DJB's
# "tcpclient" program like so:
#
#       [root@testmail root]# tcpclient 127.0.0.1 25 /root/test.pl
#
# Works fine under standard perl, but complains when called
# persistently.
#
# cl...@ro...
#

open (INCOMING, '<&=6') or die "Can't read in! $!";
  select INCOMING; $|=1;
open (OUTGOING, '>&=7') or die "Can't speak out! $!";
  select OUTGOING; $|=1;

select STDOUT;

while (<INCOMING>) {

         print STDERR ">> Received: ", $_;
         if (m/^220/) {
                 print OUTGOING "QUIT\n";
                 print STDERR "(sending QUIT)\n";
         };
};

close OUTGOING;
close INCOMING;

__END__

Re: [Speedycgi-users] Slow SpeedyCGI response / multiple parallel requests

[Thomas A. <ae...@gr...>]

On Thu, 2003-12-04 at 00:54, Sam Horrocks wrote:
> You could try running truss or strace on the backends to see what they're
> doing - you might get a clue there.

During debugging I ran into some strange effect: I decided to write a=20
small wrapper around my script (it's one single CGI with a number of
different functions depending on form arguments passed - ideal job for
SpeedyCGI :-)) logging start time and duration of one invocation.

I was really surprised to see the problem was gone!!!!

Now, if I use a simple wrapper like e.g.

   #!/bin/sh

   /usr/bin/speedycgi /tmp/myscript.pl

The pages (with myscript.pl generated images) are loaded stunningly
fast. If I use /tmp/myscript.pl directly (it starts with
#!/usr/bin/speedycgi) or use a wrapper like

    #!/bin/sh

    exec /usr/bin/speedycgi /tmp/myscript.pl

Then the script answers very fast, but somehow there are pauses of
several seconds between some (not each) of the invocations. If I use
the above wrapper (without "exec") the problem is gone.=20

Now I've got a workaround but no idea what's happening - might this
be some problem in signal handling or with STDIN/STDOUT/STDERR handling?

Best regards,
Tom
---------------------------------------------------------------------------=
-
Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
4180040
Internet: ae...@gr...                           PGP public key
available
---------------------------------------------------------------------------=
-
A day without sunshine is like night.

Re: [Speedycgi-users] Slow SpeedyCGI response / multiple parallel requests

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

Three backends might be OK - it probably depends on your web browser and
how many requests it makes in parallel.  Usually the number of backends
will increase to be the same as, or a little more than the number of
parallel requests going on.

I can't think of anything unusual about img tags that would break anything.

When you're looking at the backends in ps, are they changing process
id's, or are the pid's constant?  If the pid's are changing quite a bit,
then there's definitely somthing wrong there.  The same backend processes
should be handling the requests over and over, if all is working well.

You could try running truss or strace on the backends to see what they're
doing - you might get a clue there.

 > 
 > --=-zc0EcASufcuaVdII3jCV
 > Content-Type: text/plain
 > Content-Transfer-Encoding: quoted-printable
 > 
 > Hello,
 > 
 > I've been using SpeedyCGI for years without any problems. Currently I'm
 > writing a new web based app that should work with Speedy and ran into a
 > problem: the CGI script in question calls itself back via <img> tags in
 > the servered HTML page (the src attribute points back to the same CGI).
 > Now it seems that Speedy responds very slowly (1-2 seconds?) if the
 > number of such <img> tags is getting higher (currently, there are 4 of
 > them - not too many in my eyes). I'm also surprised to see that I never
 > get more than 3 speedy_backends running - could this point to the
 > problem?
 > 
 > Has anyone got an explanation for this? Thanks for any hint!
 > 
 > Best regards,
 > Tom
 > --=20
 > ---------------------------------------------------------------------------=
 > -
 > Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
 > 4180040
 > Internet: ae...@gr...                           PGP public key
 > available
 > ---------------------------------------------------------------------------=
 > -
 > A LISP programmer knows the value of everything, but the cost of
 > nothing.
 > 
 > --=-zc0EcASufcuaVdII3jCV
 > Content-Type: application/pgp-signature; name=signature.asc
 > Content-Description: This is a digitally signed message part
 > 
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v1.0.7 (GNU/Linux)
 > 
 > iD8DBQA/tfZE3d2qB2hF2mgRAuHvAJ0XIXm//fuEZPt+OIOsys4GTCyuKQCggKsw
 > Au3CvjbUI7bNeJL6SYM0Pj8=
 > =9Mev
 > -----END PGP SIGNATURE-----
 > 
 > --=-zc0EcASufcuaVdII3jCV--
 > 
 > 
 > 
 > -------------------------------------------------------
 > This SF. Net email is sponsored by: GoToMyPC
 > GoToMyPC is the fast, easy and secure way to access your computer from
 > any Web browser or wireless device. Click here to Try it Free!
 > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
 > _______________________________________________
 > Speedycgi-users mailing list
 > Spe...@li...
 > https://lists.sourceforge.net/lists/listinfo/speedycgi-users
 > 

[Speedycgi-users] PersistenPerl make failure on MacOSX *after* _my_perl fix ... ??

[OpenMacNews <spe...@sp...>]

hi all,

after making SamH's recommended changes to PersistentPerl code for MacOSX, specifically:

% vi /usr/ports/PersistentPerl-2.22/src/perperl_perl.h

        	void speedy_perl_run(slotnum_t _gslotnum, slotnum_t _bslotnum);
        	int speedy_perl_fork(void);
        ---	PerlInterpreter  *my_perl;
        +++	extern PerlInterpreter  *my_perl;

which *did* fix the _my_perl "multiple definitions" errors during make, the make fails again, now with (below) ...

fyi, my serv env is:  MacOSX 10.3.1, Perl 5.8.2, Apache/2.1.0-dev, mod_ssl/2.1.0-dev, OpenSSL/0.9.7c, DAV/2, PHP/4.3.4
suggestions?

thanks,

richard


entperl2.c && touch mod_persistentperl2.slo
mod_persistentperl2.c: In function `discard_script_output':
mod_persistentperl2.c:343: error: parse error before '{' token
mod_persistentperl2.c: At top level:
mod_persistentperl2.c:347: error: `e' undeclared here (not in a function)
mod_persistentperl2.c:347: error: `e' undeclared here (not in a function)
mod_persistentperl2.c:347: error: `buf' undeclared here (not in a function)
mod_persistentperl2.c:347: error: `len' undeclared here (not in a function)
mod_persistentperl2.c:347: warning: data definition has no type or storage class
mod_persistentperl2.c:348: error: parse error before "if"
mod_persistentperl2.c: In function `cgi_handler':
mod_persistentperl2.c:383: warning: assignment makes pointer from integer without a cast
mod_persistentperl2.c:468: error: parse error before '{' token
mod_persistentperl2.c:488: error: `data' undeclared (first use in this function)
mod_persistentperl2.c:488: error: (Each undeclared identifier is reported only once
mod_persistentperl2.c:488: error: for each function it appears in.)
mod_persistentperl2.c:500: error: parse error before "apr_brigade_cleanup"
mod_persistentperl2.c:474: error: break statement not within loop or switch
mod_persistentperl2.c:479: error: continue statement not within a loop
mod_persistentperl2.c:484: error: continue statement not within a loop
mod_persistentperl2.c: At top level:
mod_persistentperl2.c:505: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:505: warning: data definition has no type or storage class
mod_persistentperl2.c:506: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:506: warning: data definition has no type or storage class
mod_persistentperl2.c:509: error: parse error before "if"
mod_persistentperl2.c:515: error: `script_in' undeclared here (not in a function)
mod_persistentperl2.c:515: error: `c' undeclared here (not in a function)
mod_persistentperl2.c:515: warning: initialization makes integer from pointer without a cast
mod_persistentperl2.c:515: error: initializer element is not constant
mod_persistentperl2.c:515: warning: data definition has no type or storage class
mod_persistentperl2.c:516: error: parse error before "do"
mod_persistentperl2.c:516: error: parse error before '->' token
mod_persistentperl2.c:516: error: parse error before "struct"
mod_persistentperl2.c:516: error: parse error before "struct"
mod_persistentperl2.c:517: error: redefinition of `b'
mod_persistentperl2.c:515: error: `b' previously defined here
mod_persistentperl2.c:517: error: `c' undeclared here (not in a function)
mod_persistentperl2.c:517: warning: initialization makes integer from pointer without a cast
mod_persistentperl2.c:517: error: initializer element is not constant
mod_persistentperl2.c:517: warning: data definition has no type or storage class
mod_persistentperl2.c:518: error: parse error before "do"
mod_persistentperl2.c:518: error: parse error before '->' token
mod_persistentperl2.c:518: error: parse error before "struct"
mod_persistentperl2.c:518: error: parse error before "struct"
mod_persistentperl2.c:524: error: conflicting types for `location'
mod_persistentperl2.c:511: error: previous declaration of `location'
mod_persistentperl2.c:524: error: `r' undeclared here (not in a function)
mod_persistentperl2.c:524: warning: data definition has no type or storage class
mod_persistentperl2.c:526: error: parse error before "if"
mod_persistentperl2.c:528: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:528: warning: data definition has no type or storage class
mod_persistentperl2.c:529: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:529: error: conflicting types for `log_script_err'
mod_persistentperl2.c:161: error: previous declaration of `log_script_err'
mod_persistentperl2.c:529: warning: data definition has no type or storage class
mod_persistentperl2.c:533: error: parse error before '->' token
mod_persistentperl2.c:540: error: parse error before '->' token
mod_persistentperl2.c:540: error: conflicting types for `apr_table_unset'
/usr/include/apache2/apr_tables.h:289: error: previous declaration of `apr_table_unset'
mod_persistentperl2.c:540: warning: data definition has no type or storage class
mod_persistentperl2.c:542: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:542: error: conflicting types for `ap_internal_redirect_handler'
/usr/include/apache2/http_request.h:217: error: previous declaration of `ap_internal_redirect_handler'
mod_persistentperl2.c:542: warning: data definition has no type or storage class
mod_persistentperl2.c:543: error: parse error before "return"
mod_persistentperl2.c:550: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:550: warning: data definition has no type or storage class
mod_persistentperl2.c:551: error: parse error before "return"
mod_persistentperl2.c:554: error: parse error before '->' token
mod_persistentperl2.c:554: warning: data definition has no type or storage class
mod_persistentperl2.c:556: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:556: warning: data definition has no type or storage class
mod_persistentperl2.c:557: warning: parameter names (without types) in function declaration
mod_persistentperl2.c:557: warning: data definition has no type or storage class
mod_persistentperl2.c:558: error: parse error before '}' token
mod_persistentperl2.c:569: error: conflicting types for `cur'
mod_persistentperl2.c:562: error: previous declaration of `cur'
mod_persistentperl2.c:569: error: `r' undeclared here (not in a function)
mod_persistentperl2.c:569: warning: data definition has no type or storage class
mod_persistentperl2.c:570: error: parse error before "while"
mod_persistentperl2.c:575: error: `r' undeclared here (not in a function)
mod_persistentperl2.c:575: error: `c' undeclared here (not in a function)
mod_persistentperl2.c:575: warning: initialization makes integer from pointer without a cast
mod_persistentperl2.c:575: error: initializer element is not constant
mod_persistentperl2.c:575: warning: data definition has no type or storage class
mod_persistentperl2.c:576: error: redefinition of `b'
mod_persistentperl2.c:517: error: `b' previously defined here
mod_persistentperl2.c:576: error: `script_in' undeclared here (not in a function)
mod_persistentperl2.c:576: error: `c' undeclared here (not in a function)
mod_persistentperl2.c:576: warning: initialization makes integer from pointer without a cast
mod_persistentperl2.c:576: error: initializer element is not constant
mod_persistentperl2.c:576: warning: data definition has no type or storage class
mod_persistentperl2.c:577: error: parse error before "do"
mod_persistentperl2.c:577: error: parse error before '->' token
mod_persistentperl2.c:577: error: parse error before "struct"
mod_persistentperl2.c:577: error: parse error before "struct"
mod_persistentperl2.c:578: error: redefinition of `b'
mod_persistentperl2.c:576: error: `b' previously defined here
mod_persistentperl2.c:578: error: `c' undeclared here (not in a function)
mod_persistentperl2.c:578: warning: initialization makes integer from pointer without a cast
mod_persistentperl2.c:578: error: initializer element is not constant
mod_persistentperl2.c:578: warning: data definition has no type or storage class
mod_persistentperl2.c:579: error: parse error before "do"
mod_persistentperl2.c:579: error: parse error before '->' token
mod_persistentperl2.c:579: error: parse error before "struct"
mod_persistentperl2.c:579: error: parse error before "struct"
mod_persistentperl2.c:580: error: parse error before '->' token
mod_persistentperl2.c:580: warning: data definition has no type or storage class
apxs:Error: Command failed with rc=65536
.
make[1]: *** [mod_persistentperl.la] Error 1
make: *** [subdirs] Error 2

[Speedycgi-users] setenv PERL5LIB

[Jean-Marc P. <jm...@su...>]

Hi,

I'm switching my speedy scripts under mod_speedycgi, and I get
(3)No such process: couldn't spawn child process: ...

It seems I can't use setenv PERL5LIB.
The only scripts that don't run with mod_speedy use a setenv PERL5LIB 
in the Apache config.
I add SpeedyPerlArgs "-w -I/usr/local/.../lib", but no change.

Scripts run without error with Perl and Speedy (using setenv PERL5LIB).

Any idea?

--
Jean-Marc Pennel <jm...@su...>
http://www.suricate.net/

Re: [Speedycgi-users] Apache log/STDERR problems

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

The frontend is turning off O_APPEND on both stdout and stderr.  I should
have a more thorough fix on the cvs server soon, but a quick fix is the
following patch:


Index: src/speedy_main.c
===================================================================
RCS file: /cvsroot/speedycgi/2.x/src/speedy_main.c,v
retrieving revision 1.23
diff -c -r1.23 speedy_main.c
*** src/speedy_main.c	7 Oct 2003 04:03:48 -0000	1.23
--- src/speedy_main.c	16 Nov 2003 07:23:15 -0000
***************
*** 73,79 ****
  #endif
  	speedy_renew(fdinfo, fdinfo_size, fdinfo_t);
      }
!     fdinfo[fd].flags = flags;
      fdinfo[fd].state = FD_UNKNOWN;
      fd_change(fd, state);
  }
--- 73,79 ----
  #endif
  	speedy_renew(fdinfo, fdinfo_size, fdinfo_t);
      }
!     fdinfo[fd].flags = fcntl(fd, F_GETFL);
      fdinfo[fd].state = FD_UNKNOWN;
      fd_change(fd, state);
  }



 > This is a multi-part message in MIME format.
 > --------------000606070009020103080100
 > Content-Type: text/plain; charset=us-ascii
 > Content-Transfer-Encoding: 7bit
 > 
 > I have tested using normal perl, and that works as expected.  I've
 > attached a transcript of the steps you've requested.
 > 
 > Thanks,
 > Grant
 > 
 > Sam Horrocks wrote:
 > >  
 > >  Have you tried switching back to normal perl and doing the same test?
 > > 
 > >  Can you send me a typescript that shows the problem?   Cat the error
 > >  log before starting apache, cat your test script and httpd.conf, start
 > >  apache, do a few requests with "ab" to your test script, then cat the
 > >  error log again.  I'll try to reproduce it.
 > 
 > --------------000606070009020103080100
 > Content-Type: text/plain;
 >  name="typescript"
 > Content-Transfer-Encoding: 7bit
 > Content-Disposition: inline;
 >  filename="typescript"
 > 
 > [grant@localhost apache]$ cat conf/httpd.conf 
 > 
 > ServerType standalone
 > 
 > LogLevel debug
 > 
 > ServerRoot "/home/grant/apache"
 > 
 > PidFile /home/grant/apache/var/apache.pid
 > 
 > SetEnv PATH /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 > 
 > CoreDumpDirectory /tmp
 > 
 > ClearModuleList
 > 
 > AddModule mod_env.c
 > AddModule mod_log_config.c
 > AddModule mod_cgi.c
 > AddModule mod_alias.c
 > AddModule mod_access.c
 > AddModule mod_so.c
 > 
 > HostnameLookups off
 > 
 > Port 8080
 > 
 > ServerName localhost
 > 
 > LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
 > LogFormat "%h %l %u %t \"%r\" %>s %b" common
 > LogFormat "%{Referer}i -> %U" referer
 > LogFormat "%{User-agent}i" agent
 > 
 > CustomLog /home/grant/apache/log/access_log combined
 > ErrorLog /home/grant/apache/log/error_log
 > 
 > Listen 127.0.0.1:8080
 > 
 > <Directory />
 > 	Options None
 > 	AllowOverride None
 > 	Order allow,deny
 > 	Deny from all
 > </Directory>
 > 
 > DocumentRoot /home/grant/apache/htdocs
 > ScriptAlias /cgi-bin/ /home/grant/apache/cgi-bin/
 > 
 > <Directory "/home/grant/apache/htdocs">
 > 	Order allow,deny
 > 	Allow from all
 > </Directory>
 > 
 > <Directory "/home/grant/apache/cgi-bin">
 > 	Options ExecCGI
 > 	Order allow,deny
 > 	Allow from all
 > </Directory>
 > 
 > Listen 127.0.0.1:8090
 > <VirtualHost 127.0.0.1:8090>
 >         DocumentRoot /home/grant/apache/htdocs
 >         ErrorLog /home/grant/apache/log/vhost.error_log
 > </VirtualHost>
 >  
 > [grant@localhost apache]$ cat cgi-bin/speedy.cgi 
 > #!/usr/local/bin/speedy
 > 
 > warn(localtime() . ": This should go to the error log");
 > print STDERR localtime() . ": This also should go to the error log\n";
 > 
 > print <<EOF
 > Content-Type: text/plain
 > 
 > Testing
 > 
 > EOF
 > [grant@localhost apache]$ cat log/vhost.error_log 
 > [Mon Nov 10 22:00:22 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/1
 > [Mon Nov 10 22:00:23 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/2
 > [Mon Nov 10 22:00:26 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/3
 > [Mon Nov 10 22:00:28 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/4
 > [Mon Nov 10 22:00:31 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/5
 > [Mon Nov 10 22:00:33 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/6
 > [Mon Nov 10 22:00:35 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/7
 > [Mon Nov 10 22:00:37 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/8
 > [Mon Nov 10 22:00:39 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/9
 > [Mon Nov 10 22:00:41 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/10
 > [grant@localhost apache]$ /usr/local/apache/sbin/httpd -f /home/grant/apache/conf/httpd.conf 
 > [grant@localhost apache]$ lynx --dump http://127.0.0.1:8090/cgi-bin/speedy.cgi
 > Testing
 > 
 > 
 > [grant@localhost apache]$ cat log/vhost.error_log 
 > Mon Nov 10 22:03:47 2003: This should go to the error log at /home/grant/apache/cgi-bin/speedy.cgi line 3.
 > Mon Nov 10 22:03:47 2003: This also should go to the error log
 >  exist: /home/grant/apache/htdocs/2
 > [Mon Nov 10 22:00:26 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/3
 > [Mon Nov 10 22:00:28 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/4
 > [Mon Nov 10 22:00:31 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/5
 > [Mon Nov 10 22:00:33 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/6
 > [Mon Nov 10 22:00:35 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/7
 > [Mon Nov 10 22:00:37 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/8
 > [Mon Nov 10 22:00:39 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/9
 > [Mon Nov 10 22:00:41 2003] [error] [client 127.0.0.1] File does not exist: /home/grant/apache/htdocs/10
 > [grant@localhost apache]$
 > 
 > --------------000606070009020103080100--
 > 

[Speedycgi-users] Slow SpeedyCGI response / multiple parallel requests

[Thomas A. <ae...@gr...>]

Hello,

I've been using SpeedyCGI for years without any problems. Currently I'm
writing a new web based app that should work with Speedy and ran into a
problem: the CGI script in question calls itself back via <img> tags in
the servered HTML page (the src attribute points back to the same CGI).
Now it seems that Speedy responds very slowly (1-2 seconds?) if the
number of such <img> tags is getting higher (currently, there are 4 of
them - not too many in my eyes). I'm also surprised to see that I never
get more than 3 speedy_backends running - could this point to the
problem?

Has anyone got an explanation for this? Thanks for any hint!

Best regards,
Tom
--=20
---------------------------------------------------------------------------=
-
Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
4180040
Internet: ae...@gr...                           PGP public key
available
---------------------------------------------------------------------------=
-
A LISP programmer knows the value of everything, but the cost of
nothing.

Re: [Speedycgi-users] Apache log/STDERR problems

[Grant D. <gr...@wo...>]

Oh, one potentially important thing I did fail to mention:  the
overwriting problem only happens with my virtual host error logs.



Grant DeGraw wrote:
> I have tested using normal perl, and that works as expected.  I've
> attached a transcript of the steps you've requested.
> 
> Thanks,
> Grant
> 
> Sam Horrocks wrote:
> 
>> 
>> Have you tried switching back to normal perl and doing the same test?
>>
>> Can you send me a typescript that shows the problem?   Cat the error
>> log before starting apache, cat your test script and httpd.conf, start
>> apache, do a few requests with "ab" to your test script, then cat the
>> error log again.  I'll try to reproduce it.
>>
>>

Re: [Speedycgi-users] Apache log/STDERR problems

[Grant D. <gr...@wo...>]

I have tested using normal perl, and that works as expected.  I've
attached a transcript of the steps you've requested.

Thanks,
Grant

Sam Horrocks wrote:
>  
>  Have you tried switching back to normal perl and doing the same test?
> 
>  Can you send me a typescript that shows the problem?   Cat the error
>  log before starting apache, cat your test script and httpd.conf, start
>  apache, do a few requests with "ab" to your test script, then cat the
>  error log again.  I'll try to reproduce it.

Re: [Speedycgi-users] Probem of terminating a forked process

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

On Fri, 7 Nov 2003 00:53:51 +0800, Chung-Kie Tung wrote
> -example 2--------------------------------
> #!/usr/local/bin/speedy
> $|=1;
> $SIG{CHLD}=sub { wait };        # prevent zombie
> print "parent $$\n";
> if (fork()==0) {
>    print "child $$\n\n";
>    exit 0;
> }
> -------------------------------------------
I have found one solution.
Just use $SIG{CHLD}='IGNORE';
instead of $SIG{CHLD}=sub { wait };
Then parent won't terminate and forked process won't be zombies.

But I am still wondering why sub { wait} would terminate the parent 
speedycgi process. :(

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] Probem of terminating a forked process

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

Hi Sam,

I have found a problem in teminating a forked process while speedycgi is 
used.

Here is the example
-example 1-------------------------------
#!/usr/local/bin/speedy
$|=1;
print "parent $$\n";
if (fork()==0) {
   print "child $$\n\n";
   exit 0;
}
-----------------------------------------
If this script is executed for several times,
we can see all the forked child become zombie,

 `-+- 49150 tung /usr/bin/speedy_backend ./t.pl
   `-+- 49151 tung /usr/bin/speedy_backend ./t.pl
     |--- 49152 tung (speedy_backend)
     |--- 49155 tung (speedy_backend)
     `--- 49157 tung (speedy_backend)

This behavior is the same as normal daemon process,
then I try to add a handler to catch signal CHLD:
-example 2--------------------------------
#!/usr/local/bin/speedy
$|=1;
$SIG{CHLD}=sub { wait };        # prevent zombie
print "parent $$\n";
if (fork()==0) {
   print "child $$\n\n";
   exit 0;
}
-------------------------------------------
Then all processes related to this script disappear.

This makes think if I should only change a local copy of $SIG{CHLD}
-example 3--------------------------------
#!/usr/local/bin/speedy
$|=1;
local $SIG{CHLD}=sub { wait };        # prevent zombie
print "parent $$\n";
if (fork()==0) {
   print "child $$\n\n";
   exit 0;
}
-------------------------------------------
And the result is the same as example 1,
all child processes become zombies.

Only example 2 won't make zombies but the process won't be persistent.
So my question is how to terminate a forked processed in a speedycgi-enabled 
program?

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: [Speedycgi-users] Apache log/STDERR problems

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

 > The first problem (and the one the most concerns me) shows up using
 > speedy with CGI under Apache.  If the first request to Apache after it
 > starts up is to a speedy CGI script that prints a message to STDERR, the
 > STDERR output shows up at the _top_ of the Apache error log, overwriting
 > whatever was there.  After that any STDERR output will overwrite
 > existing lines in the error log from the top down.  Note that this only
 > happens if the speedy script is the very first request.
 
 Have you tried switching back to normal perl and doing the same test?

 Can you send me a typescript that shows the problem?   Cat the error
 log before starting apache, cat your test script and httpd.conf, start
 apache, do a few requests with "ab" to your test script, then cat the
 error log again.  I'll try to reproduce it.

Re: [Speedycgi-users] Apache log/STDERR problems

[Grant D. <gr...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fair enough...the only reason I included this in my messages was that I
thought it might be related to the other problems I was seeing.  Is it?

- -Grant


Sam Horrocks wrote:
>  > The second shows up when running a simple script like this in a shell:
>  > --------------------------------
>  > #!/usr/bin/speedy
>  > print STDERR "STDERR print\n";
>  > print "normal print\n";
>  > --------------------------------
>  > I would expect the STDERR line to always appear first in the
output, but
>  > it does not.
>
>  I don't think there's a way to preserve the order as long as speedycgi
>  is using sockets for output from the backend.
>
>  The backend puts both strings into separate unix sockets, which the
>  kernel buffers.  When the frontend goes to get the data, it sees two
>  sockets with data available and no way to tell which one was
>  written first.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/qAt3R1hIw/wbsQkRAnGDAJ9EedsBc6ASW1DT1HqdwL10DaD3MwCgguhR
1BylfQzZDdcDQBycJ8raBAs=
=b1XU
-----END PGP SIGNATURE-----