Mailing List Archive: Apache: Dev

mod_fcgid: different instances of the same program

Index | Next | Previous | View Threaded

danny.sadinoff at gmail

Nov 9, 2009, 2:16 PM

Post #1 of 11 (959 views)
Permalink

mod_fcgid: different instances of the same program

Here are two details of mod_fcgid process management that I've just
learned after a long debug session and squinting at the mod_fcgid
code.

1) symlinks & you.
It seems that mod_fcgid identifies fcgid programs by inode and device,
not by filename. So two fcgid programs invoked by the webserver
along different paths will be counted as the same if the two paths are
hardlinks or softlinks to each other.

2) Virtual hosts
The above item holds true even across virtual hosts. So while
it's possible to adjust the FcgidInitialEnv items on a per-vhost
basis, this is a recipe for disaster if two vhosts point at the same
fcgi executable, because the resulting processes with potentially
different Environments will be inserted into the same pool. Once that
occurs, we may expect that a server spawned with config defined in
vhost A will be parcelled out to vhost B.

The Apache httpd 2.3 docs do not address the symlink issue at all, and
the virtual host issue only indirectly.
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

I'd appreciate it if someone could confirm or deny the above. If I'm
right, can we add it to the docs? None of it seems obvious to me.
Apologies in advance if this is the sort of thing that belongs on the
dev list. I'm happy to throw together a doc patch.

Thanks in advance

P.S. having a lot of trouble getting this message posted to the list. Not
sure what's up with that.

--
Danny Sadinoff
danny [at] sadinoff

trawick at gmail

Nov 9, 2009, 2:53 PM

Post #2 of 11 (917 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff <danny.sadinoff [at] gmail> wrote:
> Here are two details of mod_fcgid process management that I've just
> learned after a long debug session and squinting at the mod_fcgid
> code.
>
> 1) symlinks & you.
> It seems that mod_fcgid identifies fcgid programs by inode and device,
> not by filename. So two fcgid programs invoked by the webserver
> along different paths will be counted as the same if the two paths are
> hardlinks or softlinks to each other.

Mostly yes.

The path to the file doesn't matter; it is the file itself that matters.

There are different requirements for how programs are distinguished.
One possibility is changing from stat() to lstat() (i.e., distinguish
symlinks but not hard links). Another possibility is looking only at
the basename. This was discussed in this thread:
http://www.mail-archive.com/dev [at] httpd/msg45516.html

What are you trying to accomplish which is hindered by the current
implementation?

>
> 2) Virtual hosts
> The above item holds true even across virtual hosts. So while
> it's possible to adjust the FcgidInitialEnv items on a per-vhost
> basis, this is a recipe for disaster if two vhosts point at the same
> fcgi executable, because the resulting processes with potentially
> different Environments will be inserted into the same pool. Once that
> occurs, we may expect that a server spawned with config defined in
> vhost A will be parcelled out to vhost B.

Where does this occur? Entries in the process table are distinguished
by virtual host. (I think the implementation of this check is broken,
in that it requires that ServerName is set in the virtual hosts. Are
you using a simple test config that doesn't have ServerName set?)

>
>
> The Apache httpd 2.3 docs do not address the symlink issue at all, and
> the virtual host issue only indirectly.
> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

FWIW, this isn't part of "Apache httpd 2.3". mod_fcgid is released
separately from the web server and only by coincidence has the same
version number (2.3.x) as development levels of the web server.

>
>
> I'd appreciate it if someone could confirm or deny the above. If I'm
> right, can we add it to the docs? None of it seems obvious to me.
> Apologies in advance if this is the sort of thing that belongs on the
> dev list. I'm happy to throw together a doc patch.

Let's see what needs to be fixed in the code first ;)

graham.dumpleton at gmail

Nov 9, 2009, 3:05 PM

Post #3 of 11 (922 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

2009/11/10 Jeff Trawick <trawick [at] gmail>:
> On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff <danny.sadinoff [at] gmail> wrote:
>> Here are two details of mod_fcgid process management that I've just
>> learned after a long debug session and squinting at the mod_fcgid
>> code.
>>
>> 1) symlinks & you.
>> It seems that mod_fcgid identifies fcgid programs by inode and device,
>> not by filename. So two fcgid programs invoked by the webserver
>> along different paths will be counted as the same if the two paths are
>> hardlinks or softlinks to each other.
>
> Mostly yes.
>
> The path to the file doesn't matter; it is the file itself that matters.
>
> There are different requirements for how programs are distinguished.
> One possibility is changing from stat() to lstat() (i.e., distinguish
> symlinks but not hard links). Another possibility is looking only at
> the basename. This was discussed in this thread:
> http://www.mail-archive.com/dev [at] httpd/msg45516.html

