solution to readdir/opendir mod_perl problem: rebuild!
We upgraded our systems to RedHat 7.2 with glibc2.2.4
and all of a sudden, our mod_perl scripts which call
readdir() would either fail with an exception, or
readdir() in list context would return the correct # of
items but each item as an empty string.
We scanned the modperl list and found about 50 posts in
about 8 threads on this topic (!) but no answers.
There were various workaround suggestions, such as
using glob(), but these were not useful to us since we
rely on a number of third-party perl modules which call
readdir() and it was not practical to modify them.
We discovered that this problem is caused by a build
mismatch between perl and mod_perl that is a result of
a nasty binary incompatibility between glibc2.2.4 and
glibc2.1.3. So much for DSO versioning!
To get rid of the problem, you _must_ rebuild perl from
scratch on a system with glibc2.2.4 (in our case we had
perl 5.6.1), then you _must_ rebuild mod_perl from
scratch on the same system (we had mod_perl 1.26) and
then build and run httpd on the same system.
(ok, technically it doesn't have to be the same system,
but you must have the same glibc version installed
during each build and also when you run httpd).
Or if you're not the building type, you'll need to
locate some pre-done build that was done entirely
on a system with glibc2.2.4.
The analysis of the problem goes something like this:
- the code which is hurt by the glibc incompatibility
is the code that actually calls the C readdir()
function. it gets built into
/opt/perl/lib/5.6.1/i686-linux/CORE/libperl.a by the
perl build.
- that code is then statically linked into mod_perl by
the mod_perl build (regardless of whether mod_perl
itself is statically or dynamically linked to httpd).
- when you build libperl.a on RedHat 6 with glibc2.1.3,
struct dirent is 272 bytes long and dirent.d_name is at
offset 15.
- when you build libperl.a on RedHat 7 with glibc2.2.4,
struct dirent is 276 bytes long and dirent.d_name is at
offset 19.
- a compile time / runtime discrepancy here could
definitely cause the symptom we're seeing (right number
of files, but empty filenames) because the struct is
like this:
struct dirent {
longd_ino;
__kernel_off_t d_off;
unsigned short d_reclen;
chard_name[256];
};
If glibc2.2 placed the name at the correct place, but
libperl.a was reading it out 4 bytes early, then
libperl.a would probably see a byte of 0 as the first
byte of the name, hence looking like an empty C string.
We say this because d_off is probably either 0 all the
time (since the man page says Use of other fields
[including d_off] will harm the portability of your
programs,) or it's probably 0 because it's the third
byte of d_off and you'd have to have a directory that
was 256*256 bytes or more in order to get a nonzero
value for d_off on a little endian machine. So really
this bug discriminates against people with a lot of
files or big-endian machines :) We could test this
theory by creating large directories but we're happy
that rebuilding it works :)
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: solution to readdir/opendir mod_perl problem: rebuild!
Louis Semprini wrote: We upgraded our systems to RedHat 7.2 with glibc2.2.4 and all of a sudden, our mod_perl scripts which call readdir() would either fail with an exception, or readdir() in list context would return the correct # of items but each item as an empty string. We scanned the modperl list and found about 50 posts in about 8 threads on this topic (!) but no answers. There were various workaround suggestions, such as using glob(), but these were not useful to us since we rely on a number of third-party perl modules which call readdir() and it was not practical to modify them. We discovered that this problem is caused by a build mismatch between perl and mod_perl that is a result of a nasty binary incompatibility between glibc2.2.4 and glibc2.1.3. So much for DSO versioning! To get rid of the problem, you _must_ rebuild perl from scratch on a system with glibc2.2.4 (in our case we had perl 5.6.1), then you _must_ rebuild mod_perl from scratch on the same system (we had mod_perl 1.26) and then build and run httpd on the same system. (ok, technically it doesn't have to be the same system, but you must have the same glibc version installed during each build and also when you run httpd). Thanks a lot Louis, This solution will appear in the next release of the guide in the troubleshooting chapter. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: readdir()
This feature is present when compiling under rh 7.1. With rh 6.2 there is no problem. This seems to be related as you have said to the glibc version. I compiled on rh 6.2 and move the httpd binary on rh 7.1 and there was no problem with readdir anymore. On Thu, 26 Apr 2001, Lincoln Stein wrote: Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: Hello, LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- Pierre Laplante SedNove Inc.
Re: readdir()
Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: Hello, LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
readdir()
Hi Doug, Perl 5.6.0 breaks the readdir() function when running under mod_perl. This is with the most recent versions of Apache and mod_perl, as well as with older versions. I see the same problem reported in the mailing list going back to December 2000, but no hint of a resolution. Is there any fix? Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
Re: readdir()
Hello, LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: readdir()
On Wed, 25 Apr 2001, Andrew Ho wrote: LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). AFAIK, it's broken only under Linux and then only when using glibc2.2. It works fine under glibc2.1. - Paul
Re: readdir()
Hi, I'm also experiencing issues using readdir() under mod_perl v1.25/apache 1.3.19 on a perl 5.6.1 system freshly compiled in RH7.1 + gcc 2.96/glibc 2.2. I _can_ get correct behavior when running readdir() in perl -e on the command line, but when run thru mod_perl/apache it returns null/empty. It's strange: I keep trying to run finds against the mod_perl and apache source code to detect readdir, and I get hardly anything useful.. I wonder where the breakdown is :p A temporary workaround is to shell out and do a find -maxdepth 1, but that's unworkable for anything beyond my own toy use :p.. Cheers, - Matt
Re: readdir()
On Thu, 26 Apr 2001, Mathew Hennessy wrote: Hi, I'm also experiencing issues using readdir() under mod_perl v1.25/apache 1.3.19 on a perl 5.6.1 system freshly compiled in RH7.1 + gcc 2.96/glibc 2.2. I _can_ get correct behavior when running readdir() in perl -e on the command line, but when run thru mod_perl/apache it returns null/empty. It's strange: I keep trying to run finds against the mod_perl and apache source code to detect readdir, and I get hardly anything useful.. I wonder where the breakdown is :p A temporary workaround is to shell out and do a find -maxdepth 1, but that's unworkable for anything beyond my own toy use :p.. use glob() or the diamond operator *, the suggested workarounds in the two threads from the past (see the archives). Of course this should be resolved. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Strange Problem with opendir / readdir
Hi!
I have strange problems while using opendir / readdir
under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache
and not a Mason Bug.
I have no problem to run the same directly from the shell.
Is there a known bug?
Kind regards
Cornelius Kuschnereit
Environement:
Apache 1.3.19
modperl 1.25
mason 1.01
RedHat 7.0
reiserfs
--
test1_opendir.html
my little test:
--
%init
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
/%init
Test - BR
% foreach $dir (sort @dirs) {
file:% $dir %
% }
BR
--
the (wrong) result:
--
Test - BR
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
BR
--
--
test1_opendir.pl
my little (working) test:
--
#!/usr/bin/perl
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
print "Test - \n";
foreach $dir (sort @dirs) {
print "file: $dir\n";
}
print "\n";
--
the (right) result:
--
Test -
file: .
file: ..
file: bin
file: cgi-bin
file: conf
file: htdocs
file: htdocs_mason_data_cache
file: icons
file: include
file: libexec
file: logs
file: man
file: perlmod
file: proxy
--
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: Hi! I have strange problems while using opendir / readdir under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache and not a Mason Bug. I have no problem to run the same directly from the shell. Is there a known bug? A known bug: http://forum.swarthmore.edu/epigone/modperl/landchoigrerm :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote: opendir( DIR, $directory ); opendir( DIR, $directory ) or die "Can't read $directory because of $!";
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote:
@dirs = readdir( DIR );
foreach $dir (sort @dirs) {
next unless -d "directory/$dir";
print "file: $dir\n";
}
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: I have strange problems while using opendir / readdir under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache and not a Mason Bug. I have no problem to run the same directly from the shell. Is there a known bug? As far as I can tell, it's a mod_perl, glibc2.2 compatibility bug. - Paul
RE: [Mason] Strange Problem with opendir / readdir
Yes! I can see all Files and Dirs without . and .. Can this be a hint why readdir dosn't work? Thanx! Cornelius -- the (right) result: -- Test -x BR 1 file:"/usr/local/apache/bin" length of filename:21BR 2 file:"/usr/local/apache/cgi-bin" length of filename:25BR 3 file:"/usr/local/apache/conf" length of filename:22BR 4 file:"/usr/local/apache/htdocs" length of filename:24BR 5 file:"/usr/local/apache/htdocs_mason_data_cache" length of filename:41BR 6 file:"/usr/local/apache/htdocs_mason_data_cache2" length of filename:42BR 7 file:"/usr/local/apache/icons" length of filename:23BR 8 file:"/usr/local/apache/include" length of filename:25BR 9 file:"/usr/local/apache/libexec" length of filename:25BR 10 file:"/usr/local/apache/logs" length of filename:22BR 11 file:"/usr/local/apache/man" length of filename:21BR 12 file:"/usr/local/apache/perlmod" length of filename:25BR 13 file:"/usr/local/apache/proxy" length of filename:23BR BR Does glob() work? my @files = glob( "$directory/*" );
open/opendir/readdir fail under latest perl/mod_perl/apache
Everyone:
Here's something that myself and my sysadmin guy have been working on
for a bit: opendir appears to be broken for us on a new Apache/mod_perl
installation.
We've tried checking out the mailing list archives but nothing jumpped
out at us along these lines.
Any ideas from anyone? (much more info follows...)
Thanks,
- Richard
(BTW, "use CGI::Carp 'fatalsToBrowser';" causes our installation to
segfault when included in my startup.perl program, which is invoked
from within httpd.conf with 'PerlRequire startup.perl'... just to muddy
the waters some more. :-) )
(BTW 2, do Apache::Registry scripts now allow variable _not_ to have
explicit package declaration and/or explicit lexical declarations?
Damian is showing me a program that he wrote that has neither, and yet
runs under Apache::Registry, and this freaks me out.)
Original Message
Subject: open/opendir/readdir fail under latest perl/mod_perl/apache.
Date: Mon, 11 Dec 2000 13:17:59 -0500
From: Damian M Gryski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I've been trying to use opendir/readdir under mod_perl 1.24 with
apache 1.2.14 under Debian GNU/Linux. The system is an up-to-date
Debian `woody' system, and so is using the .deb of perl 5.6.0
The problem is that while neither opendir nor readdir actually return
errors, they also don't return the results I'm expecting: namely,
the directory contents. Instead, the results consist of a list
containing the correct # of items, but each item is a zero-length
scalar (and _not_ the undefined value!) rather than a filename.
This problem does not occur on a system running mod_perl 1.24
with apache 1.3.12 and perl 5.005_03. I can't find anything in the
changelog for either mod_perl or apache suggesting a change in how
opendir is used.
Here's some example code that fails:
---8 CUT HERE 8---
#!/usr/bin/perl
use strict;
my $some_dir = "/home/dmg";
opendir(DIR, $some_dir) || die "can't opendir $some_dir: $!";
my @files = readdir(DIR);
closedir(DIR);
print "Content-type: text/plain\n\n";
print join("\n", @files), "\n";
exit 0;
---8 CUT HERE 8---
On the working system, it correctly produces the list of files
in my home directory. On the `broken' system, it produces a list
of zero-length strings. (On both systems, it works when run from the
command line.)
TIA,
Damian
--
Damian Gryski
ShadNet Admin
[EMAIL PROTECTED]
Re: open/opendir/readdir fail under latest perl/mod_perl/apache
On Mon, 11 Dec 2000, Richard Dice wrote: Everyone: Here's something that myself and my sysadmin guy have been working on for a bit: opendir appears to be broken for us on a new Apache/mod_perl installation. Rich, please send in the relevant parts of the strace output, or may be you will learn what's the problem while looking at it. I doubt it has anything to do with mod_perl. Does this code work from the command line? FYI, your code works for me... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: open/opendir/readdir fail under latest perl/mod_perl/apache
Have you looked at the permissions and verified that the uid of the user running apache has permissions to list the contents of the directory? It's a good suggestion, but we've been all up and down this one over here. (For instance, if it didn't have perms, then the opendir/readdir commands would fail -- they're not failing, they're just giving garbage output.) Damian and I are now going through strace, per Stas' suggestion. That didn't seem to yield any useful info, but we'll bring it to the list eventually. We're now giving ltrace a go... sure, it yields a few gigabytes of log information, but you gotta do what you gotta do... Cheers, - Richard -- Richard Dice * Personal 519 635 9568 * Fax 519 635 9569 ShadNet Creator * http://shadnet.shad.ca/ Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/ "squeeze the world 'til it's small enough to join us heel to toe" - jesus jones
Re: open/opendir/readdir fail under latest perl/mod_perl/apache
On Mon, 11 Dec 2000, Richard Dice wrote: Have you looked at the permissions and verified that the uid of the user running apache has permissions to list the contents of the directory? It's a good suggestion, but we've been all up and down this one over here. (For instance, if it didn't have perms, then the opendir/readdir commands would fail -- they're not failing, they're just giving garbage output.) yup :) Damian and I are now going through strace, per Stas' suggestion. That didn't seem to yield any useful info, but we'll bring it to the list eventually. We're now giving ltrace a go... sure, it yields a few gigabytes of log information, but you gotta do what you gotta do... It shouldn't be gigabytes -- you want to strace only special events like open and read, and you want to attach to the process only before running the script (run under -X) -- so you should have just a few lines!!! % strace -p PID -e trace=open,read _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: open/opendir/readdir fail under latest perl/mod_perl/apache
It shouldn't be gigabytes -- you want to strace only special events like
open and read, and you want to attach to the process only before running
the script (run under -X) -- so you should have just a few lines!!!
% strace -p PID -e trace=open,read
I was talking about ltrace, not strace, when I said it would take gigs.
And even then, I was wrong -- it was only about 50mb. (And that didn't
take into account specifiying which events to trace on.)
Anyhow... here are the results...
Test program: /web/ShadNet/sys/cvs/webdocs/foo.mp (no, it's
not the same as the one before... I tried an IO::Dir object
this time, but it makes an underlying call to Perl's 'opendir',
so it's equivalent to what I had before)
---
#!/usr/bin/perl -w
use strict;
use IO::Dir;
my $dir = new IO::Dir "/web/ShadNet/sys/cvs/webdocs";
print "Content-type: text/plain\n\n";
if ( defined($dir)) {
while (defined($_ = $dir-read)) {
print "[$_]\n";
}
}
undef $dir;
exit 0;
---
This works from the command line but not from Apache::Registry.
strace of seemingly-relevant bits via command line:
(this works)
---
munmap(0x40017000, 4096)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
open("/dev/null", O_RDONLY|O_NONBLOCK|0x1) = -1 ENOTDIR (Not a directory)
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
brk(0x81ca000) = 0x81ca000
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40017000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Content-type: text/plain\n", 25) = 25
write(1, "\n", 1) = 1
getdents(4, /* 43 entries */, 3391) = 936
write(1, "[.]\n", 4)= 4
write(1, "[..]\n", 5) = 5
write(1, "[CVS]\n", 6) = 6
write(1, "[accountclaim]\n", 15)= 15
write(1, "[AppletTag.pm]\n", 15)= 15
write(1, "[admin-login.mp]\n", 17) = 17
write(1, "[bugs.mp]\n", 10) = 10
write(1, "[bugs.mp.save]\n", 15)= 15
write(1, "[finger.mp]\n", 12) = 12
write(1, "[index.mp]\n", 11)= 11
write(1, "[login.mp]\n", 11)= 11
write(1, "[logout.html]\n", 14) = 14
write(1, "[logout.mp]\n", 12) = 12
write(1, "[menu.mp]\n", 10) = 10
write(1, "[motd.mp]\n", 10) = 10
write(1, "[msie.mp]\n", 10) = 10
write(1, "[newshad.mp]\n", 13) = 13
write(1, "[nph-changegroup.mp]\n", 21) = 21
write(1, "[nph-changelanguage.mp]\n", 24) = 24
write(1, "[nph-validate.mp]\n", 18) = 18
write(1, "[other.mp]\n", 11)= 11
write(1, "[page.mp]\n", 10) = 10
write(1, "[parsechangelog.mp]\n", 20) = 20
write(1, "[poll.mp]\n", 10) = 10
write(1, "[shadfont.css]\n", 15)= 15
write(1, "[shadnet.css]\n", 14) = 14
write(1, "[shownews.mp]\n", 14) = 14
write(1, "[admin]\n", 8)= 8
write(1, "[alumni]\n", 9) = 9
write(1, "[common]\n", 9) = 9
write(1, "[developers]\n", 13) = 13
write(1, "[development]\n", 14) = 14
write(1, "[online]\n", 9) = 9
write(1, "[partner]\n", 10) = 10
write(1, "[password]\n", 11)= 11
write(1, "[polls]\n", 8)= 8
write(1, "[static]\n", 9) = 9
write(1, "[util]\n", 7) = 7
write(1, "[classes]\n", 10) = 10
write(1, "[test-opendir.mp]\n", 18) = 18
write(1, "[test-opendir.mp~]\n", 19)= 19
write(1, "[foo.mp]\n", 9) = 9
write(1, "[foo.mp~]\n", 10) = 10
getdents(4, /* 0 entries */, 3391) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
close(4)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
munmap(0x40017000, 4096)= 0
_exit(0)= ?
---
strace of seemingly-relevant bits via Apache::Registry
(this doesn't work)
---
munmap(0x40018000, 4096)= 0
open("/dev/null", O_RDONLY|O_NONBLOCK|0x1) = -1 ENOTDIR (Not a directory)
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 5
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
brk(0x858d000) =
Re: open/opendir/readdir fail under latest perl/mod_perl/apache
On Mon, 11 Dec 2000, Richard Dice wrote:
It shouldn't be gigabytes -- you want to strace only special events like
open and read, and you want to attach to the process only before running
the script (run under -X) -- so you should have just a few lines!!!
% strace -p PID -e trace=open,read
I was talking about ltrace, not strace, when I said it would take gigs.
And even then, I was wrong -- it was only about 50mb. (And that didn't
take into account specifiying which events to trace on.)
Hmm, its manpage says : Its use is very similar to strace(1) but it's
irrelevant to the problem..
The only relevant bits are those where syscalls interact with the dir fd
more or less, so that's what's left:
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
brk(0x81ca000) = 0x81ca000
[snip interaction with STDOUT(fd=1)]
getdents(4, /* 43 entries */, 3391) = 936
fd==4, and we have 43 files and it's fine.
now the registry script which is broken:
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 5
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
brk(0x858d000) = 0x858d000
alarm(300) = 0
alarm(0)= 300
getdents(5, /* 43 entries */, 2980) = 936
all fine till now the same 43 entries are read, and the alarm(0) calls,
which appear on my system as well.
alarm(300) = 0
alarm(0)= 300
apparently 43 times...
What happens if you run the same code on the server with no preloaded
modules and configurations? Only the registry alias?
Obviously using IO::Dir won't help you to debug this problem but will make
it even more complicated.
Another thing to try: 'su - httpd' or whatever user you are running the
server under and now run the script from the command line. Since you
probably don't have the passwd for httpd do 'su' to become root first.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
