Re: File Descriptor used by FileHandle under mod_perl 2.0.4 - is it a perl/mod_perl bug ?
Shibi NS writes: [...] > is my assumption is wrong "FD 0" is reserved for STDIN ? It's partly right: FD 0 is standard input by convention (and also by definition) but it's not reserved or otherwise treated specially by the OS or by Perl. Scott.
Re: File Descriptor used by FileHandle under mod_perl 2.0.4 - is it a perl/mod_perl bug ?
This is giving problem to me
Before I open this log file I noticed that the FD0 is points a pipe , may be
the pipe gets closed when it comes to cleanup_register
The problem arises in following scenario
1. This changes my Apache parent process FD 0 to open to this log file.
2. Later the file is got removed , but still FD 0 points to removed file.
3. Some part of my code assumes that FD0 is STDIN and tries to open this
and fails with error "Stale NFS file handle"
As you suggested if i open a dummy file handle , this issue is solved.
is my assumption is wrong "FD 0" is reserved for STDIN ?
Shibi Ns
On Wed, Jul 1, 2009 at 12:37 AM, Scott Gifford wrote:
> Shibi NS writes:
>
> [...]
>
> > my $log = new FileHandle("process.log", "a");
> >
> > When I print the $log->fileno it print FD as 0 and I have couple other
> log
> > files opened after this all of these having random numbers like 12,15
> etc. my
> > believe is FD 0 used for STDIN . Is this is bug or aim doing
> > something wrong ?
>
> If you have closed FD 0, the next file opened will get that file
> descriptor. If that's the case, one solution is to open /dev/null
> after closing FD 0; another is to just let the FD be 0, as long as it
> works.
>
> Scott.
>
--
--Shibi Ns--
Re: File Descriptor used by FileHandle under mod_perl 2.0.4 - is it a perl/mod_perl bug ?
Shibi NS writes:
[...]
> my $log = new FileHandle("process.log", "a");
>
> When I print the $log->fileno it print FD as 0 and I have couple other log
> files opened after this all of these having random numbers like 12,15 etc. my
> believe is FD 0 used for STDIN . Is this is bug or aim doing
> something wrong ?
If you have closed FD 0, the next file opened will get that file
descriptor. If that's the case, one solution is to open /dev/null
after closing FD 0; another is to just let the FD be 0, as long as it
works.
Scott.
File Descriptor used by FileHandle under mod_perl 2.0.4 - is it a perl/mod_perl bug ?
Hi All,
One of my application is using following code to execute a long running
process and the control is return to the user with link to log file so that
users can monitor the progress
$req->pool->cleanup_register(sub{$self->final_process( $req,$cgi) ;});
And in final_process sub I have File open for writing the process progress
my $log = new FileHandle("process.log", "a");
When I print the $log->fileno it print FD as 0 and I have couple other log
files opened after this all of these having random numbers like 12,15 etc.
my believe is FD 0 used for STDIN . Is this is bug or aim doing something
wrong ?
My Application is running Apache/2.2.9/Mod_perl 2.04/ perl, v5.8.8 under
Red Hat Enterprise Linux release 3
Shibi Ns
Re: trying to add header field using PerlInputFilterHandler to proxy packets
On Mon, Jun 29, 2009 at 8:07 PM, Brandon Allgood wrote: > I am running an apache server 2.2.3 on CentOS 5.2. I have turned on the > proxy with the following lines from my apache.conf: > > > ProxyRequests On > > Order deny,allow > Deny from all > Allow from all > > > > I would like to add a header field to all requests going through the proxy. If your adding a static header you can just use the Apache directive 'Header'. Using mod_perl to add a static header is somewhat overkil. -wjt
Re: quick pure perl question
On Tue, Jun 30, 2009 at 6:13 AM, André Warnier wrote: > Basically, by using the '>:raw' encoding for the output stream, I was not > expecting perl to warn me that I was (knowingly) outputting "wide > characters" there, so I was surprised at the warning. > > I /would/ have expected it if I was /not/ specifying an encoding, like > using simply '>'. But not when I am explicitly specifying '>:raw', which in > my mind, and according to my interpretation of the on-line documentation, is > equivalent to saying "output whatever you have as bytes in that string > variable right now, as is, I know what I'm doing". I think it's because it's not bytes. Well, technically it's bytes of course, but conceptually once you decode bytes you no longer have bytes. You have that abstract idea of characters. And the only way to output that information into a file (which hold bytes) is by first converting it to bytes, and that requires encoding. It's just like a thought you have in your brain. I'm not aware of any way (yet) to output that in raw format -- must be encoded into typed, spoken, or signed language first. Even if most of what I write would be considered pretty raw. Isn't :raw mostly a way to use layers to say don't do CRLF conversion -- like the old use of binmode()? Oh, maybe not according to the docs. It's best to decode and encode all character data at program boundaries and stay away form Windows. -- Bill Moseley mose...@hank.org
Re: quick pure perl question
On 30 Jun 2009, at 14:13, André Warnier wrote: I /would/ have expected it if I was /not/ specifying an encoding, like using simply '>'. But not when I am explicitly specifying '>:raw', which in my mind, and according to my interpretation of the on-line documentation, is equivalent to saying "output whatever you have as bytes in that string variable right now, as is, I know what I'm doing". You have that bit right - but the string doesn't contain bytes[1] - it contains characters. Strings can either be an octet stream or a stream of wide characters. By reading utf8 into a string you've turned it into the latter. Perl's warning that you're pushing character data into an octet hole. [1] of course it's /made/ of bytes but that's not how Perl sees it. -- Andy Armstrong, Hexten
Re: quick pure perl question
Andy Armstrong wrote: On 28 Jun 2009, at 17:33, Bill Moseley wrote: You need to encode the character data before writing back out either by encoding explicitly or using a layer. Or possibly not decode it in the first place and treat it as an opaque octet stream. All depending, of course, on what it is you're trying to achieve. I was not trying to achieve anything, and I do understand the encoding/decoding aspect. Basically, by using the '>:raw' encoding for the output stream, I was not expecting perl to warn me that I was (knowingly) outputting "wide characters" there, so I was surprised at the warning. I /would/ have expected it if I was /not/ specifying an encoding, like using simply '>'. But not when I am explicitly specifying '>:raw', which in my mind, and according to my interpretation of the on-line documentation, is equivalent to saying "output whatever you have as bytes in that string variable right now, as is, I know what I'm doing". But I guess my interpretation of the documentation is incorrect then.
Re: quick pure perl question
On 28 Jun 2009, at 17:33, Bill Moseley wrote: You need to encode the character data before writing back out either by encoding explicitly or using a layer. Or possibly not decode it in the first place and treat it as an opaque octet stream. All depending, of course, on what it is you're trying to achieve. -- Andy Armstrong, Hexten
Re: trying to add header field using PerlInputFilterHandler to proxy packets
On Tue 30 Jun 2009, Brandon Allgood wrote:
> PerlInputFilterHandler company::AddHeader
>
> and I wrote the following example handler
>
> package company::AddHeader;
>
> use strict;
> use warnings;
>
> use Apache2::Filter ();
> use Apache2::RequestRec ();
> use APR::Table ();
>
> use Apache2::Const -compile => qw(OK DECLINED);
>
> my $debug = 1;
>
> sub handler {
> my $f = shift;
>
> # if we have already seen this do nothing
> return Apache2::Const::DECLINED if $f->ctx;
>
> # get headers
> my $headers_in = $f->r->headers_in();
>
> # add header field
> $headers_in->set("Message","Hi Mom");
> $f->r->headers_in($headers_in);
>
> if($debug)
> {
> open FILE, ">>/tmp/out.log" or die $!;
> foreach my $key (keys %{$headers_in})
> {
> print FILE "$key = $headers_in->{$key}\n";
> }
> close FILE;
> }
>
> $f->ctx(1);
>
> return Apache2::Const::OK;
> }
> 1;
>
> As you can see, if debugging is turned on the headers are written to
> the file /tmp/out.log. The contents of out.log contains the new
> header, but the requests being forwarded by the proxy don't seem to
> be altered. Why is the new header not being sent?
A request level input filter is called when the request body is read.
mod_proxy does this obviously *after* sending the request header to the
backend server. Hence, adding an input header at this time is too late.
Why do you want to do that in a filter? Why don't you add it in a
request phase prior to response. Fixup would be a good place for
example.
PerlFixupHandler "sub { \
use Apache2::RequestRec;\
use Apache2::Const -compile=>'DECLINED';\
$_[0]->headers_in->{Message}='Hi, Mom'; \
return Apache2::Const::DECLINED;\
}"
Another word to your filter, did you know you can remove a filter on
first invocation? This way you can avoid the useless
return Apache2::Const::DECLINED if $f->ctx;
sub filter {
my ($f)=...@_;
# do something
$f->remove;
return Apache2::Const::DECLINED;
}
I haven't benchmarked it but I believe this is faster than return if
$f->ctx. But it only makes a difference of course if the filter is
called more than once.
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
