persistentperl-users Mailing List for PersistentPerl (Page 24)
Brought to you by:
samh
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(13) |
Mar
(12) |
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(12) |
2004 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(2) |
2005 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(3) |
Jul
(4) |
Aug
(3) |
Sep
(10) |
Oct
(10) |
Nov
(4) |
Dec
(5) |
2006 |
Jan
(7) |
Feb
(7) |
Mar
(5) |
Apr
(3) |
May
(10) |
Jun
(11) |
Jul
(10) |
Aug
(10) |
Sep
(5) |
Oct
(38) |
Nov
(55) |
Dec
(39) |
2007 |
Jan
(18) |
Feb
(10) |
Mar
(21) |
Apr
(20) |
May
(14) |
Jun
(29) |
Jul
(21) |
Aug
(42) |
Sep
(42) |
Oct
(11) |
Nov
(18) |
Dec
(11) |
2008 |
Jan
(9) |
Feb
(29) |
Mar
(40) |
Apr
(48) |
May
(17) |
Jun
(15) |
Jul
(59) |
Aug
(37) |
Sep
(39) |
Oct
(23) |
Nov
(31) |
Dec
(69) |
2009 |
Jan
(24) |
Feb
(24) |
Mar
(30) |
Apr
(55) |
May
(109) |
Jun
(110) |
Jul
(64) |
Aug
(26) |
Sep
(19) |
Oct
(26) |
Nov
(7) |
Dec
(14) |
2010 |
Jan
(9) |
Feb
(6) |
Mar
(39) |
Apr
(46) |
May
(60) |
Jun
(69) |
Jul
(40) |
Aug
(46) |
Sep
(26) |
Oct
|
Nov
(1) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
(3) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(10) |
Dec
(10) |
2015 |
Jan
(14) |
Feb
(10) |
Mar
(8) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2016 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael M. <mi...@np...> - 2004-02-12 05:42:37
|
Hi, My setup is as follows: * Fedora Core 1 * openwebmail-2.30-20040131 * perl-5.8.1-92 * kernel 2.4.22-1.2149.nptlsmp. * PersistentPerl (SpeedyCGI) version 2.22-1 All functions work in OWM and have been for some time, except every now then, my customers get an "Internal Server Error" within their browsers when they try to send email from OWM (by clicking the "New" message icon within OWM). The following is shown multiple times from the Apache error log when this happens: [Thu Feb 12 14:56:32 2004] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: openwebmail-send.pl, referer: http://www.xxx.xxx /cgi-bin/openwebmail/openwebmail-main.pl [Thu Feb 12 14:56:32 2004] [error] [client xxx.xxx.xxx.xxx] Can't use an undefined value as filehandle reference at /dev/fd/9 line 8., referer: http: //www.xxx.xxx/cgi-bin/openwebmail/openwebmail-main.pl A stop and start of the Apache server (with a touch open*pl of OWM's perl scripts), usually fixes the problem but only for a short time, as it then comes back. For the permanent fix I had to remove the "perperl" from the openwebmail-send. pl file, stop and start my httpd server and it seems to be ok now. I've kept the perperl active on all other openwebmail-???.pl scripts, only removed it on the openwebmail-send.pl script. Any ideas why this occurs or what the error means above? it seems to be related to perperl since the removal of perperl from the openwebmail-send.pl script does not reproduce the error. Michael. |
From: Michael M. <mi...@np...> - 2004-01-28 02:42:15
|
Hi, I'm using the latest PerPerl 2.22-1 release with OpenWebmail 2.30 running on Fedora Core 1. Everything works fine, but in the /var/log/messages file I get the following error all the time: Jan 28 12:00:01 server kernel: application bug: perperl_backend(4336) has SIGCHLD set to SIG_IGN but calls wait(). Jan 28 12:00:01 server kernel: (see the NOTES section of 'man 2 wait'). Workaround activated. Jan 28 12:01:01 server kernel: application bug: perperl_backend(4336) has SIGCHLD set to SIG_IGN but calls wait(). Jan 28 12:01:01 server kernel: (see the NOTES section of 'man 2 wait'). Workaround activated. Reading that relevant section of the man page says: NOTES The Single Unix Specification describes a flag SA_NOCLDWAIT (not sup- ported under Linux) such that if either this flag is set, or the action for SIGCHLD is set to SIG_IGN then children that exit do not become zombies and a call to wait() or waitpid() will block until all children have exited, and then fail with errno set to ECHILD. The original POSIX standard left the behaviour of setting SIGCHLD to SIG_IGN unspecified. Later standards, including SUSv2 and POSIX 1003.1-2001 specify the behaviour just described as an XSI-compliance option. Linux does not conform to the second of the two points just described: if a wait() or waitpid() call is made while SIGCHLD is being ignored, the call behaves just as though SIGCHLD were not being ignored, that is, the call blocks until the next child terminates and then returns the PID and status of that child. Is this something we should be concerned about or can we fix it somehow? Thanks. Michael. |
From: Michael M. <mi...@np...> - 2004-01-28 02:00:30
|
From: SAV P. <pr...@pr...> - 2003-12-17 21:55:33
|
Hello PersistentPerl-2.22 on redhat 7.2 and perl 5.6.0 theses steps fail with the t/be_memleak test perl Makefile.PL make make test and theses ones don't perl Makefile.PL make clean make make test make install |
From: Andre G. <tc...@ya...> - 2003-12-07 13:18:56
|
FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet= ter using three patented processes from General Motors. www.eoei.com?axel=3D49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently= completed tests on the new Fuel Saver. The results were astounding! Maste= r Service, a subsidiary of Ford Motor Company, also conducted extensive em= issions testing and obtained similar, unheard of results. The achievements= of the Fuel Saver is so noteworthy to the environmental community, that C= ommercial News has featured it as their cover story in their June, 2000 ed= ition. Take a test drive Today - www.eoei.com?axel=3D49 No more advertisements, thanks - http://www.5jzd.org/out5s/pre-rem2e.asp kqktk i snvpjdeakmpgta t yjxg |
From: Josue V. <mmp...@ya...> - 2003-12-04 17:23:47
|
AFTER-HOURS TRADING - BREAKING NEWS Get Quote - http://quote.money.cnn.com/quote/quote?symbols=3Dhtds Hard to Treat Diseases Incorporated - HTDS - Announces: Receipt of Tuberci= n Toxicity Study and Formation of Scientific Advisory Panel - Wednesday De= cember 3, 8:04 pm ET DELRAY BEACH, Fla.--(BUSINESS WIRE)--Dec. 3, 2003--Hard to Treat Diseases = Incorporated (Pink Sheets: HTDS) announces today that the spokesperson for= the independent medical group conducting the testing for HTTD (HTDS) has = forwarded the formal Testing Results of Tubercin=AE's Toxicity Trials to H= TTD. Tubercin of five different concentrations was administered to five groups = of mice. A pathologist at the University of Oklahoma Health Science Center= performed autopsies. The mice were randomized and only the control mouse = was known to the pathologist, as stated in the cover letter of the Patholo= gy Report. The report concludes, "All tissues evaluated, visceral organs and the brai= n were essentially normal in appearance." "The importance of this report i= s even better than I expected," stated the spokesperson for the medical gr= oup. "As the testing continues and if the results are similar to those of = Chemotherapy and or radiation with no harmful side effects, Tubercin has e= normous potential for the treatment of cancer and the immune system." The President and CEO of HTTD, Mr. Colm J. King is in the process of formi= ng a Scientific Advisory Panel with leading Oncologists and Immunologists = from prestigious institutions in the U.S. The panel will review the report= s and results of Tubercin=AE's findings and will report back to Mr. King w= ith the ongoing reports in layman language for the shareholders. "We are continuing to receive promising results regarding Tubercin=AE and = we're looking forward to additional positive results in the near future," = stated Mr. King. "These tests prove that Tubercin=AE is non-toxic and is t= he first step on the way to human clinical trials as well as the first pos= itive breakthrough conducted in the United States with an independent medi= cal group for Tubercin=AE. Operating out of Delray Beach, Florida, Hard to Treat Diseases Incorporate= d ("HTTD") holds the international marketing rights, except South Korea, t= o Tubercin=AE, a patented immunostimulant developed for combating Cancer u= nder medical patent (US Patent 6,274,356). The unique properties unlike ot= her cancer products are clearly stated in the abstract summary of the pate= nt... "A carbohydrate complex, which is a mixture of low molecular-weight = polysaccharides of an arabinomannan structure extracted from Mycobacterium= tuberculosis, is highly effective in treating various cancer patients wit= hout incurring any adverse side effects." Statements in this press release that are not historical facts are forward= -looking statements within the meaning of the Securities Act of 1933, as a= mended. Those statements include statements regarding the intent, belief o= r current expectations of the Company and its management. Such statements = reflect management's current views, are based on certain assumptions and i= nvolve risks and uncertainties. Actual results, events, or performance may= differ materially from the above forward-looking statements due to a numb= er of important factors, and will be dependent upon a variety of factors, = including, but not limited to, our ability to obtain additional financing = and access funds from our existing financing arrangements that will allow = us to continue our current and future operations and whether demand for ou= r product and testing service in domestic and international markets will c= ontinue to expand. The Company undertakes no obligation to publicly update= these forward-looking statements to reflect events or circumstances that = occur after the date hereof or to reflect any change in the Company's expe= ctations with regard to these forward-looking statements or the occurrence= of unanticipated events. y brvz |
From: Sam H. <sa...@da...> - 2003-10-12 06:33:16
|
PersistentPerl release 2.22 is available at: http://daemoninc.com/PersistentPerl/download.html The changes since 2.21 are: - Redhat9 fixes. - Better support for setuid under Solaris. - Fixes for HP-UX 11.22 - Fix for memory leak in speedy_backend reported by James H. Thompson - speedy_file.c fixes for bugs reported by Dmitri Tikhonov - Fix from Lars Thegler for buffer overrun in speedy_opt.c - Add efence malloc debugging. |
From: Sam H. <sa...@da...> - 2003-10-11 05:33:54
|
Fix is on the cvs server. > As well, I am finding that the make package process is no longer > working. > > For RedHat 9 (and 8 I think) rpm has been upgraded. Now you need to use > the command "rpmbuild -bb" instead of "rpm -bb". Unfortunately there > are a few more changes which I am not capable of figuring out - the > spec file needs to changed in some way. > > Hope that helps, > Jay > > > > ------------------------------------------------------- > 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 > _______________________________________________ > Persistentperl-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/persistentperl-users > |
From: Sam H. <sa...@da...> - 2003-10-05 01:32:35
|
THis is fixed in the latest version on the cvs server. > Hello, > > I want to install Persistent Perl2.2.1 to environment; > OS: Red Hat Linux 9 (Japan) > Web: Apache2.0.40 > perl: Perl5.8.0 > > But in make process, error in below occured. > > ....snip.... > gcc -o perperl_backend perperl_backend_main.o perperl_perl.o perperl_util.o perp > erl_sig.o perperl_frontend.o perperl_backend.o perperl_file.o perperl_slot.o per > perl_poll.o perperl_ipc.o perperl_group.o perperl_script.o perperl_opt.o perperl > _optdefs.o xsinit.o -rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread > -multi/CORE -L/usr/local/lib /usr/lib/perl5/5.8.0/i386-linux-thread-multi/auto/ > DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -lpe > rl -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil > perperl_perl.o(.text+0xf98): In function `onerun': > : undefined reference to `setdefout' > collect2: ld returned 1 exit status > make[1]: *** [perperl_backend] Error 1 > make[1]: Leaving directory `/home/admin/PersistentPerl-2.21/perperl_backend' > make: *** [subdirs] Error 2 > > How I avoid this error? > Please help. > > > ------------------------------------------------------- > 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 > _______________________________________________ > Persistentperl-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/persistentperl-users > |
From: @lists.sourceforge.net - 2003-09-21 23:00:14
|
<html> <head> <meta http-equiv="Content-Language" content="zh-tw"> <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> <meta name="ProgId" content="FrontPage.Editor.Document"> <meta http-equiv="Content-Type" content="text/html; charset=big5"> <title>·s¼Wºô¶1</title> <style> <!-- p{font-size:10pt;line-height:150%;color:#444E5B;} --> </style> </head> <body> <p><b><font face="·s²Ó©úÅé"> </font> <font face="·s²Ó©úÅé"> <a target="_blank" style="text-decoration: none" href="http://6192.24cc.cc/">¡m¤W¯Z±Ú»Ä²¢°O¨Æ¡n</a></font></b><font face="·s²Ó©úÅé"><b><a target="_blank" style="text-decoration: none" href="http://6192.24cc.cc/">§Ú̳£´¿¸g·Qn<i>¡u¦W´¥|®ü</i>¡v</a></b></font></p> <p><a href="http://logserver.url.com.tw/cevent.asp?c=2023&c2=12&e=" target="_blank" style="color: #003388; text-decoration: none"><br> </a> §Ú̳o¨Ç¦b¥x¥_´M³V¹Ú·Q¡B´Á«Ý¬ü¹Ú¦¨¯uªº¤H¡A</p> <p> ¦³¨S¦³·Q¹L¡A</p> <p> ¯d¦b¥x¥_ªº²z¥Ñ¡A¨s³º¬O¤°»ò¡H</p> <p> §Ṳ́£¬O³£´¿¸g·Q¹Ln¦b¥x¥_¡u¦W´¥|®ü¡v¶Ü¡H</p> <p> ¸g¹L³o»ò¦h¦~¡A¨º¨Ç¼ö±¡¡A³Ñ¤U¦h¤Ö©O¡H<a target="_blank" style="color: #003388; text-decoration: none" href="http://thankU.24cc.com"><img height="15" src="http://ad.url.com.tw/weekly/go.gif" width="15" border="0"></a></p> <p>¡@</p> <p style="line-height: 125%; margin-top: 6px; margin-bottom: 3px"><b> <a href="http://6192.24cc.cc/">³o¬O¤@¥÷¥Î¤ß»s§@ªº¶g³ø¡AÅwªïÂà±Hµ¹±zªºªB¤Í</a><font color="#ff5050"> </font></b></p> <p style="line-height: 125%; margin-top: 6px; margin-bottom: 3px">¡@</p> <p style="line-height: 125%; margin-top: 6px; margin-bottom: 3px"><b> <font color="#ff5050"> <a href="6192.24cc.cc/">:<font size="2">) see you next week!...............................................<img src="http://www.url.com.tw/include/index/topic/weekly/images/end.gif" align="baseline" border="0" width="7" height="7"></font></a></font></b></p> </body> </html> |
From: OHTSUKA Ko-h. <te...@sa...> - 2003-08-09 04:00:56
|
Hello, I want to install Persistent Perl2.2.1 to environment; OS: Red Hat Linux 9 (Japan) Web: Apache2.0.40 perl: Perl5.8.0 But in make process, error in below occured. ....snip.... gcc -o perperl_backend perperl_backend_main.o perperl_perl.o perperl_util.o perp erl_sig.o perperl_frontend.o perperl_backend.o perperl_file.o perperl_slot.o per perl_poll.o perperl_ipc.o perperl_group.o perperl_script.o perperl_opt.o perperl _optdefs.o xsinit.o -rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread -multi/CORE -L/usr/local/lib /usr/lib/perl5/5.8.0/i386-linux-thread-multi/auto/ DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -lpe rl -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil perperl_perl.o(.text+0xf98): In function `onerun': : undefined reference to `setdefout' collect2: ld returned 1 exit status make[1]: *** [perperl_backend] Error 1 make[1]: Leaving directory `/home/admin/PersistentPerl-2.21/perperl_backend' make: *** [subdirs] Error 2 How I avoid this error? Please help. |
From: Garth B. <gbe...@bl...> - 2003-05-27 16:34:55
|
=20 I have been trying to modify the mod_persistentperl source to have more discretion over what type of files get the Non Parse Header flags. For those who don't know, this is required to write your own HTTP header and not let apache do it. =20 Right now the source is hard coded for files starting with 'nph-' to get the flag. I would prefer an apache option setup. I added the details for my own 'PersistentForceNPH' flag. The problem is, none of the Persistent* flags in httpd.conf seem to be file specific. They get loaded on start and that is about it. Is that by design? Is there any way to get the flags on each request? =20 ~~ Garth Benedict Bluesocket, Inc (781) 328-0888x214 =20 |
From: Jay L. <ja...@in...> - 2003-05-26 15:48:22
|
I am doing a generic build of PersistentPerl on a stock RedHat 9.0 system. After a bit of digging I found: http://216.239.41.100/ search?q=cache:PiFj1lO2YOkJ:turtle.ee.ncku.edu.tw/openwebmail/doc/ readme.txt+setdefout&hl=en&ie=UTF-8 src/speedy_perl.c needs the following added: #ifndef setdefout # define setdefout(a) Perl_setdefout(aTHX_ a) #endif As well, I am finding that the make package process is no longer working. For RedHat 9 (and 8 I think) rpm has been upgraded. Now you need to use the command "rpmbuild -bb" instead of "rpm -bb". Unfortunately there are a few more changes which I am not capable of figuring out - the spec file needs to changed in some way. Hope that helps, Jay |
From: Garth B. <gbe...@bl...> - 2003-05-13 21:45:40
|
I am porting over piece by piece, so we have both mod_perl and mod_persistentperl Our httpd.conf: ... ErrorLog /home/blueserver/logs/error_log LogLevel warn ... <Files *.pl> SetHandler perl-script PerlHandler Apache::Registry PerlLogHandler Apache::SizeLimit Options ExecCGI </Files> LoadModule persistentperl_module /home/blueserver/bin/mod_persistentperl.so <Files *.perpl> SetHandler persistentperl-script Options ExecCGI </Files> ... I copied the .pl files and to .perpl, and changed '!/usr/bin/perl' to '#!/usr/bin/perperl -- -r4 -t10 -g' in those files. In the mod_perl world, all warns and stuff would go to the apache ErrorLog. This would be the best solution with perperl, but I can live with all the output going to a single file. Where is the output of warns, run through apache, suppose to go? My guess is that the backend pipes stderr to some unknown place....?? When using mod_persistentperl, what is the recommended setup for Carp, or logging in general? Sorry for not including the setup in the original message. By the way, I have tried twice to set myself up on the mailing list by entering my info here: http://lists.sourceforge.net/lists/listinfo/persistentperl-users. I never received a confirmation email. Any reason you know of why I couldn't? -----Original Message----- From: Sam Horrocks [mailto:sa...@da...]=20 Sent: Tuesday, May 13, 2003 5:03 PM To: Garth Benedict Cc: per...@li... Subject: Re: [Persistentperl-users] Logging with perperl=20 What do you mean by "normally". Where do you expect to see the error output? On the screen? In the apache error log? Are you using mod_persistentperl or the perperl binary? > I am trying to move out mod_perl infrastructure to Persistent perl. I > am having a horrible time tracking down errors. warn statements do not > appear anywhere. > > I have tested 'use Carp', 'use CGI::Carp' (with and without carpout), > 'Apache::warn', and plain 'warn'. I cannot track down any of the > output. Is there a directive for perperl to make it log "normally". > > Thanks for any help. > > ~~ > Garth Benedict > Bluesocket, Inc > (781) 328-0888x214 |
From: Sam H. <sa...@da...> - 2003-05-13 21:03:30
|
What do you mean by "normally". Where do you expect to see the error output? On the screen? In the apache error log? Are you using mod_persistentperl or the perperl binary? > I am trying to move out mod_perl infrastructure to Persistent perl. I > am having a horrible time tracking down errors. warn statements do not > appear anywhere. > > I have tested 'use Carp', 'use CGI::Carp' (with and without carpout), > 'Apache::warn', and plain 'warn'. I cannot track down any of the > output. Is there a directive for perperl to make it log "normally". > > Thanks for any help. > > ~~ > Garth Benedict > Bluesocket, Inc > (781) 328-0888x214 |
From: Garth B. <gbe...@bl...> - 2003-05-12 19:29:35
|
=20 I am trying to move out mod_perl infrastructure to Persistent perl. I am having a horrible time tracking down errors. warn statements do not appear anywhere. =20 I have tested 'use Carp', 'use CGI::Carp' (with and without carpout), 'Apache::warn', and plain 'warn'. I cannot track down any of the output. Is there a directive for perperl to make it log "normally". =20 Thanks for any help. =20 ~~ Garth Benedict Bluesocket, Inc (781) 328-0888x214 =20 |
From: James H. T. <jh...@la...> - 2003-05-04 02:33:24
|
On Redhat 8.0 when I do: perl -MCPAN -e shell install CGI::SpeedyCGI I get: t/hold_stdio..........FAILED test 2 Failed 1/2 tests, 50.00% okay Jim James H. Thompson jh...@la... |
From: Sam H. <sa...@da...> - 2003-03-13 21:48:12
|
How about putting a frontend in front of your script like this: (sed "s/^/MAIL/"; sed "s/^/ENVELOPE/" 0<&1) | yourscript.pl Then in yourscript.pl do this: while (<STDIN>) { s/^(MAIL|ENVELOPE)//; if ($1 eq 'MAIL') { # $_ is a line from the mail message } else { # $_ is a line from the envelope } } > Here is the problem... > > SYNOPSIS > qmail-queue > > DESCRIPTION > qmail-queue reads a mail message from descriptor 0. It then reads envelope information from descriptor 1. It > places the message into the outgoing queue for future delivery by qmail-send. > > qmail-queue is what I am replacing with my own custom script. qmail-queue is written in C, and can read descriptor 0 (the message) from qmail-smtpd, and read descriptor 1 (the envelope) from qmail-smtpd. A script written in perl can read both descriptors also, but once I try to write the script in perperl, it wont work because it cannot read descriptor 1, and I cant get everything to pass out of qmail-smtpd on descriptor 0 without a major rewrite of the qmail-smtpd code. > > Thanks, > Dallas > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Persistentperl-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/persistentperl-users > |
From: Dallas E. <da...@nm...> - 2003-03-13 21:27:21
|
> -----Original Message----- > From: Sam Horrocks [mailto:sa...@da...] > Sent: Thursday, March 13, 2003 3:22 PM > To: Dallas Engelken > Cc: per...@li...; > spe...@li... > Subject: Re: [Persistentperl-users] RE: [Speedycgi-users] Help with > STDOUT=20 >=20 >=20 > You should be able to do email filtering with the current=20 > implementation. > Just read from STDIN. >=20 Here is the problem... SYNOPSIS qmail-queue DESCRIPTION qmail-queue reads a mail message from descriptor 0. It then = reads envelope information from descriptor 1. It places the message into the outgoing queue for future delivery by = qmail-send. qmail-queue is what I am replacing with my own custom script. = qmail-queue is written in C, and can read descriptor 0 (the message) = from qmail-smtpd, and read descriptor 1 (the envelope) from qmail-smtpd. = A script written in perl can read both descriptors also, but once I = try to write the script in perperl, it wont work because it cannot read = descriptor 1, and I cant get everything to pass out of qmail-smtpd on = descriptor 0 without a major rewrite of the qmail-smtpd code. Thanks, Dallas |
From: Sam H. <sa...@da...> - 2003-03-13 21:21:44
|
You should be able to do email filtering with the current implementation. Just read from STDIN. > ah, ignore my other post. it looks like it's impossible at this point. it would be cool if perperl could act like perl and suidperl in this case... it would speed up my email processing tremendously because i would have no overhead for the perl invocation or establishing a DBI connection on each email for logging. > > i'll keep an eye out for future releases.. i hope it is something you will consider. |
From: Sam H. <sa...@da...> - 2003-03-13 20:15:36
|
> My question to you is, why can I read the STDOUT when I use the perl or suidperl interpreter but not perperl. Because PersistentPerl does not support reading input from STDOUT. The PersistentPerl code is not written to accomodate that. The reasons PersistentPerl doesn't support reading from STDOUT are: 1) It's not trivial to implement in the current way of doing things. 2) An overwhelming majority of the the perl programs out there use STDOUT only for output. They do this because, by Unix convention, STDOUT is used for output, not input. |
From: Dallas E. <da...@nm...> - 2003-03-13 20:13:22
|
> -----Original Message----- > From: Sam Horrocks [mailto:sa...@da...] > Sent: Thursday, March 13, 2003 1:04 PM > To: Dallas Engelken > Cc: per...@li...; > spe...@li... > Subject: Re: [Speedycgi-users] Help with STDOUT=20 >=20 >=20 > Your script is trying to read input from STDOUT, is that=20 > correct? That > won't work - STDOUT works only for output, not input. >=20 > This might work, if and when I add code to pass filehandles,=20 > but at the > moment, PersistentPerl won't do that. >=20 ah, ignore my other post. it looks like it's impossible at this point. = it would be cool if perperl could act like perl and suidperl in this = case... it would speed up my email processing tremendously because i = would have no overhead for the perl invocation or establishing a DBI = connection on each email for logging. =20 i'll keep an eye out for future releases.. i hope it is something you = will consider.=20 thanks, dallas |
From: Dallas E. <da...@nm...> - 2003-03-13 19:54:33
|
> -----Original Message----- > From: Sam Horrocks [mailto:sa...@da...] > Sent: Thursday, March 13, 2003 1:11 PM > To: Dallas Engelken > Cc: per...@li...; > spe...@li... > Subject: Re: [Persistentperl-users] Followup to my STDOUT issue=20 >=20 >=20 > > When I look at Step 3 on how speedy works, I see that it=20 > does not pipe STDOUT to the backend? > =20 > That's true. STDOUT is sent from the backend to the frontend=20 > as output > from the script. STDOUT, is not sent from the frontend to the backend > for input. STDOUT is an output channel. >=20 > > How am I supposed to read STDOUT from a previous pipe into=20 > my script?? >=20 > With STDIN. > =20 > > Like the one I posted before. I'm trying to write a filter=20 > that mail pipes through, but I dont want to invoke a perl=20 > interpreter for each email! In order to get the envelope=20 > addresses, I have to read STDOUT from the qmail-smtpd pipe to=20 > my script. >=20 > That should work. In pipes, the STDOUT of the previous command > (qmail in this case) becomes STDIN for the next command (your script). > Should work fine. STDIN is passed by the frontend from the=20 > pipe to the > backend's STDIN, the backend reads it, produces output on STDOUT, then > STDOUT is copied from the backend to the frontend, where the frontend > emits it on its STDOUT. >=20 >=20 Thanks for the response Sam. My question to you is, why can I read the = STDOUT when I use the perl or suidperl interpreter but not perperl. =20 Did you see my DEBUG output from my first post? perl and suidperl can = read the =20 > SOUT LINE: Fda...@nm...Tda...@nm...=20 but perperl cannot. Thanks, Dallas |
From: Sam H. <sa...@da...> - 2003-03-13 19:11:40
|
I can't think of any current problems with exit. There used to be a bug involving exit, but that was fixed. If you're doing CGI programming with fork and starting something that will continue running in the background, then you have to be careful to close your files. This is more a CGI guideline though, because it's true for both perl and PersistentPerl. http://www.ssc.com/websmith/issues/i6/ws107.html If you use the Group option, then all scripts in a group will share global signal handler settings, becaue they all run in the same process. But if you set up your signal handlers on each run (instead of setting them in a BEGIN), then you're probably OK . If you don't use groups (Group option is set to "none"), then there shouldn't be any special requirements for signal handlers. > Hi all, > > When coding or porting a program to play nicely with Persistent Perl (aka SpeedyCGI), is there anything special that needs to be done when one uses exit, fork, or a signal handler? FastCGI and mod_perl seem to require you to do special things so the programs work correctly, but the webpage for Persistent Perl doesn't really mention anything special. > > Thanks, > Kevin > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Persistentperl-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/persistentperl-users > |
From: Sam H. <sa...@da...> - 2003-03-13 19:11:08
|
> When I look at Step 3 on how speedy works, I see that it does not pipe STDOUT to the backend? That's true. STDOUT is sent from the backend to the frontend as output from the script. STDOUT, is not sent from the frontend to the backend for input. STDOUT is an output channel. > How am I supposed to read STDOUT from a previous pipe into my script?? With STDIN. > Like the one I posted before. I'm trying to write a filter that mail pipes through, but I dont want to invoke a perl interpreter for each email! In order to get the envelope addresses, I have to read STDOUT from the qmail-smtpd pipe to my script. That should work. In pipes, the STDOUT of the previous command (qmail in this case) becomes STDIN for the next command (your script). Should work fine. STDIN is passed by the frontend from the pipe to the backend's STDIN, the backend reads it, produces output on STDOUT, then STDOUT is copied from the backend to the frontend, where the frontend emits it on its STDOUT. |