Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
Hi Jim,
for me/us it's needed, because we operate with multi-instancing.
e.g.:
Apache installation directory ("ServerRoot") is /opt/http-2.4.x/
(belonging to apache:apache). This installation only provides the
httpd binaries/modules.
Users on this server configure their own apache insances:
(user1:group1)
/var/www/project1/
\==> logs/ (error/access/pid/mutex)
\==> htdocs/ (content)
\==> config/ (httpd.conf, includes, etc.)
(user2:group2)
/var/www/project2/
\==> logs/
\==> htdocs/
\==> config/
(user3:group3)
/var/www/project3/
\==> logs/
\==> htdocs/
\==> config/
So a customizable slotmem-shm file would make sense in
this scenario.
Regards,
Zisis
- Original Message -
From: "Jim Jagielski"
To: dev@httpd.apache.org
Sent: Tuesday, March 6, 2012 7:26:19 PM
Subject: Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
My plan is 2 pronged... to see if r1297560 is enough and if
allowing a slotmem override is even needed (or wanted) ... ;)
On Mar 6, 2012, at 12:35 PM, Zisis Lianas wrote:
> Thanks Jim, that works fine for the default-rel-runtimedir configuration.
> Slotmem file is created as /logs/slotmem-shm-s.shm.
>
> Now if also the slotmem-file-target-location directive gets available,
> this thread is done for me.
>
>
> Regards,
> Zisis
>
> - Original Message -
> From: "Jim Jagielski"
> To: dev@httpd.apache.org
> Sent: Tuesday, March 6, 2012 5:21:22 PM
> Subject: Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
>
> http://svn.apache.org/viewvc?rev=1297560&view=rev
>
> On Mar 6, 2012, at 10:39 AM, Jeff Trawick wrote:
>
>> On Tue, Mar 6, 2012 at 10:33 AM, Jim Jagielski wrote:
>>> Yeah, that seems better, ala ./modules/cache/mod_socache_dbm.c
>>
>> On behalf of anyone else reading this thread, here's the idiom from
>> mod_socache_dbm.c:
>>
>> #define DEFAULT_DBM_PREFIX DEFAULT_REL_RUNTIMEDIR "/socache-dbm-"
>> ...
>> const char *path = apr_pstrcat(p, DEFAULT_DBM_PREFIX, namespace,
>> NULL);
>>
>> ctx->data_file = ap_server_root_relative(p, path);
>>
>>
>>>
>>> On Mar 6, 2012, at 8:36 AM, Jeff Trawick wrote:
>>>
On Tue, Mar 6, 2012 at 7:56 AM, Jim Jagielski wrote:
> OK... What I'll do is add a directive which provides a
> "default" location for slotmem file...
Uhh, that seems as endless as per-mutex directives.
Is slotmem not using DEFAULT_REL_RUNTIMEDIR already? (not perfect,
but a good start)
Directive to specify runtime directory (API returns serverroot +
DEFAULT_REL_RUNTIMEDIR if not configured).
Directive like Mutex but for shmem?
>>>
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>>
>
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
[snip] > So to sum up: all uses of DEFAULT_REL_RUNTIMEDIR I can see at the > moment > are overwritable by configuration. A runtime configurable runtime > directory would not be a critical feature but make it easy to move > all > these objects in a common directory not known at build time. [snip] This is such a common use-case that it would make a lot of sense to provide such a directive. See next mail in this thread for a reference. i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
On Wed, Mar 7, 2012 at 9:39 AM, Zisis Lianas wrote:
> Hi Jim,
>
> for me/us it's needed, because we operate with multi-instancing.
>
> e.g.:
> Apache installation directory ("ServerRoot") is /opt/http-2.4.x/
> (belonging to apache:apache). This installation only provides the
> httpd binaries/modules.
>
ServerRoot does not have to be the directory above {bin,libexec,sbin}.
It should be the directory above {conf,logs}.
When running in this scenario, you do have to have absolute paths to
your apache modules, eg:
LoadModule status_module /usr/local/libexec/apache22/mod_status.so
rather than:
LoadModule status_module libexec/apache22/mod_status.so
The disadvantage of doing it this way is that you have to specify full
paths to all your modules. The disadvantage of doing it your way is
that your ServerRoot is not your ServerRoot...
Cheers
Tom
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
- Original Message -
> On Wed, Mar 7, 2012 at 9:39 AM, Zisis Lianas
> wrote:
> > Hi Jim,
> >
> > for me/us it's needed, because we operate with multi-instancing.
> >
> > e.g.:
> > Apache installation directory ("ServerRoot") is /opt/http-2.4.x/
> > (belonging to apache:apache). This installation only provides the
> > httpd binaries/modules.
> >
>
> ServerRoot does not have to be the directory above
> {bin,libexec,sbin}.
> It should be the directory above {conf,logs}.
>
> When running in this scenario, you do have to have absolute paths to
> your apache modules, eg:
>
> LoadModule status_module /usr/local/libexec/apache22/mod_status.so
>
> rather than:
>
> LoadModule status_module libexec/apache22/mod_status.so
>
> The disadvantage of doing it this way is that you have to specify
> full
> paths to all your modules. The disadvantage of doing it your way is
> that your ServerRoot is not your ServerRoot...
I think this is exactly the point.
You wouldn't want to give up this kind of convenience.
Ideally, you'd like to keep both.
The only reason I can think of providing different versions of
binaries would be to provide a different suexec. But overall it
sounds like overkill - same with modules.
> Cheers
>
> Tom
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: log-message-tags
Ahh... great. Thx. I'll go ahead and put some docs in the repo where they belong. On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote: > hi Jim, > > On 07.03.2012 00:24, Jim Jagielski wrote: >> Oh yeah... and how do we worry about keeping things in sync. For >> example, right now trunk uses 02298 and 02299, but 2.4 does not. >> When another log entry is added to 2.4, do we use these or skip >> these??? >> >> On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote: >> >>> Hmmm... anyone else noticing that the httpd-2.4 branch is lacking >>> the docs/log-message-tags/ dir? > > I asked the question in the "Questions" thread end of January: > > >> 2) log tags > >> === > >> > >> r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 > >> lines Add APLOGNO() macro for unique tags for every log message. > >> Add some scripts to make adding these tags easier. > >> > >> This has only been backported partially. The directory > >> docs/log-message-tags is mising in 2.4.x as well as the > >> update-log-tags and update-log-msg-tags targets in Makefile. > > Stefan answered on Jan. 31st: > > > This is intentional and not for backport. The log tags should be > > consistent between trunk and the branches, so there can be only one > > "docs/log-message-tags/next-number" file, and that resides in trunk. > > That means if an error message is introduced in 2.4 but not in trunk, > > the next-number file in trunk should be updated. > > > > But there should probably be a docs/log-message-tags/README file in > > 2.4 that explains this. I will write something when I have time. But > > as a non-code change, this is not that urgent. > > Regards, > > Rainer >
SVN question (Was: Re: log-message-tags)
A question for SVN experts: can we create an export or something like that that puts the trunk version of docs/log-message-tags/ in the 2.4 branch, so that there exists only 1 canonical version and it lives in trunk but is "referred" to in the 2.4 branch? On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote: > hi Jim, > > On 07.03.2012 00:24, Jim Jagielski wrote: >> Oh yeah... and how do we worry about keeping things in sync. For >> example, right now trunk uses 02298 and 02299, but 2.4 does not. >> When another log entry is added to 2.4, do we use these or skip >> these??? >> >> On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote: >> >>> Hmmm... anyone else noticing that the httpd-2.4 branch is lacking >>> the docs/log-message-tags/ dir? > > I asked the question in the "Questions" thread end of January: > > >> 2) log tags > >> === > >> > >> r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 > >> lines Add APLOGNO() macro for unique tags for every log message. > >> Add some scripts to make adding these tags easier. > >> > >> This has only been backported partially. The directory > >> docs/log-message-tags is mising in 2.4.x as well as the > >> update-log-tags and update-log-msg-tags targets in Makefile. > > Stefan answered on Jan. 31st: > > > This is intentional and not for backport. The log tags should be > > consistent between trunk and the branches, so there can be only one > > "docs/log-message-tags/next-number" file, and that resides in trunk. > > That means if an error message is introduced in 2.4 but not in trunk, > > the next-number file in trunk should be updated. > > > > But there should probably be a docs/log-message-tags/README file in > > 2.4 that explains this. I will write something when I have time. But > > as a non-code change, this is not that urgent. > > Regards, > > Rainer >
Re: SVN question (Was: Re: log-message-tags)
On 07 Mar 2012, at 1:27 PM, Jim Jagielski wrote: > A question for SVN experts: can we create an export or something like > that that puts the trunk version of docs/log-message-tags/ in > the 2.4 branch, so that there exists only 1 canonical version > and it lives in trunk but is "referred" to in the 2.4 branch? Would we ever use this on the v2.4 branch at all? In theory, nothing should hit v2.4 that isn't already on trunk, and a log message in v2.4 should definitely mirror the same log message in trunk. If I'm understanding this correctly, we're worrying about something that should in theory never be used. Ideally we just need a README of some kind to indicate briefly how it works, and to look in trunk. We shouldn't encourage v2.4 having messages of it's own. Regards, Graham --
Re: SVN question (Was: Re: log-message-tags)
Never mind, I hope I did it correctly :) % cat la log-message-tags https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/log-message-tags % pwd blahblah.../dev/httpd-2.4/docs % svn propset svn:externals . -F la property 'svn:externals' set on '.' % svn up Fetching external item into 'log-message-tags': Alog-message-tags/update-log-msg-tags Alog-message-tags/find-messages.cocci Alog-message-tags/next-number Alog-message-tags/macros.h Alog-message-tags/README Updated external to revision 1297944. On Mar 7, 2012, at 6:27 AM, Jim Jagielski wrote: > A question for SVN experts: can we create an export or something like > that that puts the trunk version of docs/log-message-tags/ in > the 2.4 branch, so that there exists only 1 canonical version > and it lives in trunk but is "referred" to in the 2.4 branch? > On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote: > >> hi Jim, >> >> On 07.03.2012 00:24, Jim Jagielski wrote: >>> Oh yeah... and how do we worry about keeping things in sync. For >>> example, right now trunk uses 02298 and 02299, but 2.4 does not. >>> When another log entry is added to 2.4, do we use these or skip >>> these??? >>> >>> On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote: >>> Hmmm... anyone else noticing that the httpd-2.4 branch is lacking the docs/log-message-tags/ dir? >> >> I asked the question in the "Questions" thread end of January: >> 2) log tags === r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 lines Add APLOGNO() macro for unique tags for every log message. Add some scripts to make adding these tags easier. This has only been backported partially. The directory docs/log-message-tags is mising in 2.4.x as well as the update-log-tags and update-log-msg-tags targets in Makefile. >> >> Stefan answered on Jan. 31st: >> >>> This is intentional and not for backport. The log tags should be >>> consistent between trunk and the branches, so there can be only one >>> "docs/log-message-tags/next-number" file, and that resides in trunk. >>> That means if an error message is introduced in 2.4 but not in trunk, >>> the next-number file in trunk should be updated. >>> >>> But there should probably be a docs/log-message-tags/README file in >>> 2.4 that explains this. I will write something when I have time. But >>> as a non-code change, this is not that urgent. >> >> Regards, >> >> Rainer >> >
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
I'll work on it... I already have a version for slotmem, but a generic solution it best, I agree. But what do we call it? DefaultDir? On Mar 7, 2012, at 5:17 AM, Igor Galić wrote: > > [snip] >> So to sum up: all uses of DEFAULT_REL_RUNTIMEDIR I can see at the >> moment >> are overwritable by configuration. A runtime configurable runtime >> directory would not be a critical feature but make it easy to move >> all >> these objects in a common directory not known at build time. > [snip] > > This is such a common use-case that it would make a lot of sense > to provide such a directive. > > See next mail in this thread for a reference. > > i > > -- > Igor Galić > > Tel: +43 (0) 664 886 22 883 > Mail: i.ga...@brainsware.org > URL: http://brainsware.org/ > GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE >
Re: SVN question (Was: Re: log-message-tags)
svn:externals is only a client-side mechanism. This will not bring log-message-tags/ into the branch, and especially not within the tag. In essence, you will not be able to recreate any specific state in time (or a release!) because of this. The repository doesn't actually reflect the state that you're trying to capture. You could construct a tarball for 2.4.x, but a week later, that tarball cannot be reconstructed. The checksums will not match. etc. My suggestion would be to add a step to the T&R instructions to do a merge from trunk over to the branch before processing a release. Thus, the branch will get a snapshot of the log-message-tags at the time of release. Cheers, -g On Wed, Mar 7, 2012 at 06:33, Jim Jagielski wrote: > Never mind, I hope I did it correctly :) > > % cat la > log-message-tags > https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/log-message-tags > % pwd > blahblah.../dev/httpd-2.4/docs > % svn propset svn:externals . -F la > property 'svn:externals' set on '.' > % svn up > Fetching external item into 'log-message-tags': > A log-message-tags/update-log-msg-tags > A log-message-tags/find-messages.cocci > A log-message-tags/next-number > A log-message-tags/macros.h > A log-message-tags/README > Updated external to revision 1297944. > > > On Mar 7, 2012, at 6:27 AM, Jim Jagielski wrote: > >> A question for SVN experts: can we create an export or something like >> that that puts the trunk version of docs/log-message-tags/ in >> the 2.4 branch, so that there exists only 1 canonical version >> and it lives in trunk but is "referred" to in the 2.4 branch? >> On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote: >> >>> hi Jim, >>> >>> On 07.03.2012 00:24, Jim Jagielski wrote: Oh yeah... and how do we worry about keeping things in sync. For example, right now trunk uses 02298 and 02299, but 2.4 does not. When another log entry is added to 2.4, do we use these or skip these??? On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote: > Hmmm... anyone else noticing that the httpd-2.4 branch is lacking > the docs/log-message-tags/ dir? >>> >>> I asked the question in the "Questions" thread end of January: >>> > 2) log tags > === > > r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | 3 > lines Add APLOGNO() macro for unique tags for every log message. > Add some scripts to make adding these tags easier. > > This has only been backported partially. The directory > docs/log-message-tags is mising in 2.4.x as well as the > update-log-tags and update-log-msg-tags targets in Makefile. >>> >>> Stefan answered on Jan. 31st: >>> This is intentional and not for backport. The log tags should be consistent between trunk and the branches, so there can be only one "docs/log-message-tags/next-number" file, and that resides in trunk. That means if an error message is introduced in 2.4 but not in trunk, the next-number file in trunk should be updated. But there should probably be a docs/log-message-tags/README file in 2.4 that explains this. I will write something when I have time. But as a non-code change, this is not that urgent. >>> >>> Regards, >>> >>> Rainer >>> >> >
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
I agree that ServerRoot should not be touched or changed, but
it begs the question how do we differentiate between what
is ServerRoot relative and what is DefaultRuntimeDir ?
I guess docs that mention what modules use DefaultRuntimeDir is
sufficient? Or maybe we just call it something like SafeWriteDir
that says we know that httpd can write to this dir... Or to
make it clear that we're talking transitory files, something like
TempDir or ScratchSpace ??
On Mar 7, 2012, at 5:50 AM, Igor Galić wrote:
>
>
> - Original Message -
>> On Wed, Mar 7, 2012 at 9:39 AM, Zisis Lianas
>> wrote:
>>> Hi Jim,
>>>
>>> for me/us it's needed, because we operate with multi-instancing.
>>>
>>> e.g.:
>>> Apache installation directory ("ServerRoot") is /opt/http-2.4.x/
>>> (belonging to apache:apache). This installation only provides the
>>> httpd binaries/modules.
>>>
>>
>> ServerRoot does not have to be the directory above
>> {bin,libexec,sbin}.
>> It should be the directory above {conf,logs}.
>>
>> When running in this scenario, you do have to have absolute paths to
>> your apache modules, eg:
>>
>> LoadModule status_module /usr/local/libexec/apache22/mod_status.so
>>
>> rather than:
>>
>> LoadModule status_module libexec/apache22/mod_status.so
>>
>> The disadvantage of doing it this way is that you have to specify
>> full
>> paths to all your modules. The disadvantage of doing it your way is
>> that your ServerRoot is not your ServerRoot...
>
> I think this is exactly the point.
> You wouldn't want to give up this kind of convenience.
> Ideally, you'd like to keep both.
>
> The only reason I can think of providing different versions of
> binaries would be to provide a different suexec. But overall it
> sounds like overkill - same with modules.
>
>> Cheers
>>
>> Tom
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.ga...@brainsware.org
> URL: http://brainsware.org/
> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
>
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
- Original Message - > I agree that ServerRoot should not be touched or changed, but > it begs the question how do we differentiate between what > is ServerRoot relative and what is DefaultRuntimeDir ? > > I guess docs that mention what modules use DefaultRuntimeDir is > sufficient? Or maybe we just call it something like SafeWriteDir > that says we know that httpd can write to this dir... Or to > make it clear that we're talking transitory files, something like > TempDir or ScratchSpace ?? I knew this is going to be my favourite part of this discussion ;) So far, DefaultRuntimeDir sounds most reasonable (to me) i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: SVN question (Was: Re: log-message-tags)
- Original Message - > svn:externals is only a client-side mechanism. This will not bring > log-message-tags/ into the branch, and especially not within the tag. > > In essence, you will not be able to recreate any specific state in > time (or a release!) because of this. The repository doesn't actually > reflect the state that you're trying to capture. > > You could construct a tarball for 2.4.x, but a week later, that > tarball cannot be reconstructed. The checksums will not match. etc. Huh? svn externals can reference a specific revision. > My suggestion would be to add a step to the T&R instructions to do a > merge from trunk over to the branch before processing a release. > Thus, > the branch will get a snapshot of the log-message-tags at the time of > release. > > Cheers, > -g > > On Wed, Mar 7, 2012 at 06:33, Jim Jagielski wrote: > > Never mind, I hope I did it correctly :) > > > > % cat la > > log-message-tags > > https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/log-message-tags > > % pwd > > blahblah.../dev/httpd-2.4/docs > > % svn propset svn:externals . -F la > > property 'svn:externals' set on '.' > > % svn up > > Fetching external item into 'log-message-tags': > > A log-message-tags/update-log-msg-tags > > A log-message-tags/find-messages.cocci > > A log-message-tags/next-number > > A log-message-tags/macros.h > > A log-message-tags/README > > Updated external to revision 1297944. > > > > > > On Mar 7, 2012, at 6:27 AM, Jim Jagielski wrote: > > > >> A question for SVN experts: can we create an export or something > >> like > >> that that puts the trunk version of docs/log-message-tags/ in > >> the 2.4 branch, so that there exists only 1 canonical version > >> and it lives in trunk but is "referred" to in the 2.4 branch? > >> On Mar 6, 2012, at 7:43 PM, Rainer Jung wrote: > >> > >>> hi Jim, > >>> > >>> On 07.03.2012 00:24, Jim Jagielski wrote: > Oh yeah... and how do we worry about keeping things in sync. For > example, right now trunk uses 02298 and 02299, but 2.4 does not. > When another log entry is added to 2.4, do we use these or skip > these??? > > On Mar 6, 2012, at 6:21 PM, Jim Jagielski wrote: > > > Hmmm... anyone else noticing that the httpd-2.4 branch is > > lacking > > the docs/log-message-tags/ dir? > >>> > >>> I asked the question in the "Questions" thread end of January: > >>> > > 2) log tags > > === > > > > r1209743 | sf | 2011-12-02 23:26:54 +0100 (Fri, 02 Dec 2011) | > > 3 > > lines Add APLOGNO() macro for unique tags for every log > > message. > > Add some scripts to make adding these tags easier. > > > > This has only been backported partially. The directory > > docs/log-message-tags is mising in 2.4.x as well as the > > update-log-tags and update-log-msg-tags targets in Makefile. > >>> > >>> Stefan answered on Jan. 31st: > >>> > This is intentional and not for backport. The log tags should be > consistent between trunk and the branches, so there can be only > one > "docs/log-message-tags/next-number" file, and that resides in > trunk. > That means if an error message is introduced in 2.4 but not in > trunk, > the next-number file in trunk should be updated. > > But there should probably be a docs/log-message-tags/README file > in > 2.4 that explains this. I will write something when I have time. > But > as a non-code change, this is not that urgent. > >>> > >>> Regards, > >>> > >>> Rainer > >>> > >> > > > -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: SVN question (Was: Re: log-message-tags)
2012/3/7 Igor Galić : > > > - Original Message - >> svn:externals is only a client-side mechanism. This will not bring >> log-message-tags/ into the branch, and especially not within the tag. >> >> In essence, you will not be able to recreate any specific state in >> time (or a release!) because of this. The repository doesn't actually >> reflect the state that you're trying to capture. >> >> You could construct a tarball for 2.4.x, but a week later, that >> tarball cannot be reconstructed. The checksums will not match. etc. > > Huh? > > svn externals can reference a specific revision. With recent versions of Subversion, sure. But regardless, look at Jim's copy/paste. There is no pegged revision. Cheers, -g
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
On Wed, Mar 7, 2012 at 6:37 AM, Jim Jagielski wrote: > I'll work on it... I already have a version for slotmem, but > a generic solution it best, I agree. But what do we call it? > DefaultDir? As I mentioned yesterday, I have thrown together the code for the API and directive and need to test it. > > On Mar 7, 2012, at 5:17 AM, Igor Galić wrote: > >> >> [snip] >>> So to sum up: all uses of DEFAULT_REL_RUNTIMEDIR I can see at the >>> moment >>> are overwritable by configuration. A runtime configurable runtime >>> directory would not be a critical feature but make it easy to move >>> all >>> these objects in a common directory not known at build time. >> [snip] >> >> This is such a common use-case that it would make a lot of sense >> to provide such a directive. >> >> See next mail in this thread for a reference. >> >> i >> >> -- >> Igor Galić >> >> Tel: +43 (0) 664 886 22 883 >> Mail: i.ga...@brainsware.org >> URL: http://brainsware.org/ >> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE >> > -- Born in Roswell... married an alien...
Re: SVN question (Was: Re: log-message-tags)
On Mar 7, 2012, at 6:32 AM, Graham Leggett wrote: > On 07 Mar 2012, at 1:27 PM, Jim Jagielski wrote: > >> A question for SVN experts: can we create an export or something like >> that that puts the trunk version of docs/log-message-tags/ in >> the 2.4 branch, so that there exists only 1 canonical version >> and it lives in trunk but is "referred" to in the 2.4 branch? > > Would we ever use this on the v2.4 branch at all? > Sure... assume a case with 2.4.10 and trunk has changed enough that to fix a bug in 2.4.10, there is no direct backport, but rather a one-off. I don't feel strongly one way or another but the previous situation was untenable.
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
2012/3/7 Igor Galić : > I knew this is going to be my favourite part of this discussion ;) > > So far, DefaultRuntimeDir sounds most reasonable (to me) > I'd like it green! But seriously, doesn't this directive change the runtime directory from the default to something not the default? In which case, a simple "RuntimeDir" may be better? Cheers Tom
Re: SVN question (Was: Re: log-message-tags)
On Mar 7, 2012, at 6:40 AM, Greg Stein wrote: > svn:externals is only a client-side mechanism. This will not bring > log-message-tags/ into the branch, and especially not within the tag. > Which is fine... docs/log-message-tags isn't part of the releasable data for a branch anyway. It's a developer artifact only.
Re: SVN question (Was: Re: log-message-tags)
On Wed, Mar 7, 2012 at 06:59, Jim Jagielski wrote: > > On Mar 7, 2012, at 6:40 AM, Greg Stein wrote: > >> svn:externals is only a client-side mechanism. This will not bring >> log-message-tags/ into the branch, and especially not within the tag. >> > > Which is fine... docs/log-message-tags isn't part of the > releasable data for a branch anyway. It's a developer artifact > only. Ah! Then the externals solution is Just Fine! Cheers, -g
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
Yeah, it's pretty ez actually... ap_scratch_space (or whatever) which is an extern. And then the changes from DEFAULT_REL_RUNTIMEDIR to ap_scratch_space except for the initial setting of ap_scratch_space to it. Some places will need a strcat instead of using cpp string concat, but not too bad at all... On Mar 7, 2012, at 6:54 AM, Jeff Trawick wrote: > On Wed, Mar 7, 2012 at 6:37 AM, Jim Jagielski wrote: >> I'll work on it... I already have a version for slotmem, but >> a generic solution it best, I agree. But what do we call it? >> DefaultDir? > > As I mentioned yesterday, I have thrown together the code for the API > and directive and need to test it. > > >> >> On Mar 7, 2012, at 5:17 AM, Igor Galić wrote: >> >>> >>> [snip] So to sum up: all uses of DEFAULT_REL_RUNTIMEDIR I can see at the moment are overwritable by configuration. A runtime configurable runtime directory would not be a critical feature but make it easy to move all these objects in a common directory not known at build time. >>> [snip] >>> >>> This is such a common use-case that it would make a lot of sense >>> to provide such a directive. >>> >>> See next mail in this thread for a reference. >>> >>> i >>> >>> -- >>> Igor Galić >>> >>> Tel: +43 (0) 664 886 22 883 >>> Mail: i.ga...@brainsware.org >>> URL: http://brainsware.org/ >>> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE >>> >> > > > > -- > Born in Roswell... married an alien... >
Re: httpd 2.4.1 and mod_slotmem_shm / mod_proxy_balancer (AH01179)
On Wed, Mar 7, 2012 at 6:59 AM, Tom Evans wrote: > 2012/3/7 Igor Galić : >> I knew this is going to be my favourite part of this discussion ;) >> >> So far, DefaultRuntimeDir sounds most reasonable (to me) That's what I have (along with ap_runtime_dir_relative()). >> > > I'd like it green! But seriously, doesn't this directive change the > runtime directory from the default to something not the default? In > which case, a simple "RuntimeDir" may be better? > > Cheers > > Tom -- Born in Roswell... married an alien...
[PATCH] DefaultRuntimeDir, ap_runtime_dir_relative()
barely tested
--
Born in Roswell... married an alien...
Index: server/config.c
===
--- server/config.c (revision 1297483)
+++ server/config.c (working copy)
@@ -59,6 +59,7 @@
AP_DECLARE_DATA const char *ap_server_argv0 = NULL;
AP_DECLARE_DATA const char *ap_server_root = NULL;
+AP_DECLARE_DATA const char *ap_runtime_dir = NULL;
AP_DECLARE_DATA server_rec *ap_server_conf = NULL;
AP_DECLARE_DATA apr_pool_t *ap_pglobal = NULL;
@@ -1560,6 +1561,25 @@
}
}
+AP_DECLARE(char *) ap_runtime_dir_relative(apr_pool_t *p, const char *file)
+{
+char *newpath = NULL;
+apr_status_t rv;
+const char *runtime_dir = ap_runtime_dir ? ap_runtime_dir :
ap_server_root_relative(p, DEFAULT_REL_RUNTIMEDIR);
+
+rv = apr_filepath_merge(&newpath, runtime_dir, file,
+APR_FILEPATH_TRUENAME, p);
+if (newpath && (rv == APR_SUCCESS || APR_STATUS_IS_EPATHWILD(rv)
+ || APR_STATUS_IS_ENOENT(rv)
+ || APR_STATUS_IS_ENOTDIR(rv))) {
+return newpath;
+}
+else {
+return NULL;
+}
+}
+
+
AP_DECLARE(const char *) ap_soak_end_container(cmd_parms *cmd, char *directive)
{
struct ap_varbuf vb;
Index: server/core.c
===
--- server/core.c (revision 1297483)
+++ server/core.c (working copy)
@@ -2775,6 +2775,24 @@
return NULL;
}
+static const char *set_runtime_dir(cmd_parms *cmd, void *dummy, const char
*arg)
+{
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
+if ((apr_filepath_merge((char**)&ap_runtime_dir, NULL,
+ap_server_root_relative(cmd->pool, arg),
+APR_FILEPATH_TRUENAME, cmd->pool) != APR_SUCCESS)
+|| !ap_is_directory(cmd->temp_pool, ap_runtime_dir)) {
+return "DefaultRuntimeDir must be a valid directory, absolute or
relative to ServerRoot";
+}
+
+return NULL;
+}
+
static const char *set_timeout(cmd_parms *cmd, void *dummy, const char *arg)
{
const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE);
@@ -3928,6 +3946,8 @@
"En-/disable server signature (on|off|email)"),
AP_INIT_TAKE1("ServerRoot", set_server_root, NULL, RSRC_CONF | EXEC_ON_READ,
"Common directory of server-related files (logs, confs, etc.)"),
+AP_INIT_TAKE1("DefaultRuntimeDir", set_runtime_dir, NULL, RSRC_CONF |
EXEC_ON_READ,
+ "Common directory for run-time files (shared memory, locks, etc.)"),
AP_INIT_TAKE1("ErrorLog", set_server_string_slot,
(void *)APR_OFFSETOF(server_rec, error_fname), RSRC_CONF,
"The filename of the error log"),
Index: include/http_main.h
===
--- include/http_main.h (revision 1297483)
+++ include/http_main.h (working copy)
@@ -43,6 +43,11 @@
AP_DECLARE_DATA extern const char *ap_server_argv0;
/** The global server's ServerRoot */
AP_DECLARE_DATA extern const char *ap_server_root;
+/** The global server's DefaultRuntimeDir
+ * This is not usable directly in the general case; use
+ * ap_runtime_dir_relative() instead.
+ */
+AP_DECLARE_DATA extern const char *ap_runtime_dir;
/** The global server's server_rec */
AP_DECLARE_DATA extern server_rec *ap_server_conf;
/** global pool, for access prior to creation of server_rec */
Index: include/http_config.h
===
--- include/http_config.h (revision 1297483)
+++ include/http_config.h (working copy)
@@ -706,6 +706,14 @@
*/
AP_DECLARE(char *) ap_server_root_relative(apr_pool_t *p, const char *fname);
+/**
+ * Compute the name of a run-time file (e.g., shared memory "file") relative
+ * to the appropriate run-time directory. Absolute paths are returned as-is.
+ * The run-time directory is configured via the RuntimeDir directive or
+ * at build time.
+ */
+AP_DECLARE(char *) ap_runtime_dir_relative(apr_pool_t *p, const char *fname);
+
/* Finally, the hook for dynamically loading modules in... */
/**
Index: include/ap_mmn.h
===
--- include/ap_mmn.h(revision 1297483)
+++ include/ap_mmn.h(working copy)
@@ -394,6 +394,7 @@
* add insert_network_bucket hook, AP_DECLINED
* 20120211.0 (2.5.0-dev) Change re_nsub in ap_regex_t from apr_size_t to int.
* 20120211.1 (2.5.0-dev) Add ap_palloc_debug, ap_pcalloc_debug
+ * 20120211.2 (2.5.0-dev) Add ap_runtime_dir_relative
*/
#define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
Re: [PATCH] DefaultRuntimeDir, ap_runtime_dir_relative()
On Wed, Mar 7, 2012 at 7:15 AM, Jeff Trawick wrote:
> barely tested
>
seems to DTRT with this change to a test module, but more variations
of ServerRoot/DefaultRuntimeDir need to be tried; I expect that
ServerRoot must be set prior to DefaultRuntimeDir if declaring a path
relative to ServerRoot
static const char *set_flag(cmd_parms *cmd, void *dummy,
int arg)
{
+fprintf(stderr, "my relative run-time file: >%s<\n",
+ap_runtime_dir_relative(cmd->pool, "mod_test"));
+fprintf(stderr, "my absolute run-time file: >%s<\n",
+ap_runtime_dir_relative(cmd->pool, "/tmp/mod_test"));
return NULL;
}
Re: Cannot start httpd v2.4.1 with mpm_build on AIX
On Tue, Mar 6, 2012 at 8:00 PM, Guenter Knauf wrote: > Hi Jeff, > Am 26.02.2012 22:44, schrieb Jeff Trawick: > >> I guess the problem is that those MPM APIs are not decorated with >> AP_DECLARE() so they don't get added to httpd.exp so they don't get >> exported from httpd on AIX. >> >> Can you try the attached patch to mpm_common.h? > > it seems that this breaks the NetWare build now; I've not looked into it > myself since I'm swamped currently with other stuff, but Norm just sent me > this mail: > > Hi, > Tried to send this to devAThttpd-apache but it got bounced; how peasant > compared to other lists I've sent issues to. I'll watch for fixes. > > r1294936 causes extra export symbols. > Hi, > Re httpd-trunk: > r1294936 added AP_DECLARE_xxx() to a number of func prototypes/vars in > mpm_common.h. These are now found by the 'build/nw_exp_var.awk' script, > which causes the NetWare apache2 link to fail for missing exports. As > these functions are NOT common to NetWare or likely other non-Unix OS > (all seem to be in mpm_unix or related mpm's such as event and worker), > should these prototypes/vsrs now be in ap_mpm.h instead? > > Norm > Thanks; I'll look into that.
Re: [PATCH] DefaultRuntimeDir, ap_runtime_dir_relative()
+1 for inclusion in trunk for test/refining :) /me loves CTR :) On Mar 7, 2012, at 7:15 AM, Jeff Trawick wrote: > barely tested > > > > > -- > Born in Roswell... married an alien... >
Re: SVN question (Was: Re: log-message-tags)
On 07 Mar 2012, at 1:58 PM, Jim Jagielski wrote: >> Would we ever use this on the v2.4 branch at all? >> > > Sure... assume a case with 2.4.10 and trunk has changed enough > that to fix a bug in 2.4.10, there is no direct backport, but > rather a one-off. Would it not be safer to give instructions to drop a particular path into the tree in order to allocate a number, the same way the "build" directory is dropped into the documentation tree? This could solve the tags-have-moved problem. Regards, Graham --
Re: SVN question (Was: Re: log-message-tags)
On Mar 7, 2012, at 7:30 AM, Graham Leggett wrote: > On 07 Mar 2012, at 1:58 PM, Jim Jagielski wrote: > >>> Would we ever use this on the v2.4 branch at all? >>> >> >> Sure... assume a case with 2.4.10 and trunk has changed enough >> that to fix a bug in 2.4.10, there is no direct backport, but >> rather a one-off. > > Would it not be safer to give instructions to drop a particular path into the > tree in order to allocate a number, the same way the "build" directory is > dropped into the documentation tree? > > This could solve the tags-have-moved problem. > Sure... whatever works :) I'm ez :)
Re: SVN question (Was: Re: log-message-tags)
On 07 Mar 2012, at 2:36 PM, Jim Jagielski wrote: >> Would it not be safer to give instructions to drop a particular path into >> the tree in order to allocate a number, the same way the "build" directory >> is dropped into the documentation tree? >> >> This could solve the tags-have-moved problem. >> > > Sure... whatever works :) > > I'm ez :) Keen to keep it consistent if practical :) Regards, Graham --
Re: SVN question (Was: Re: log-message-tags)
On Mar 7, 2012, at 7:45 AM, Graham Leggett wrote: > On 07 Mar 2012, at 2:36 PM, Jim Jagielski wrote: > >>> Would it not be safer to give instructions to drop a particular path into >>> the tree in order to allocate a number, the same way the "build" directory >>> is dropped into the documentation tree? >>> >>> This could solve the tags-have-moved problem. >>> >> >> Sure... whatever works :) >> >> I'm ez :) > > Keen to keep it consistent if practical :) > Sure... just let me know what to do...
Re: SVN question (Was: Re: log-message-tags)
- Original Message - > > On Mar 7, 2012, at 7:45 AM, Graham Leggett wrote: > > > On 07 Mar 2012, at 2:36 PM, Jim Jagielski wrote: > > > >>> Would it not be safer to give instructions to drop a particular > >>> path into the tree in order to allocate a number, the same way > >>> the "build" directory is dropped into the documentation tree? > >>> > >>> This could solve the tags-have-moved problem. > >>> > >> > >> Sure... whatever works :) > >> > >> I'm ez :) > > > > Keen to keep it consistent if practical :) > > > > Sure... just let me know what to do... svn ps svn:externals 'tags-thingy ^/httpd/httpd/trunk/tags-thingy' -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: SVN question (Was: Re: log-message-tags)
On Mar 7, 2012, at 8:20 AM, Igor Galić wrote: > > svn ps svn:externals 'tags-thingy ^/httpd/httpd/trunk/tags-thingy' What about the the fact that docs/log-message-tags already exists? Does that change it? btw:, I expect that the actual command is svn ps svn:externals 'log-message-tags ^/httpd/httpd/trunk/docs/log-message-tags' ??
Re: SVN question (Was: Re: log-message-tags)
On 3/7/2012 5:40 AM, Greg Stein wrote: > svn:externals is only a client-side mechanism. This will not bring > log-message-tags/ into the branch, and especially not within the tag. Right, in this case it's fine. This is a 'for programmer's reference' datum that isn't needed when we export the tarball, and in fact should be purged on export. It's needed for day-to-day assignment of error codes, so its state at any given time isn't relevant, it's most recent state is critical.
Re: [PATCH] DefaultRuntimeDir, ap_runtime_dir_relative()
Since a user can now easily move all those non-log read/write files to a central dir like /var/run/apache etc., do we think we need to keep the files themselves separate between instances by choosing unique file names (adding parent pid or similar)? Or should we document that you should *not* use the same directory for multiple instances? Although adding a pid to the file names seems simple, it often leads to accumulating garbage files. Regards, Rainer
Re: [PATCH] DefaultRuntimeDir, ap_runtime_dir_relative()
- Original Message - > Since a user can now easily move all those non-log read/write files > to a > central dir like /var/run/apache etc., do we think we need to keep > the > files themselves separate between instances by choosing unique file > names (adding parent pid or similar)? Or should we document that you > should *not* use the same directory for multiple instances? > > Although adding a pid to the file names seems simple, it often leads > to > accumulating garbage files. No garbage please. > Regards, > > Rainer i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