FWIW, in the mod_wsgi module for Python applications, by default
applications are distinguished based on mount point and host/port they
are running under. That is, combination of SERVER_HOST, SERVER_PORT
and SCRIPT_NAME values.

Well, actually it is a little bit more complicated than that because
ports 80/443 are treated effectively the same given usage would
normally be paired.

What it means is that can have one script file mounted multiple times
and for each to be treated as separate instance of application.

In mod_wsgi the separation by default is done based on Python sub
interpreters within a process rather than actual processes. This is
because mod_wsgi supports running in embedded mode, ie., within Apache
server child processes, or as distinct daemon processes like with
FASTCGI.

There is the flexibility in mod_wsgi though to override this however
and manually specific what named application group (Python sub
interpreter within process), or whether embedded or daemon mode used
for processes and if daemon mode which named daemon process group.

Anyway, thought the strategy of using SERVER_HOST, SERVER_PORT and
SCRIPT_NAME values may be of interest as an alternative to
distinguishing based on path to script.

Graham

danny at sadinoff

Nov 9, 2009, 3:47 PM

Post #4 of 11 (915 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick <trawick [at] gmail> wrote:
>
> On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff <danny.sadinoff [at] gmail>
wrote:
> >...
> > 1) symlinks & you.
> > It seems that mod_fcgid identifies fcgid programs by inode and device,
> > not by filename. So two fcgid programs invoked by the webserver
> > along different paths will be counted as the same if the two paths are
> > hardlinks or softlinks to each other.
>
> Mostly yes.
>
> The path to the file doesn't matter; it is the file itself that matters.
>
> There are different requirements for how programs are distinguished.
> One possibility is changing from stat() to lstat() (i.e., distinguish
> symlinks but not hard links). Another possibility is looking only at
> the basename. This was discussed in this thread:
> http://www.mail-archive.com/dev [at] httpd/msg45516.html
>
> What are you trying to accomplish which is hindered by the current
> implementation?

My goal is a fairly simple one-application per vhost setup. But, I'm seeing
application pools shared amongst virtual hosts with distinct ServerName
declarations, all of whom refer to the same file path (and inode) for the
fcgi executable. From what you're telling me, this is buggy behavior. I'll
try to boil my config down further and come up with a good testcase.

Whether my config is wrong or the implementation is buggy, I would think
that the mere existance of the dev thread trying to nail down the semantics
ought to be argument enough for
documenting the file-path-vs-inode behavior.

>
> >
> > 2) Virtual hosts
> > The above item holds true even across virtual hosts. So while
> > it's possible to adjust the FcgidInitialEnv items on a per-vhost
> > basis, this is a recipe for disaster if two vhosts point at the same
> > fcgi executable, because the resulting processes with potentially
> > different Environments will be inserted into the same pool. Once that
> > occurs, we may expect that a server spawned with config defined in
> > vhost A will be parcelled out to vhost B.
>
> Where does this occur? Entries in the process table are distinguished
> by virtual host. (I think the implementation of this check is broken,
> in that it requires that ServerName is set in the virtual hosts. Are
> you using a simple test config that doesn't have ServerName set?)

My case is not yet simple. I'll get back to you.

> > The Apache httpd 2.3 docs do not address the symlink issue at all, and
> > the virtual host issue only indirectly.
> > http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
>
> FWIW, this isn't part of "Apache httpd 2.3". mod_fcgid is released
> separately from the web server and only by coincidence has the same
> version number (2.3.x) as development levels of the web server.

Well, that's another doc bug, since the page I link to has a big
header that says:
"Apache HTTP Server Version 2.3"
:)

