You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/03/22 21:34:59 UTC
call_exec way bogus in win32
It tries to exec r->filename instead of argv0, which completely screws
mod_include and exec cmd, etc. When I change that, I get the whole server
hanging.
There is also some interplay here with the fact that the current code
changes directories, but a threaded server can't do that.
Re: call_exec way bogus in win32
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 22 Mar 1998, Ben Laurie wrote:
> Marc Slemko wrote:
> >
> > It tries to exec r->filename instead of argv0, which completely screws
> > mod_include and exec cmd, etc. When I change that, I get the whole server
> > hanging.
>
> Ugh.
>
> > There is also some interplay here with the fact that the current code
> > changes directories, but a threaded server can't do that.
>
> Surely it can, but you have to do some locking, right? Presumably once
> you've fired off the subprocess you can change dir again?
>
> Some CGIs assume that directory change has occurred, so you can't blow
> that behaviour away without some careful thought.
You have to change for CGIs, but that is easy to wrap (although lame)
because you can chdir right before and chdir back after.
If you take a look at mod_include... well... you see a slightly different
use of chdir.
Re: call_exec way bogus in win32
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> It tries to exec r->filename instead of argv0, which completely screws
> mod_include and exec cmd, etc. When I change that, I get the whole server
> hanging.
Ugh.
> There is also some interplay here with the fact that the current code
> changes directories, but a threaded server can't do that.
Surely it can, but you have to do some locking, right? Presumably once
you've fired off the subprocess you can change dir again?
Some CGIs assume that directory change has occurred, so you can't blow
that behaviour away without some careful thought.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: call_exec way bogus in win32
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Sun, 22 Mar 1998, Ben Laurie wrote:
>
> > Marc Slemko wrote:
> > >
> > > On Sun, 22 Mar 1998, Marc Slemko wrote:
> > >
> > > > It tries to exec r->filename instead of argv0, which completely screws
> > > > mod_include and exec cmd, etc. When I change that, I get the whole server
> > > > hanging.
> > > >
> > > > There is also some interplay here with the fact that the current code
> > > > changes directories, but a threaded server can't do that.
> > > >
> > >
> > > Ok, the below patch seems to fix that and make exec cmd work. It does
> > > not, however, work for programs without a path; eg. "foo.exe" will not
> > > work, but "/path/to/foo.exe" will.
> >
> > OK, but now I'm puzzled. You complain that it tries to exec r->filename.
> > But that's what the Unix version does, too. So why shouldn't it???
> >
> > At least, Unix does unless shellcmd is set. Win32 (and OS/2) pay no
> > attention to shellcmd. What gives?
>
> Oh yea, OS/2 is probably way broken too.
>
> The deal is that it just happens that mod_cgi only calls call_exec with
> shellcmd set. Using r->filename in Unix is bogus too, it just never ends
> up hurting anything.
OK ... so who calls it with shellcmd _not_ set? Why does mod_cgi set it?
This all sounds like a complete mess!
BTW, while we're talking about messes with CGIs, they can fail to be
launched for numerous reasons, but there are almost no diagnostics to
reveal why. It'd be nice to fix that one day. A particular problem is
when shortage of resources cause them to fail: finding out exactly what
resource one is short of is hard (OK, it pretty much has to be processes
or file handles, but figuring out that sodding csh reduces the process
limit to 64 when you only use bash [natch, someone else used csh and
restarted Apache] would've been greatly eased with some diagnostics).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: call_exec way bogus in win32
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 22 Mar 1998, Ben Laurie wrote:
> Marc Slemko wrote:
> >
> > On Sun, 22 Mar 1998, Marc Slemko wrote:
> >
> > > It tries to exec r->filename instead of argv0, which completely screws
> > > mod_include and exec cmd, etc. When I change that, I get the whole server
> > > hanging.
> > >
> > > There is also some interplay here with the fact that the current code
> > > changes directories, but a threaded server can't do that.
> > >
> >
> > Ok, the below patch seems to fix that and make exec cmd work. It does
> > not, however, work for programs without a path; eg. "foo.exe" will not
> > work, but "/path/to/foo.exe" will.
>
> OK, but now I'm puzzled. You complain that it tries to exec r->filename.
> But that's what the Unix version does, too. So why shouldn't it???
>
> At least, Unix does unless shellcmd is set. Win32 (and OS/2) pay no
> attention to shellcmd. What gives?
Oh yea, OS/2 is probably way broken too.
The deal is that it just happens that mod_cgi only calls call_exec with
shellcmd set. Using r->filename in Unix is bogus too, it just never ends
up hurting anything.
Re: call_exec way bogus in win32
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Sun, 22 Mar 1998, Marc Slemko wrote:
>
> > It tries to exec r->filename instead of argv0, which completely screws
> > mod_include and exec cmd, etc. When I change that, I get the whole server
> > hanging.
> >
> > There is also some interplay here with the fact that the current code
> > changes directories, but a threaded server can't do that.
> >
>
> Ok, the below patch seems to fix that and make exec cmd work. It does
> not, however, work for programs without a path; eg. "foo.exe" will not
> work, but "/path/to/foo.exe" will.
OK, but now I'm puzzled. You complain that it tries to exec r->filename.
But that's what the Unix version does, too. So why shouldn't it???
At least, Unix does unless shellcmd is set. Win32 (and OS/2) pay no
attention to shellcmd. What gives?
> exec cgi is still broken, but that is because it doesn't allow references
> to CGIs outside.
I don't understand what you mean.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: call_exec way bogus in win32
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 22 Mar 1998, Marc Slemko wrote:
> It tries to exec r->filename instead of argv0, which completely screws
> mod_include and exec cmd, etc. When I change that, I get the whole server
> hanging.
>
> There is also some interplay here with the fact that the current code
> changes directories, but a threaded server can't do that.
>
Ok, the below patch seems to fix that and make exec cmd work. It does
not, however, work for programs without a path; eg. "foo.exe" will not
work, but "/path/to/foo.exe" will.
exec cgi is still broken, but that is because it doesn't allow references
to CGIs outside.
I don't think this patch breaks anything, but YMMV...
Oh yea, why does StartServiceCtrlDispatcher take 20 seconds to
return? ie. run Apache without any arguments from the command
line, note how long it actually takes to start. Is that just because
you are half starting it as a service or something? '-s' works fine,
but is annoying to use all the time.
Index: main/util_script.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/main/util_script.c,v
retrieving revision 1.103
diff -u -r1.103 util_script.c
--- util_script.c 1998/03/14 00:50:39 1.103
+++ util_script.c 1998/03/22 21:12:10
@@ -721,11 +721,11 @@
interpreter[0] = 0;
- exename = strrchr(r->filename, '/');
+ exename = strrchr(argv0, '/');
if (!exename)
- exename = strrchr(r->filename, '\\');
+ exename = strrchr(argv0, '\\');
if (!exename)
- exename = r->filename;
+ exename = argv0;
else
exename++;
dot = strrchr(exename, '.');
@@ -737,16 +737,16 @@
}
if (!is_exe) {
- program = fopen(r->filename, "rb");
+ program = fopen(argv0, "rb");
if (!program) {
aplog_error(APLOG_MARK, APLOG_ERR, r->server,
- "fopen(%s) failed", r->filename);
+ "fopen(%s) failed", argv0);
return (pid);
}
sz = fread(interpreter, 1, sizeof(interpreter) - 1, program);
if (sz < 0) {
aplog_error(APLOG_MARK, APLOG_ERR, r->server,
- "fread of %s failed", r->filename);
+ "fread of %s failed", argv0);
fclose(program);
return (pid);
}
@@ -774,32 +774,32 @@
if ((!r->args) || (!r->args[0]) || strchr(r->args, '=')) {
if (is_exe || is_binary) {
- pid = spawnle(_P_NOWAIT, r->filename, r->filename, NULL, env);
+ pid = spawnle(_P_NOWAIT, argv0, argv0, NULL, env);
}
else if (is_script) {
pid = spawnle(_P_NOWAIT, interpreter + 2, interpreter + 2,
- r->filename, NULL, env);
+ argv0, NULL, env);
}
else {
pid = spawnle(_P_NOWAIT, "CMD.EXE", "CMD.EXE", "/C",
- r->filename, NULL, env);
+ argv0, NULL, env);
}
}
else {
if (is_exe || is_binary) {
- pid = spawnve(_P_NOWAIT, r->filename,
+ pid = spawnve(_P_NOWAIT, argv0,
create_argv(r->pool, NULL, NULL, NULL, argv0,
r->args), env);
}
else if (is_script) {
pid = spawnve(_P_NOWAIT, interpreter + 2,
create_argv(r->pool, interpreter + 2, NULL, NULL,
- r->filename, r->args), env);
+ argv0, r->args), env);
}
else {
pid = spawnve(_P_NOWAIT, "CMD.EXE",
create_argv_cmd(r->pool, argv0, r->args,
- r->filename), env);
+ argv0), env);
}
}
return (pid);