Now, AT experts are needed to mull over:1) why don't the error message show up in the error_log 2) is the enclosed patch a sufficient cure or does it rather hide a real problem (why is $ENV{PATH} undef in the first place) The strace output for that process starts with these lines: setsid() = 7719 close(0) = 0 open("/dev/null", O_RDONLY) = 0 close(1) = 0 open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 1 close(2) = 0 open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 2 stat("/opt/apache22-prefork/bin/suexec", 0x7fffb935fda0) = -1 ENOENT (No such file or directory) So the first question is answered. However I don't know if it is wise to redirect STDERR to /dev/null. The string "error_log" doesn't appear in combination with an open syscall in that trace.
yeah, I don't get that. digging in the recesses of my memory, I seem to recall errors on one of the initial two startup passes being swallowed, but it doesn't make sense if it's the first one since we see that all the time. maybe it's the second startup pass and the value being passed to untaint_path() is undef where it wasn't before? I'd be interested in recording all the values passed in and see if they match during start and restart.
as for your patch, it seems reasonable anyway, since there's no guarantee that the path isn't undef, and we certainly don't want to cause trouble. however, it falls within our style to remove the parens :)
return '' unless defined $path; --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