-danny

trawick at gmail

Nov 9, 2009, 4:14 PM

Post #5 of 11 (922 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Mon, Nov 9, 2009 at 6:47 PM, Danny Sadinoff <danny [at] sadinoff> wrote:
> On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick <trawick [at] gmail> wrote:
>>
>> On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff <danny.sadinoff [at] gmail>
>> wrote:
>> >...
>> > 1) symlinks & you.
>> > It seems that mod_fcgid identifies fcgid programs by inode and device,
>> > not by filename. So two fcgid programs invoked by the webserver
>> > along different paths will be counted as the same if the two paths are
>> > hardlinks or softlinks to each other.
>>
>> Mostly yes.
>>
>> The path to the file doesn't matter; it is the file itself that matters.
>>
>> There are different requirements for how programs are distinguished.
>> One possibility is changing from stat() to lstat() (i.e., distinguish
>> symlinks but not hard links). Another possibility is looking only at
>> the basename. This was discussed in this thread:
>> http://www.mail-archive.com/dev [at] httpd/msg45516.html
>>
>> What are you trying to accomplish which is hindered by the current
>> implementation?
>
> My goal is a fairly simple one-application per vhost setup. But, I'm seeing
> application pools shared amongst virtual hosts with distinct ServerName
> declarations, all of whom refer to the same file path (and inode) for the
> fcgi executable. From what you're telling me, this is buggy behavior. I'll
> try to boil my config down further and come up with a good testcase.
> Whether my config is wrong or the implementation is buggy, I would think
> that the mere existance of the dev thread trying to nail down the semantics
> ought to be argument enough for
> documenting the file-path-vs-inode behavior.

sure

does this cover it for you?

http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/docs/manual/mod/mod_fcgid.xml?r1=823178&r2=834283&diff_format=h

>> FWIW, this isn't part of "Apache httpd 2.3". mod_fcgid is released
>> separately from the web server and only by coincidence has the same
>> version number (2.3.x) as development levels of the web server.
>
> Well, that's another doc bug, since the page I link to has a big
> header that says:
> "Apache HTTP Server Version 2.3"

ouch; mod_fcgid uses the same doc framework/settings as httpd

(maybe somebody will figure out how to fold the mod_fcgid docs into
the manual for the level of httpd it is installed with)

pqf at mailtech

Nov 9, 2009, 5:28 PM

Post #6 of 11 (918 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

Hi,
Yes, mod_fcgid search process node base on file's inode and deviceid(plus share_group_id, virtual host name). The goal is to create as less process as possible. Some administrators like the idea that all virtual hosts share one PHP process pool. (But some other don't, they can turn that off anyway. This is what share_group_id for in the first place, administrator can make who share who's process pool)
But the document should provide more detail about it, I missed that part in my old documents. I am sure some native English speekers will modify the documents soon.

Thanks

From: Danny Sadinoff
Sent: Tuesday, November 10, 2009 6:16 AM
To: dev [at] httpd
Subject: mod_fcgid: different instances of the same program

Here are two details of mod_fcgid process management that I've just
learned after a long debug session and squinting at the mod_fcgid
code.

1) symlinks & you.
It seems that mod_fcgid identifies fcgid programs by inode and device,
not by filename. So two fcgid programs invoked by the webserver
along different paths will be counted as the same if the two paths are
hardlinks or softlinks to each other.

2) Virtual hosts
The above item holds true even across virtual hosts. So while
it's possible to adjust the FcgidInitialEnv items on a per-vhost
basis, this is a recipe for disaster if two vhosts point at the same
fcgi executable, because the resulting processes with potentially
different Environments will be inserted into the same pool. Once that
occurs, we may expect that a server spawned with config defined in
vhost A will be parcelled out to vhost B.

