On Mon, 13 May 2002, Justin Erenkrantz wrote:
> Okay, I committed changes to both apr-config and apu-config so
> that they will always print the .la file information. -- justin
Thanks!!
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED
On Mon, May 13, 2002 at 10:54:55PM -0400, Cliff Woolley wrote:
> On Mon, 13 May 2002, Justin Erenkrantz wrote:
>
> > Hmm. We could modify apr-config to always print the la-file even
> > if it doesn't exist yet. Can you try this?
>
> That fixed it.
Okay, I committed changes to both apr-config
On Mon, 13 May 2002, Justin Erenkrantz wrote:
> Hmm. We could modify apr-config to always print the la-file even
> if it doesn't exist yet. Can you try this?
That fixed it.
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
C
On Mon, May 13, 2002 at 10:40:21PM -0400, Cliff Woolley wrote:
> On Mon, 13 May 2002, Justin Erenkrantz wrote:
>
> > > Justin, is this related to your recent commits?
> >
> > I don't think so, but what does your link line say? It looks like
> > apr isn't being linked in correctly. -- justin
>
On Mon, 13 May 2002, Justin Erenkrantz wrote:
> > Justin, is this related to your recent commits?
>
> I don't think so, but what does your link line say? It looks like
> apr isn't being linked in correctly. -- justin
Aww crap, I see what's happening. Because of the way it's finding -lapr
now,
On Mon, May 13, 2002 at 10:28:01PM -0400, Cliff Woolley wrote:
>
> /root/apache/httpd-2.0/support/htpasswd.c:409: undefined reference to
> `apr_app_initialize'
> /root/apache/httpd-2.0/support/htpasswd.c:414: undefined reference to
> `apr_pool_create_ex'
> /root/apache/httpd-2.0/srclib/apr-util/.
/root/apache/httpd-2.0/support/htpasswd.c:409: undefined reference to
`apr_app_initialize'
/root/apache/httpd-2.0/support/htpasswd.c:414: undefined reference to
`apr_pool_create_ex'
/root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined
reference to `apr_pstrmemdup'
/root/apache/ht
Outch... thanks.
Fortunately, that isn't the final file. I had finished the entire effort,
so I was
attempting to break the changes into components that could be followed,
bit by bit. It took a full day to break this overhaul into manageable,
modular
changes, sorry I missed that.
Fortunatel
On Mon, May 13, 2002 at 11:00:09PM -, [EMAIL PROTECTED] wrote:
> Index: http_main.c
> ===
> RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
> retrieving revision 1.580
> retrieving revision 1.581
> diff -u -r1.58
> the wrong pgrp later. So I think Aaron's right.
Ok - committed - please check that it matches people their consensus :-).
Dw
On Mon, May 13, 2002 at 09:23:13PM -, [EMAIL PROTECTED] wrote:
> wrowe 02/05/13 14:23:13
>
> Modified:modules/arch/win32 mod_isapi.c
> Log:
> Part two; nearly inconsequential - Made the log message prefix ISAPI:
> (rather than ISAPI with no trailing colon) and normalized
> What do you mean? At what point do we stop trying to detect errors
> and let the daemon go on its merry way?
Ideally once she says:
[Mon May 13 14:39:24 2002] [notice] Apache/1.3.25-dev (Unix) configured -- resuming
normal operations
which if I recall correctly is the moment after which you
> Of course the real patch is to make the exit codes always reliable - even
> when we fork and detach ;-)
What do you mean? At what point do we stop trying to detect errors
and let the daemon go on its merry way?
-aaron
> As long as you still do the fork(2) decision before the setsid(2) call,
> no. :)
Of course the real patch is to make the exit codes always reliable - even
when we fork and detach ;-)
Dw
Aaron Bannert <[EMAIL PROTECTED]> writes:
> Now that I think about it a little more, we should probably always
> exit if setsid() fails.
That sounds good. The only instance I can see setsid(2) legitimately
failing other than OS resource exhaustion or something is when you
invoke httpd -F interac
On Mon, 13 May 2002, Aaron Bannert wrote:
> On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote:
> > In that case I'd suggest we do
> >
> > if (setsid() fails)
> > always log error
> > exit(1) unless no_detach.
>
> should that be
> exit(1) if no_
> Note that I'm not sure if httpd 2.0 is this robust in handling
> setsid(2), so if we're spending the time on this and it's considered
> important for 1.3, someone should probably spend some time on making
> 2.0 as robust.
I improved the error detecting in 2.0 when originally adding Jos' patch
t
> > > if (setsid() fails)
> > > always log error
> > > exit(1) unless no_detach.
> >
> > should that be
> > exit(1) if no_detach
> > ? or do I have the logic backward?
>
> We should exit if setsid() fails and we don't want to detach (i.e.
> no_detach). If we don't e
On Mon, May 13, 2002 at 09:23:29PM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/05/13 14:23:29
>
> Modified:.configure.in
> Log:
> Instead of hardcoding srclib/apr{-util} in the INCLUDES, get the information
> from ap{ru}-config --includes which knows how to deal with V
Aaron Bannert <[EMAIL PROTECTED]> writes:
> I think we should just fail with an error if the user wished to start
> up under daemontools mode (no_detach mode) but somehow started httpd
> as a process group leader.
Concur.
> On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote:
> >
On Mon, May 13, 2002 at 03:23:54PM -0700, Aaron Bannert wrote:
> On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote:
> > In that case I'd suggest we do
> >
> > if (setsid() fails)
> > always log error
> > exit(1) unless no_detach.
>
> should that be
>
On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote:
> In that case I'd suggest we do
>
> if (setsid() fails)
> always log error
> exit(1) unless no_detach.
should that be
exit(1) if no_detach
? or do I have the logic backward?
-aaron
> OTOH, simply calling httpd from the command line (or exec'ing it from
> a shell script) will usually mean that the process is the leader of a
> new process group, meaning setsid() will fail.
I had not considered that mode of use - should we allow for that ? It
would propably make sense - seems
On Mon, May 13, 2002 at 03:04:01PM -0700, Aaron Bannert wrote:
> I think we should just fail with an error if the user wished to start
> up under daemontools mode (no_detach mode) but somehow started httpd
> as a process group leader.
That's a good idea ("Doctor, it hurts when I poke here." ...).
On Mon, May 13, 2002 at 02:50:34PM -0700, [EMAIL PROTECTED] wrote:
> > Hmm - not entirely trivial; it turns out that most unix-es do not take
> > kindly to
> >
> > setsid()
> >
> > when not detached/non-root. So I changed Jos/Michaels patch. See below.
> > Anyone any comments ?
>
> The other
On Mon, May 13, 2002 at 02:45:12PM -0700, [EMAIL PROTECTED] wrote:
>
> Hmm - not entirely trivial; it turns out that most unix-es do not take
> kindly to
>
> setsid()
>
> when not detached/non-root. So I changed Jos/Michaels patch. See below.
> Anyone any comments ?
Which platforms disal
On Mon, 13 May 2002, Justin Erenkrantz wrote:
> Unified diff, please. =) My brain can't parse that style of
> diffs. -- justin
Hmm - sorry - blame MacOS-X - somehow unified diffs break. Here is one
from a BSD box:
Dw
Index: src/CHANGES
==
> Hmm - not entirely trivial; it turns out that most unix-es do not take
> kindly to
>
> setsid()
>
> when not detached/non-root. So I changed Jos/Michaels patch. See below.
> Anyone any comments ?
The other obvious way is to make the error non fatal or do a (!geteuid())
to see if we are
Hmm - not entirely trivial; it turns out that most unix-es do not take
kindly to
setsid()
when not detached/non-root. So I changed Jos/Michaels patch. See below.
Anyone any comments ?
Dw
Index: CHANGES
===
RCS file: /home
Ok - massaged the right patch in - works perfectly on MacOS X. Testing
further.
Dw.
--
Dirk-Willem van Gulik
On Mon, 13 May 2002, Jim Jagielski wrote:
> Jim Jagielski wrote:
> >
> > At 12:25 PM -0701 5/13/02, Jos Backus wrote:
> > >Anyone interested in picking this up before the next (last?)
> http://www.catnook.com/patches/apache-1.3.24-daemontools.patch
>
> is valid. To the point, however, the bug says to simply place in
> ./patches, but I'm wondering whether we should just fold it into
> the official source. That's what I'm leaning towards... Any complaints
> if, after review and
On Mon, May 13, 2002 at 01:29:23PM -0700, Aaron Bannert wrote:
> On Mon, May 13, 2002 at 12:25:39PM -0701, Jos Backus wrote:
> > Anyone interested in picking this up before the next (last?) 1.3 release?
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
>
> I would like to see th
Jim Jagielski wrote:
>
> At 12:25 PM -0701 5/13/02, Jos Backus wrote:
> >Anyone interested in picking this up before the next (last?) 1.3 release?
> >
> >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
> >
> >Please? Thanks!
> >
>
> The URL in the bug report
>(http://lizzy.dyndns.org
At 12:25 PM -0701 5/13/02, Jos Backus wrote:
>Anyone interested in picking this up before the next (last?) 1.3 release?
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
>
>Please? Thanks!
>
The URL in the bug report
(http://lizzy.dyndns.org/~jos/apache-1.3.24-daemontools.patch)
app
On Mon, May 13, 2002 at 12:25:39PM -0701, Jos Backus wrote:
> Anyone interested in picking this up before the next (last?) 1.3 release?
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
I would like to see this go in to 1.3. I will volunteer my time to see
that this happens (the pat
Anyone interested in picking this up before the next (last?) 1.3 release?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628
Please? Thanks!
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
Stipe Tolj wrote:
>
> David Reid wrote:
> >
> > What about fixing build issues?
> >
> > ab is currently broken on non writev and non ssl platforms (though I have
> > Dirk's patch applied and it correct the issue) and I have one other small
> > patch I'd like to finish and then apply to allow a
David Reid wrote:
>
> What about fixing build issues?
>
> ab is currently broken on non writev and non ssl platforms (though I have
> Dirk's patch applied and it correct the issue) and I have one other small
> patch I'd like to finish and then apply to allow a build for beos to
> complete...
>
The PR was written for nph CGIs but it appears that any server push
CGI is broken.
Apparently, core_output_filter() would need to switch between
non-blocking and blocking bucket reads (and flush the output
in-between) to get this to work.
For non-nph server push CGIs to work, other filters which
On Mon, May 13, 2002 at 01:58:38PM +0200, Kraemer, Martin wrote:
> @@ -1045,12 +1045,26 @@
> r->assbackwards = (ll[0] == '\0');
> r->protocol = ap_pstrdup(r->pool, ll[0] ? ll : "HTTP/0.9");
>
> -if (2 == sscanf(r->protocol, "HTTP/%u.%u", &major, &minor)
> +if (3 == sscanf(r->pr
Okay, once again _with_ patch:
We have been discussing this topic in the past: a stricter check
should be applied to the request line, in order to prevent arbitrary
user input to end up in the access_log and error_log. It could be
misused to spoof accesses to nonexistent (or inaccessible) resourc
We have been discussing this topic in the past: a stricter check
should be applied to the request line, in order to prevent arbitrary
user input to end up in the access_log and error_log. It could be
misused to spoof accesses to nonexistent (or inaccessible) resources,
of course without the client
I noticed that the DEFAULT_XFERLOG macro definition is
supplied but not used anywhere in apache_1.3.
The only place where we use the definition is in "httpd -V"
where we print its setting.
% find . -type f | xargs grep -i DEFAULT_XFERLOG
./src/main/http_main.c:#ifdef DEFAULT_XFERLOG
./src/main/h
On Mon, May 13, 2002 at 06:47:00AM -0400, Jeff Trawick wrote:
> crypt() is fine if it uses thread-specific storage (like Solaris,
> OS/390, HP-UX); that's a better fix than adding crypt_r() since old
Are there any BSD-licensed sources that uses thread-specific
storage for crypt() that we can (att
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Fri, May 10, 2002 at 04:41:52PM -0400, Jeff Trawick wrote:
> > ...on Linux and AIX and perhaps some other platforms with a threaded
> > MPM and crypt() passwords. I saw it myself on AIX before teaching APR
> > to use crypt_r(). Somebody else at
45 matches
Mail list logo
