speedycgi-users Mailing List for SpeedyCGI (Page 5)
Brought to you by:
samh
Menu
▾
▴
speedycgi-users — Speedycgi user discussion
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(4) |
Mar
(12) |
Apr
(3) |
May
(1) |
Jun
(10) |
Jul
(12) |
Aug
(2) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(12) |
Apr
(1) |
May
(18) |
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
(9) |
Oct
(21) |
Nov
(11) |
Dec
(2) |
| 2004 |
Jan
(6) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
(10) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark T. <M.T...@sh...> - 2003-09-15 11:37:32
|
dear speedy users, here is another opinion on this one... my processes run for weeks at a time, and the resident memory size of the processes remains a steady 7632K I am running a 2500 line perl cgi script. it uses sockets to send IP packets to another machine (independantly of the incoming HTTP CGI connections). I am using a custom OO module, and I am also using... CGI, CGI::peristent, CGI::Carp, Net::LDAP, Net::LDAP::Util. it does not write to any files but it does read html from eight text files. OS is Sun Solaris 7 Speedy version unknown - it does not respond to the -v option, so its probably v2.11 is it possible that the leaks are in your code? you can get into some weird situations when your program runs under speedy, where you end up doing things many times when you only wanted to do them once. my program ran for about a year before a realised it was reading in the eight text files on every HTTP connection, when I should really only read them once the first time thru. alternatively, it might be worth you trying speedy v2.11 regards, mark. At 12:05 15/09/2003 +0200, PW wrote: >I have noticed the same behavior in a moderate traffic Perl application >(clean code, using custom OO modules, 1 hit/1-5 minutes, using the group >function across several virtual domains, process expiration set to 1 hour) >on SuSE Linux, too. Processes grow from an initial 7 MB to 60 MB+ over 1-3 >days. Additionally and as already mentioned on this list, there is as a >problem with too many socket connections established, yielding eventually >a "Too many files opened" error by Apache. > >Ph. Wiede > > > >James H. Thompson wrote: >>I'm using SpeedyCGI in a high volume application on Redhat 8, and noticed >>that the memory usage of speedy_backend continually grew over time, even >>if the -r option was set to low number like 3. >>The memory consumption seemed to be tied to speedy_backend creating a new >>child. >>I created an experimental patch to fix this. >>The patch is here: >> www.voip-info.org/speedycgi >> >>Jim >>James H. Thompson >>jh...@la... > > > > >------------------------------------------------------- >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 -- Mark Taylor, Department of Corporate Information & Computing Services, Extension 21145. (0114) 222 1145 http://www.shef.ac.uk/~ad1mt The opinions expressed in this email are mine and not those of the University of Sheffield. |
|
From: PW <sub...@me...> - 2003-09-15 10:03:17
|
I have noticed the same behavior in a moderate traffic Perl application (clean code, using custom OO modules, 1 hit/1-5 minutes, using the group function across several virtual domains, process expiration set to 1 hour) on SuSE Linux, too. Processes grow from an initial 7 MB to 60 MB+ over 1-3 days. Additionally and as already mentioned on this list, there is as a problem with too many socket connections established, yielding eventually a "Too many files opened" error by Apache. Ph. Wiede James H. Thompson wrote: > I'm using SpeedyCGI in a high volume application on Redhat 8, and noticed that the memory usage of speedy_backend continually grew over time, even if the -r option was set to low number like 3. > > The memory consumption seemed to be tied to speedy_backend creating a new child. > > I created an experimental patch to fix this. > > The patch is here: > www.voip-info.org/speedycgi > > > Jim > > James H. Thompson > jh...@la... > |
|
From: James H. T. <jh...@la...> - 2003-09-15 09:37:45
|
I'm using SpeedyCGI in a high volume application on Redhat 8, and =
noticed that the memory usage of speedy_backend continually grew over =
time, even if the -r option was set to low number like 3.
The memory consumption seemed to be tied to speedy_backend creating a =
new child.
I created an experimental patch to fix this.
The patch is here:
www.voip-info.org/speedycgi
Jim
James H. Thompson
jh...@la...
|
|
From: PW <sub...@me...> - 2003-09-11 12:11:18
|
Since I installed the latest SpeedyCGI package 2.21 a couple of months ago, running as combo with Apache/1.3.23 (Linux, approx. 70 virtual hosts - thereof 14 running Perl applications under SpeedyCGI), I experience never encountered problems before. Problem description: After around 3 days (probably depending on traffic) our Apache Server runs out of the hardcoded per user file descriptors (1024), bringing all Web services to a halt. Mentioned Perl applications are clean and close all of their file descriptors. However, when checking the Server logs and querying lsof/netstat -a, I always notice an aweful lot of open Socket connections, typically around 500+ by speedy_ba per process: ## 509 UDP port connections altogether for one process! speedy_ba 14332 wwwrun 237u IPv4 308290 UDP ns.megapublic.net:28952->ns.megapublic.net:domain speedy_ba 14332 wwwrun 238u IPv4 308414 UDP gateway.megapublic.net:28966->ns3.magnet.ch:domain speedy_ba 14332 wwwrun 239u IPv4 308415 UDP ns.megapublic.net:28967->ns.megapublic.net:domain speedy_ba 14332 wwwrun 240u IPv4 308431 UDP gateway.megapublic.net:28970->ns3.magnet.ch:domain speedy_ba 14332 wwwrun 658u IPv4 495600 UDP ns.megapublic.net:7764->ns.megapublic.net:domain Once the "Too many open files" error appears, I have to kill all SpeedyCGI processes and restart Apache in order to get into business again. Questions: 1. Why does SpeedyCGI listen on such a lot of ports? 2. Is there a possible bug in that SpeedyCGI forgets to close once opened sockets after exiting? Thanks for any insight! P. Wiede |
|
From: Dmitri T. <dm...@ne...> - 2003-09-09 01:20:40
|
Issue 1 (patch at the end of the message):
I've found a logical error in file_lock() (from speedy_file.c). Note how
the test inside the for loop decrements the variable after the check is
performed. Right after the loop, there's if (!tries). If file could not
be locked, 'tries' is -1 at that point, not zero. The easiest fix is of
course to change when decrement takes place.
Issue 2:
I found this bug because I found a box after power failure that segfaulted
apache each time a CGI handled by SpeedyCGI was requested. Turns out, a
stale state file (/tmp/speedy.6.f.F), had file_removed byte = 1.
Apparently, the power went right after the flag was set but before unlink
could do its evil thing.
Now comes the question: is there a way to modify SpeedyCGI's algorithm so
that it could recover from these conditions itself, without having to
manually delete the offending file? Right now, if this flag is set
(manually or after a power failure, as it was in my case), SpeedyCGI is
taken out of commission. Maybe, besides being a boolean flag,
file_removed could specify a PID of the process that removed it (but that
raises several more questions)?
My setup:
Linux 2.4.21
Apache 2.0.46
SpeedyCGI 2.21
Thanks,
- Dmitri.
*** speedy_file.c.orig Mon Sep 8 18:54:37 2003
--- speedy_file.c.fixed Mon Sep 8 18:54:33 2003
***************
*** 183,189 ****
file_close2();
}
! for (tries = 5; tries--;) {
/* If file is not open, open it */
if (file_fd == -1) {
str_replace(&saved_tmpbase,
speedy_util_strdup(OPTVAL_TMPBASE));
--- 183,189 ----
file_close2();
}
! for (tries = 5; tries; --tries) {
/* If file is not open, open it */
if (file_fd == -1) {
str_replace(&saved_tmpbase,
speedy_util_strdup(OPTVAL_TMPBASE));
|
|
From: <ck...@ep...> - 2003-09-07 01:23:35
|
Hi: I found speedyCGI very interesting but i did not found a ppm for win32 even in activestate. somebody knows if exists? Thank you for your response Carlos Kassab |
|
From: Filipe B. L. <fil...@tn...> - 2003-08-07 19:16:43
|
Hi sam,
I discovered by querying the apxs parameters that it was nonfunctinal
anyway. apxs -q CC and apxs -q SYSCONFIGDIR returned incorrect values.
Later, I discovered that mod_so wasn=B4t isntalled anyway. I had to =
recompile
apache from ground up with all installed modules and including mod_so =
to
build a usable apxs.
The problem is: that error message shuld explain things a bit better.
Thanks anyway,
Filipe Litaiff
-----Mensagem original-----
De: Sam Horrocks [mailto:sa...@da...]
Enviada em: quarta-feira, 6 de agosto de 2003 15:01
Para: Filipe Barbosa Litaiff
Cc: spe...@li...; hpe...@on...
Assunto: Re: [Speedycgi-users] Nonsense error message=20
Try running:
apxs -q CC
That should return "cc" or "gcc" or something like that. If it returns
an error or no output, then that's the problem.
>=20
> Hi gentlemen,
>=20
> I=B4m really puzzled about a problem regarding speedycgi=B4s =
compilation.
>=20
> My environment: Solaris 8, Perl 5.6.1 and apache 1.3.27.
>=20
> The problem:
>=20
>
------------------------------------------------------------------------=
----
>=20
> Server:/opt/src/CGI-SpeedyCGI-2.21# perl -v
>=20
> This is perl, v5.6.1 built for sun4-solaris
>=20
> Copyright 1987-2001, Larry Wall
>=20
> (...).
>=20
> Server:/opt/src/CGI-SpeedyCGI-2.21# type apxs
> apxs is /usr/local/apache/bin/apxs
> Server:/opt/src/CGI-SpeedyCGI-2.21# apxs -?
> apxs:Error: Unknown option: ?
> Usage: apxs -g [-S <var>=3D<val>] -n <modname>
> apxs -q [-S <var>=3D<val>] <query> ...
> (...)
>=20
> Server:/opt/src/CGI-SpeedyCGI-2.21# perl Makefile.PL
>=20
> Optional mod_speedycgi support.
>=20
> Mod_speedycgi increases performance under Apache by avoiding the
fork/exec
> overhead associated with each request under normal SpeedyCGI. =
However,
it
> requires a working copy of "apxs" in your path, Apache with mod_so
> support, and additional Apache configuration.
>=20
> Compile mod_speedycgi (default no)? yes
> ERROR: Could not find a working copy of 'apxs' in your path.
>=20
>
------------------------------------------------------------------------=
----
> --------
>=20
> As you can see, the Makefile.PL comes out with this message, which =
is
> simply not true. The apxs IS in my path, and it is working.
>=20
> I couldn=B4t figure out what happened looking into the Makefile.PL, =
since
I=B4m
> not a perl expert, unfortunately...
>=20
> Thanks in advance for any help,
>=20
> Filipe Litaiff
>=20
>=20
>=20
>=20
> Esta mensagem, incluindo seus anexos, pode conter informa=E7=F5es
privilegiadas
> e/ou de car=E1ter confidencial, n=E3o podendo ser retransmitida sem
autoriza=E7=E3o
> do remetente. Se voc=EA n=E3o =E9 o destinat=E1rio ou pessoa =
autorizada a
receb=EA-la,
> informamos que o seu uso, divulga=E7=E3o, c=F3pia ou arquivamento =
s=E3o
proibidos.
> Portanto, se voc=EA recebeu esta mensagem por engano, por favor, nos
informe
> respondendo imediatamente a este e-mail e em seguida apague-a.
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites =
including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01=
/01
> _______________________________________________
> Speedycgi-users mailing list
> Spe...@li...
> https://lists.sourceforge.net/lists/listinfo/speedycgi-users
>=20
Esta mensagem, incluindo seus anexos, pode conter informa=E7=F5es =
privilegiadas
e/ou de car=E1ter confidencial, n=E3o podendo ser retransmitida sem =
autoriza=E7=E3o
do remetente. Se voc=EA n=E3o =E9 o destinat=E1rio ou pessoa autorizada =
a receb=EA-la,
informamos que o seu uso, divulga=E7=E3o, c=F3pia ou arquivamento s=E3o =
proibidos.
Portanto, se voc=EA recebeu esta mensagem por engano, por favor, nos =
informe
respondendo imediatamente a este e-mail e em seguida apague-a.
|
|
From: Sam H. <sa...@da...> - 2003-08-06 18:01:15
|
Try running:
apxs -q CC
That should return "cc" or "gcc" or something like that. If it returns
an error or no output, then that's the problem.
>
> Hi gentlemen,
>
> I´m really puzzled about a problem regarding speedycgi´s compilation.
>
> My environment: Solaris 8, Perl 5.6.1 and apache 1.3.27.
>
> The problem:
>
> ----------------------------------------------------------------------------
>
> Server:/opt/src/CGI-SpeedyCGI-2.21# perl -v
>
> This is perl, v5.6.1 built for sun4-solaris
>
> Copyright 1987-2001, Larry Wall
>
> (...).
>
> Server:/opt/src/CGI-SpeedyCGI-2.21# type apxs
> apxs is /usr/local/apache/bin/apxs
> Server:/opt/src/CGI-SpeedyCGI-2.21# apxs -?
> apxs:Error: Unknown option: ?
> Usage: apxs -g [-S <var>=<val>] -n <modname>
> apxs -q [-S <var>=<val>] <query> ...
> (...)
>
> Server:/opt/src/CGI-SpeedyCGI-2.21# perl Makefile.PL
>
> Optional mod_speedycgi support.
>
> Mod_speedycgi increases performance under Apache by avoiding the fork/exec
> overhead associated with each request under normal SpeedyCGI. However, it
> requires a working copy of "apxs" in your path, Apache with mod_so
> support, and additional Apache configuration.
>
> Compile mod_speedycgi (default no)? yes
> ERROR: Could not find a working copy of 'apxs' in your path.
>
> ----------------------------------------------------------------------------
> --------
>
> As you can see, the Makefile.PL comes out with this message, which is
> simply not true. The apxs IS in my path, and it is working.
>
> I couldn´t figure out what happened looking into the Makefile.PL, since I´m
> not a perl expert, unfortunately...
>
> Thanks in advance for any help,
>
> Filipe Litaiff
>
>
>
>
> Esta mensagem, incluindo seus anexos, pode conter informações privilegiadas
> e/ou de caráter confidencial, não podendo ser retransmitida sem autorização
> do remetente. Se você não é o destinatário ou pessoa autorizada a recebê-la,
> informamos que o seu uso, divulgação, cópia ou arquivamento são proibidos.
> Portanto, se você recebeu esta mensagem por engano, por favor, nos informe
> respondendo imediatamente a este e-mail e em seguida apague-a.
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Speedycgi-users mailing list
> Spe...@li...
> https://lists.sourceforge.net/lists/listinfo/speedycgi-users
>
|
|
From: Filipe B. L. <fil...@tn...> - 2003-08-05 15:42:17
|
Hi gentlemen,
I=B4m really puzzled about a problem regarding speedycgi=B4s =
compilation.
My environment: Solaris 8, Perl 5.6.1 and apache 1.3.27.
The problem:
------------------------------------------------------------------------=
----
Server:/opt/src/CGI-SpeedyCGI-2.21# perl -v
This is perl, v5.6.1 built for sun4-solaris
Copyright 1987-2001, Larry Wall
(...).
Server:/opt/src/CGI-SpeedyCGI-2.21# type apxs
apxs is /usr/local/apache/bin/apxs
Server:/opt/src/CGI-SpeedyCGI-2.21# apxs -?
apxs:Error: Unknown option: ?
Usage: apxs -g [-S <var>=3D<val>] -n <modname>
apxs -q [-S <var>=3D<val>] <query> ...
(...)
Server:/opt/src/CGI-SpeedyCGI-2.21# perl Makefile.PL
Optional mod_speedycgi support.
Mod_speedycgi increases performance under Apache by avoiding the =
fork/exec
overhead associated with each request under normal SpeedyCGI. However, =
it
requires a working copy of "apxs" in your path, Apache with mod_so
support, and additional Apache configuration.
Compile mod_speedycgi (default no)? yes
ERROR: Could not find a working copy of 'apxs' in your path.
------------------------------------------------------------------------=
----
--------
As you can see, the Makefile.PL comes out with this message, which is
simply not true. The apxs IS in my path, and it is working.
I couldn=B4t figure out what happened looking into the Makefile.PL, =
since I=B4m
not a perl expert, unfortunately...
Thanks in advance for any help,
Filipe Litaiff
Esta mensagem, incluindo seus anexos, pode conter informa=E7=F5es =
privilegiadas
e/ou de car=E1ter confidencial, n=E3o podendo ser retransmitida sem =
autoriza=E7=E3o
do remetente. Se voc=EA n=E3o =E9 o destinat=E1rio ou pessoa autorizada =
a receb=EA-la,
informamos que o seu uso, divulga=E7=E3o, c=F3pia ou arquivamento s=E3o =
proibidos.
Portanto, se voc=EA recebeu esta mensagem por engano, por favor, nos =
informe
respondendo imediatamente a este e-mail e em seguida apague-a.
|
|
From: Sam H. <sa...@da...> - 2003-07-27 02:56:53
|
You should see perl errors logged in the Apache error log. > Dear SpeedyCGI users and developers, > > Oops!! Sorry about that! I made one change too many in my configuration > objects and tried to call methods on an undefined object. The > speedy_backend had a right to choke!! > > Is there some place where errors like this are logged? Of course this > was code called only from the SpeedyCGI version of Penguin Greetings - > otherwise it would have crashed and burned far more "vocally" :-) > > Peace, Edouard :-) > > > ================================== > Edouard Lagache > Lead Developer, Penguin Greetings > http://pgreet.sourceforge.net/ > pgr...@ca... > > ============================================ > Edouard Lagache <lag...@ca...> wrote at Thu, 3 Jul 2003 13:44:31 -0700 > > >Dear SpeedyCGI users and developers, > > > >First, thank you to Sam Horrocks and everyone else who has gotten > >SpeedyCGI up and running. It is a great tool!! > > > >However, ... :-) having gotten my ecard application (Penguin Greetings) > >working SpeedyCGI for about 2 months now, I've run into a strange > >problem. I'm in the process of moving code into some Perl module > >libraries, and strangely, SpeedyCGI is acting like a sputtering car. The > >first attempt to invoke SpeedyCGI will fail with a "Premature ending of > >script headers" error for the browser and absolutely nothing in the http/ > >error_log besides that. Yet, if you involve the script a second time, it > >appears to run fine except that some of the initialization that should > >have been done on the first invocation was never done. > > > >I have fallen to the "last resort" strategy of using CGI::Carp and > >putting warnings everywhere. The top of my program is essentially this: > > > > #!/usr/bin/speedy -- -M20 -gpgreet > > use CGI::SpeedyCGI; > > use CGI qw(:standard escape); > > use CGI::Carp; > > warn "Just after CGI::Carp"; > > > >The warn statement is never printed on the first invocation, but is in > >subsequent runs. > > > >Has anyone run into a problem like this? Any thoughts on how to debug > >this sort of "crankyness?" > > > >Thanks in advance! > > > >Peace, Edouard :-) > > > >P.S. Yes, the program runs fine in straight CGI. > >================================== > >Edouard Lagache > >Lead Developer, Penguin Greetings > >http://pgreet.sourceforge.net/ > >pgr...@ca... > > > > > > > > > >------------------------------------------------------- > >This SF.Net email sponsored by: Free pre-built ASP.NET sites including > >Data Reports, E-commerce, Portals, and Forums are available now. > >Download today and enter to win an XBOX or Visual Studio .NET. > >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > >_______________________________________________ > >Speedycgi-users mailing list > >Spe...@li... > >https://lists.sourceforge.net/lists/listinfo/speedycgi-users > > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Speedycgi-users mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speedycgi-users > |
|
From: Edouard L. <lag...@ca...> - 2003-07-05 03:03:16
|
Dear SpeedyCGI users and developers, Oops!! Sorry about that! I made one change too many in my configuration objects and tried to call methods on an undefined object. The speedy_backend had a right to choke!! Is there some place where errors like this are logged? Of course this was code called only from the SpeedyCGI version of Penguin Greetings - otherwise it would have crashed and burned far more "vocally" :-) Peace, Edouard :-) ================================== Edouard Lagache Lead Developer, Penguin Greetings http://pgreet.sourceforge.net/ pgr...@ca... ============================================ Edouard Lagache <lag...@ca...> wrote at Thu, 3 Jul 2003 13:44:31 -0700 >Dear SpeedyCGI users and developers, > >First, thank you to Sam Horrocks and everyone else who has gotten >SpeedyCGI up and running. It is a great tool!! > >However, ... :-) having gotten my ecard application (Penguin Greetings) >working SpeedyCGI for about 2 months now, I've run into a strange >problem. I'm in the process of moving code into some Perl module >libraries, and strangely, SpeedyCGI is acting like a sputtering car. The >first attempt to invoke SpeedyCGI will fail with a "Premature ending of >script headers" error for the browser and absolutely nothing in the http/ >error_log besides that. Yet, if you involve the script a second time, it >appears to run fine except that some of the initialization that should >have been done on the first invocation was never done. > >I have fallen to the "last resort" strategy of using CGI::Carp and >putting warnings everywhere. The top of my program is essentially this: > > #!/usr/bin/speedy -- -M20 -gpgreet > use CGI::SpeedyCGI; > use CGI qw(:standard escape); > use CGI::Carp; > warn "Just after CGI::Carp"; > >The warn statement is never printed on the first invocation, but is in >subsequent runs. > >Has anyone run into a problem like this? Any thoughts on how to debug >this sort of "crankyness?" > >Thanks in advance! > >Peace, Edouard :-) > >P.S. Yes, the program runs fine in straight CGI. >================================== >Edouard Lagache >Lead Developer, Penguin Greetings >http://pgreet.sourceforge.net/ >pgr...@ca... > > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 >_______________________________________________ >Speedycgi-users mailing list >Spe...@li... >https://lists.sourceforge.net/lists/listinfo/speedycgi-users > |
|
From: Edouard L. <lag...@ca...> - 2003-07-03 20:44:47
|
Dear SpeedyCGI users and developers, First, thank you to Sam Horrocks and everyone else who has gotten SpeedyCGI up and running. It is a great tool!! However, ... :-) having gotten my ecard application (Penguin Greetings) working SpeedyCGI for about 2 months now, I've run into a strange problem. I'm in the process of moving code into some Perl module libraries, and strangely, SpeedyCGI is acting like a sputtering car. The first attempt to invoke SpeedyCGI will fail with a "Premature ending of script headers" error for the browser and absolutely nothing in the http/ error_log besides that. Yet, if you involve the script a second time, it appears to run fine except that some of the initialization that should have been done on the first invocation was never done. I have fallen to the "last resort" strategy of using CGI::Carp and putting warnings everywhere. The top of my program is essentially this: #!/usr/bin/speedy -- -M20 -gpgreet use CGI::SpeedyCGI; use CGI qw(:standard escape); use CGI::Carp; warn "Just after CGI::Carp"; The warn statement is never printed on the first invocation, but is in subsequent runs. Has anyone run into a problem like this? Any thoughts on how to debug this sort of "crankyness?" Thanks in advance! Peace, Edouard :-) P.S. Yes, the program runs fine in straight CGI. ================================== Edouard Lagache Lead Developer, Penguin Greetings http://pgreet.sourceforge.net/ pgr...@ca... |
|
From: Chung-Kie T. <tu...@tu...> - 2003-06-12 07:01:32
|
Hello, While testing speedycgi + openwebmail in all circumstances, I found some problems and finally got them fixed. I think the information may be also useful to other speedycgi users so I post them here. 1. speedycgi + openwebmail doesn't work on Redhat9? Speedycgi could be compiled on Redhat9 with the fix in http://sourceforge.net/mailarchive/forum.php?thread_id=2398706&forum_id=7581, but openwebmail still report errors after several run. I found the problem is all variables are treated as tainted, even the variable is just untailed by a regex. This could a problem for all large CGIs running with speedycgi on Redhat9. An ugly solution for this is to replace the /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so with the one in redhat8. And I guess this problem could be due to the use of new gcc 3.2.2. 2. speedycgi + thttpd doesn't work for cgi returning long page? If th CGI returns very long webpage, only part of the result (mostly first 16k or 32k) is returned. This is due to a minor bug in thttpd that didn't handle EAGAIN error well. The bug can be fixed by applying the following patch --------------------------------------------- --- libhttpd.c.orig Tue Jun 10 10:20:22 2003 +++ libhttpd.c Tue Jun 10 10:21:42 2003 @@ -4169,7 +4169,8 @@ } else if ( r == 0 ) break; - nread += r; + else + nread += r; } return nread; @@ -4195,7 +4196,8 @@ return r; else if ( r == 0 ) break; - nwritten += r; + else + nwritten += r; } return nwritten; -------------------------------------------- tung -- Distributed System Laboratory (http://dslab.ee.ncku.edu.tw) Department of Electrical Engineering National Cheng Kung University, Tainan, Taiwan, R.O.C. |
|
From: Gines R. <gi...@ba...> - 2003-05-27 18:03:49
|
Hi I'm new to the list, I wonder if is possible to run perl's script with speedycgi using suExec feature in apache 1.3.27, I'm using suExec with regular perl and works fine, but, when I run the same script under speedy it runs as the apache user and not the user I have specified for suExec (excuse my english) Thanks in advance |
|
From: Gines R. <gi...@ba...> - 2003-05-26 14:02:47
|
Hi I'm new to the list, I wonder if is possible to run perl's script with speedycgi using suExec feature in apache 1.3.27, I'm using suExec with regular perl and works fine, but, when I run the same script under speedy it runs as the apache user and not the user I have specified for suExec (excuse my english) Thanks in advance |
|
From: Sam H. <sa...@da...> - 2003-05-21 18:58:26
|
Thanks for the fixes! Looks like I need to start using a malloc debugger.
Sam
> Hi all,
>
> It seems the speedy executable has some problems running under FreeBSD-5.x,
> e.g.:
>
> --cut--
> [lth@bhor speedy]$ ./speedy -- -v
> Bus error (core dumped)
> [lth@bhor speedy]$
> --cut--
>
> This, and another bus error problem stems from a couple of code bugs, solved
> by the following patch:
>
> --cut--
> --- src/speedy_opt.c Mon Sep 30 07:19:54 2002
> +++ /tmp/speedy_opt.c Tue May 20 11:11:28 2003
> @@ -165,6 +165,8 @@ static void cmdline_split(
> ++p;
> if (*p)
> strlist_append(doing_speedy_opts ? speedy_opts : perl_args,
> *p);
> + else
> + break;
> }
>
> if (*p) {
> @@ -422,7 +424,7 @@ const char * const *speedy_opt_script_ar
> }
>
> SPEEDY_INLINE const char *speedy_opt_script_fname(void) {
> - return exec_argv.ptrs[script_argv_loc];
> + return exec_argv.len > script_argv_loc ?
> exec_argv.ptrs[script_argv_loc] : NULL;
> }
>
> #ifdef SPEEDY_BACKEND
> --cut--
>
> Apparently, malloc() of current beta versions of 5.x has the the 'J' flag
> set, and is therefore much more unforgiving regarding pointer overruns than
> under 4.x (and under Linux), so this is probably why this has not been
> discovered before.
>
> Thanks to tobez for invaluable help with debugging this.
>
> /Lars
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> 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
>
|
|
From: Douglas, J. <jdo...@en...> - 2003-05-21 16:34:17
|
You are right, it does fail one test, but Speedycgi does work with the '#define' fix! I am not sure why the test errors out.=20 Joshua Douglas Systems Network Engineer Enterasys Networks Inc Email: jdo...@en... www: http://www.enterasys.com=20 -----Original Message----- From: re...@th... [mailto:re...@th...]=20 Sent: Tuesday, May 20, 2003 6:45 AM To: Sam Horrocks Cc: Douglas, Joshua; spe...@li... Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red Hat 9=20 Hm - I think it actually fails one of the tests, but passes overall. Are you interested in the output? I would be happy to send it to you. The strange thing about the problem I noticed with openwebmail is that it worked fine under RH8. That code is stated to be speedycgi compatible. Anyway, let me know if sending you the make test output is useful. I've also emailed the author of openwebmail. Regards, Ron On Tue, 20 May 2003, Sam Horrocks wrote: > The better fix is #define line at the top, so you should use that one. > With that fix, speedycgi should behave normally. > > If speedycgi is passing "make test" on RH-9, it's probably working OK=20 > now, so you should concentrate on the perl code. There are subtle=20 > differences in the way perl scripts behave when they are run=20 > persistently, and usually that's where problems come up when you=20 > switch to speedycgi. > > > > So with both fixes - either the added lines at the top of=20 > speedy_perl.c or > commenting out select(STDOUT); I have erratic=20 > problems running > openwebmail, unfortunately. The error displayed in > the browser is the > famous "premature end of script" error. I=20 > haven't been able to get much > more info than that - nothing=20 > particularly shows up in the openwebmail > log. The oddity is that it > sometimes works, sometimes doesn't. I'll try to > reproduce this=20 > running from command line. > > Changing the first line of the=20 > scripts in question to > #!/usr/bin/perl alleviates the problem. The=20 > two scripts I've specifically > notices this with is=20 > openwebmail-send.pl and openwebmail-prefs.pl. > > > For now I have these two scripts running without SpeedyCGI. > > > > Hope this helps track down the problem. > > > > Regards, > > > > Ron > > > > On Mon, 19 May 2003, Sam Horrocks wrote: > > > > > Thanks. That's probably a better quick fix than commenting it out. > > > > > > > I actually got the source to compile by adding the following lines that > > > > the top of speedy_perl.c: > > > > > > > > > > > > #ifndef setdefout > > > > # define setdefout(a) Perl_setdefout(aTHX_ a) > > > > #endif > > > > > > > > > > > > Joshua Douglas > > > > Systems Network Engineer > > > > Enterasys Networks Inc > > > > Email: jdo...@en... > > > > www: http://www.enterasys.com > > > > > > > > -----Original Message----- > > > > From: Sam Horrocks [mailto:sa...@da...] > > > > Sent: Monday, May 19, 2003 10:01 AM > > > > To: re...@th... > > > > Cc: spe...@li... > > > > Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red > > > > Hat 9 > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: ObjectStore. > > > 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 > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a=20 > relational database is painful, don't do it! Check out ObjectStore.=20 > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Speedycgi-users mailing list Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speedycgi-users > |
|
From: Lars T. <la...@th...> - 2003-05-21 09:29:58
|
Lars Thegler <la...@th...> wrote: > This, and another bus error problem stems from a couple of code bugs, > solved by the following patch: Argh. Note to self: never cut+paste patch files. Proper (hopefully) patch file attached. /Lars |
|
From: Lars T. <la...@th...> - 2003-05-21 08:45:21
|
Hi all,
It seems the speedy executable has some problems running under FreeBSD-5.x,
e.g.:
--cut--
[lth@bhor speedy]$ ./speedy -- -v
Bus error (core dumped)
[lth@bhor speedy]$
--cut--
This, and another bus error problem stems from a couple of code bugs, solved
by the following patch:
--cut--
--- src/speedy_opt.c Mon Sep 30 07:19:54 2002
+++ /tmp/speedy_opt.c Tue May 20 11:11:28 2003
@@ -165,6 +165,8 @@ static void cmdline_split(
++p;
if (*p)
strlist_append(doing_speedy_opts ? speedy_opts : perl_args,
*p);
+ else
+ break;
}
if (*p) {
@@ -422,7 +424,7 @@ const char * const *speedy_opt_script_ar
}
SPEEDY_INLINE const char *speedy_opt_script_fname(void) {
- return exec_argv.ptrs[script_argv_loc];
+ return exec_argv.len > script_argv_loc ?
exec_argv.ptrs[script_argv_loc] : NULL;
}
#ifdef SPEEDY_BACKEND
--cut--
Apparently, malloc() of current beta versions of 5.x has the the 'J' flag
set, and is therefore much more unforgiving regarding pointer overruns than
under 4.x (and under Linux), so this is probably why this has not been
discovered before.
Thanks to tobez for invaluable help with debugging this.
/Lars
|
|
From: <re...@th...> - 2003-05-20 22:24:48
|
Hm - I think it actually fails one of the tests, but passes overall. Are you interested in the output? I would be happy to send it to you. The strange thing about the problem I noticed with openwebmail is that it worked fine under RH8. That code is stated to be speedycgi compatible. Anyway, let me know if sending you the make test output is useful. I've also emailed the author of openwebmail. Regards, Ron On Tue, 20 May 2003, Sam Horrocks wrote: > The better fix is #define line at the top, so you should use that one. With > that fix, speedycgi should behave normally. > > If speedycgi is passing "make test" on RH-9, it's probably working OK now, > so you should concentrate on the perl code. There are subtle differences > in the way perl scripts behave when they are run persistently, and usually > that's where problems come up when you switch to speedycgi. > > > > So with both fixes - either the added lines at the top of speedy_perl.c or > > commenting out select(STDOUT); I have erratic problems running > > openwebmail, unfortunately. The error displayed in the browser is the > > famous "premature end of script" error. I haven't been able to get much > > more info than that - nothing particularly shows up in the openwebmail > > log. The oddity is that it sometimes works, sometimes doesn't. I'll try to > > reproduce this running from command line. > > > > Changing the first line of the scripts in question to > > #!/usr/bin/perl alleviates the problem. The two scripts I've specifically > > notices this with is openwebmail-send.pl and openwebmail-prefs.pl. > > > > For now I have these two scripts running without SpeedyCGI. > > > > Hope this helps track down the problem. > > > > Regards, > > > > Ron > > > > On Mon, 19 May 2003, Sam Horrocks wrote: > > > > > Thanks. That's probably a better quick fix than commenting it out. > > > > > > > I actually got the source to compile by adding the following lines that > > > > the top of speedy_perl.c: > > > > > > > > > > > > #ifndef setdefout > > > > # define setdefout(a) Perl_setdefout(aTHX_ a) > > > > #endif > > > > > > > > > > > > Joshua Douglas > > > > Systems Network Engineer > > > > Enterasys Networks Inc > > > > Phone: 978-684-1439 > > > > Email: jdo...@en... > > > > www: http://www.enterasys.com > > > > > > > > -----Original Message----- > > > > From: Sam Horrocks [mailto:sa...@da...] > > > > Sent: Monday, May 19, 2003 10:01 AM > > > > To: re...@th... > > > > Cc: spe...@li... > > > > Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red > > > > Hat 9 > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: ObjectStore. > > > 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 > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > 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 > |
|
From: Sam H. <sa...@da...> - 2003-05-20 22:17:31
|
The better fix is #define line at the top, so you should use that one. With that fix, speedycgi should behave normally. If speedycgi is passing "make test" on RH-9, it's probably working OK now, so you should concentrate on the perl code. There are subtle differences in the way perl scripts behave when they are run persistently, and usually that's where problems come up when you switch to speedycgi. > So with both fixes - either the added lines at the top of speedy_perl.c or > commenting out select(STDOUT); I have erratic problems running > openwebmail, unfortunately. The error displayed in the browser is the > famous "premature end of script" error. I haven't been able to get much > more info than that - nothing particularly shows up in the openwebmail > log. The oddity is that it sometimes works, sometimes doesn't. I'll try to > reproduce this running from command line. > > Changing the first line of the scripts in question to > #!/usr/bin/perl alleviates the problem. The two scripts I've specifically > notices this with is openwebmail-send.pl and openwebmail-prefs.pl. > > For now I have these two scripts running without SpeedyCGI. > > Hope this helps track down the problem. > > Regards, > > Ron > > On Mon, 19 May 2003, Sam Horrocks wrote: > > > Thanks. That's probably a better quick fix than commenting it out. > > > > > I actually got the source to compile by adding the following lines that > > > the top of speedy_perl.c: > > > > > > > > > #ifndef setdefout > > > # define setdefout(a) Perl_setdefout(aTHX_ a) > > > #endif > > > > > > > > > Joshua Douglas > > > Systems Network Engineer > > > Enterasys Networks Inc > > > Phone: 978-684-1439 > > > Email: jdo...@en... > > > www: http://www.enterasys.com > > > > > > -----Original Message----- > > > From: Sam Horrocks [mailto:sa...@da...] > > > Sent: Monday, May 19, 2003 10:01 AM > > > To: re...@th... > > > Cc: spe...@li... > > > Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red > > > Hat 9 > > > > > > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: ObjectStore. > > 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 > > > |
|
From: <re...@th...> - 2003-05-20 21:14:20
|
So with both fixes - either the added lines at the top of speedy_perl.c or commenting out select(STDOUT); I have erratic problems running openwebmail, unfortunately. The error displayed in the browser is the famous "premature end of script" error. I haven't been able to get much more info than that - nothing particularly shows up in the openwebmail log. The oddity is that it sometimes works, sometimes doesn't. I'll try to reproduce this running from command line. Changing the first line of the scripts in question to #!/usr/bin/perl alleviates the problem. The two scripts I've specifically notices this with is openwebmail-send.pl and openwebmail-prefs.pl. For now I have these two scripts running without SpeedyCGI. Hope this helps track down the problem. Regards, Ron On Mon, 19 May 2003, Sam Horrocks wrote: > Thanks. That's probably a better quick fix than commenting it out. > > > I actually got the source to compile by adding the following lines that > > the top of speedy_perl.c: > > > > > > #ifndef setdefout > > # define setdefout(a) Perl_setdefout(aTHX_ a) > > #endif > > > > > > Joshua Douglas > > Systems Network Engineer > > Enterasys Networks Inc > > Phone: 978-684-1439 > > Email: jdo...@en... > > www: http://www.enterasys.com > > > > -----Original Message----- > > From: Sam Horrocks [mailto:sa...@da...] > > Sent: Monday, May 19, 2003 10:01 AM > > To: re...@th... > > Cc: spe...@li... > > Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red > > Hat 9 > > > > > > 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 > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > 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 > |
|
From: Sam H. <sa...@da...> - 2003-05-19 20:10:13
|
Thanks. That's probably a better quick fix than commenting it out. > I actually got the source to compile by adding the following lines that > the top of speedy_perl.c: > > > #ifndef setdefout > # define setdefout(a) Perl_setdefout(aTHX_ a) > #endif > > > Joshua Douglas > Systems Network Engineer > Enterasys Networks Inc > Phone: 978-684-1439 > Email: jdo...@en... > www: http://www.enterasys.com > > -----Original Message----- > From: Sam Horrocks [mailto:sa...@da...] > Sent: Monday, May 19, 2003 10:01 AM > To: re...@th... > Cc: spe...@li... > Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red > Hat 9 > > > 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 > > > > > ------------------------------------------------------- > 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 > > > ------------------------------------------------------- > 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 > |
|
From: Douglas, J. <jdo...@en...> - 2003-05-19 16:12:44
|
I actually got the source to compile by adding the following lines that the top of speedy_perl.c: #ifndef setdefout # define setdefout(a) Perl_setdefout(aTHX_ a) #endif Joshua Douglas Systems Network Engineer Enterasys Networks Inc Phone: 978-684-1439 Email: jdo...@en... www: http://www.enterasys.com=20 -----Original Message----- From: Sam Horrocks [mailto:sa...@da...]=20 Sent: Monday, May 19, 2003 10:01 AM To: re...@th... Cc: spe...@li... Subject: Re: [Speedycgi-users] SpeedyCGI-2.21 doesn't compile under Red Hat 9=20 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. >=20 > Any responses would be of interest. >=20 > Regards, >=20 > Ron >=20 >=20 >=20 > ------------------------------------------------------- > 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,=20 > 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 >=20 ------------------------------------------------------- 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,=20 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 |
|
From: <re...@th...> - 2003-05-19 16:02:39
|
Thanks very much for the quick response, Sam - commenting out that call did the trick for the moment. Ron On Mon, 19 May 2003, Sam Horrocks wrote: > 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 > > > |