The Apache httpd 2.3 docs do not address the symlink issue at all, and
the virtual host issue only indirectly.
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

I'd appreciate it if someone could confirm or deny the above. If I'm
right, can we add it to the docs? None of it seems obvious to me.
Apologies in advance if this is the sort of thing that belongs on the
dev list. I'm happy to throw together a doc patch.

Thanks in advance

P.S. having a lot of trouble getting this message posted to the list. Not sure what's up with that.

--
Danny Sadinoff
danny [at] sadinoff

trawick at gmail

Nov 10, 2009, 3:58 AM

Post #7 of 11 (897 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Mon, Nov 9, 2009 at 8:28 PM, pqf <pqf [at] mailtech> wrote:
> Hi,
> Yes, mod_fcgid search process node base on file's inode and deviceid(plus
> share_group_id, virtual host name). The goal is to create as less process as
> possible. Some administrators like the idea that all virtual hosts share one
> PHP process pool. (But some other don't, they can turn that off anyway. This
> is what share_group_id for in the first place, administrator can make who
> share who's process pool)

Can you explain how the share_grp_id works, and what configuration
directives control it? I think some piece of the puzzle may be
missing from the code.

> But the document should provide more detail about it, I missed that part
> in my old documents. I am sure some native English speekers will modify the
> documents soon.

sure, once we understand it ;)

Thanks!

danny at sadinoff

Nov 16, 2009, 2:03 AM

Post #8 of 11 (837 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff <danny [at] sadinoff> wrote:

> On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick <trawick [at] gmail> wrote:
> >
> > On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff <danny.sadinoff [at] gmail>
> wrote:
> > > 2) Virtual hosts
> > > The above item holds true even across virtual hosts. So while
> > > it's possible to adjust the FcgidInitialEnv items on a per-vhost
> > > basis, this is a recipe for disaster if two vhosts point at the same
> > > fcgi executable, because the resulting processes with potentially
> > > different Environments will be inserted into the same pool. Once that
> > > occurs, we may expect that a server spawned with config defined in
> > > vhost A will be parcelled out to vhost B.
> >
> > Where does this occur? Entries in the process table are distinguished
> > by virtual host. (I think the implementation of this check is broken,
> > in that it requires that ServerName is set in the virtual hosts. Are
> > you using a simple test config that doesn't have ServerName set?)
>
> My case is not yet simple. I'll get back to you.
>

It turns out that the problem was that I was using mod_fcgid-2.2 Upgrading
to mod_fcigd-2.3.4 fixed the problem. I apologize for the noise.

Should this item (vhost independence) be added to the upgrade notes section?
Are new features in mod_fcgid going to be manifest in the documentation in
general?

--
Danny Sadinoff
danny [at] sadinoff

trawick at gmail

Nov 16, 2009, 4:14 AM

Post #9 of 11 (835 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On Mon, Nov 16, 2009 at 5:03 AM, Danny Sadinoff <danny [at] sadinoff> wrote:
> On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff <danny [at] sadinoff> wrote:
>>
>> On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick <trawick [at] gmail> wrote:
>> >
>> > On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff
>> > <danny.sadinoff [at] gmail> wrote:
>> > > 2) Virtual hosts
>> > > The above item holds true even across virtual hosts. So while
>> > > it's possible to adjust the FcgidInitialEnv items on a per-vhost
>> > > basis, this is a recipe for disaster if two vhosts point at the same
>> > > fcgi executable, because the resulting processes with potentially
>> > > different Environments will be inserted into the same pool. Once that
>> > > occurs, we may expect that a server spawned with config defined in
>> > > vhost A will be parcelled out to vhost B.
>> >
>> > Where does this occur? Entries in the process table are distinguished
>> > by virtual host. (I think the implementation of this check is broken,
>> > in that it requires that ServerName is set in the virtual hosts. Are
>> > you using a simple test config that doesn't have ServerName set?)
>>
>> My case is not yet simple. I'll get back to you.
>
> It turns out that the problem was that I was using mod_fcgid-2.2 Upgrading
> to mod_fcigd-2.3.4 fixed the problem. I apologize for the noise.

great/np

> Should this item (vhost independence) be added to the upgrade notes section?

Unfortunately, I'm still in the dark about vhost independence and how
exactly the share_grp_id construct in the source code can change the
process association without more code written to tie it to the
configuration. ISTR that Rainer made the same observation --
share_grp_id isn't completely implemented. (Maybe it once worked and
some code was lost?)

> Are new features in mod_fcgid going to be manifest in the documentation in
> general?

definitely

falcacibar at gmail

Nov 16, 2009, 6:48 AM

Post #10 of 11 (836 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

> On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff
> <danny.sadinoff [at] gmail> wrote:
> 2) Virtual hosts
> The above item holds true even across virtual hosts. So while
> it's possible to adjust the FcgidInitialEnv items on a per-vhost
> basis, this is a recipe for disaster if two vhosts point at the same
> fcgi executable, because the resulting processes with potentially
> different Environments will be inserted into the same pool. Once that
> occurs, we may expect that a server spawned with config defined in
> vhost A will be parcelled out to vhost B.

The first time that i use mod_fcgid, i probe SetEnv instead
FcgidInitialEnv because i not readed complete the documentation, but
SetEnv and FcgidInitialEnv causes the same effect, the difference is
where you put the SetEnv. The FastCGI especification only needs the
environment variables that uses (FCGI_SOCKET, FCGI_USER, ALLOWED_ENV,
etc.) you could use SetEnv if need more flexibility than
FcgidInitialEnv.

--
Felipe Alcacibar Buccioni

rainer.jung at kippdata

Nov 16, 2009, 1:49 PM

Post #11 of 11 (823 views)
Permalink

Re: mod_fcgid: different instances of the same program [In reply to]

On 16.11.2009 13:14, Jeff Trawick wrote:
> On Mon, Nov 16, 2009 at 5:03 AM, Danny Sadinoff <danny [at] sadinoff> wrote:
>> On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff <danny [at] sadinoff> wrote:
>>>
>>> On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick <trawick [at] gmail> wrote:
>>>>
>>>> On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff
>>>> <danny.sadinoff [at] gmail> wrote:
>>>>> 2) Virtual hosts
>>>>> The above item holds true even across virtual hosts. So while
>>>>> it's possible to adjust the FcgidInitialEnv items on a per-vhost
>>>>> basis, this is a recipe for disaster if two vhosts point at the same
>>>>> fcgi executable, because the resulting processes with potentially
>>>>> different Environments will be inserted into the same pool. Once that
>>>>> occurs, we may expect that a server spawned with config defined in
>>>>> vhost A will be parcelled out to vhost B.
>>>>
>>>> Where does this occur? Entries in the process table are distinguished
>>>> by virtual host. (I think the implementation of this check is broken,
>>>> in that it requires that ServerName is set in the virtual hosts. Are
>>>> you using a simple test config that doesn't have ServerName set?)
>>>
>>> My case is not yet simple. I'll get back to you.
>>
>> It turns out that the problem was that I was using mod_fcgid-2.2 Upgrading
>> to mod_fcigd-2.3.4 fixed the problem. I apologize for the noise.
>
> great/np
>
>> Should this item (vhost independence) be added to the upgrade notes section?
>
> Unfortunately, I'm still in the dark about vhost independence and how
> exactly the share_grp_id construct in the source code can change the
> process association without more code written to tie it to the
> configuration. ISTR that Rainer made the same observation --
> share_grp_id isn't completely implemented. (Maybe it once worked and
> some code was lost?)

Yes, the original mail was:

http://www.mail-archive.com/dev [at] httpd/msg45336.html

Regards,

Rainer

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads