Re: mod_fcgid: different instances of the same program
On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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 da...@sadinoff.com
Re: mod_fcgid: different instances of the same program
On Mon, Nov 16, 2009 at 5:03 AM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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
Re: mod_fcgid: different instances of the same program
On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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
Re: mod_fcgid: different instances of the same program
On 16.11.2009 13:14, Jeff Trawick wrote: On Mon, Nov 16, 2009 at 5:03 AM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 1:47 AM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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@httpd.apache.org/msg45336.html Regards, Rainer
Re: mod_fcgid: different instances of the same program
On Mon, Nov 9, 2009 at 8:28 PM, pqf p...@mailtech.cn 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!
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 da...@sadinoff.com
Re: mod_fcgid: different instances of the same program
On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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@httpd.apache.org/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 ;)
Re: mod_fcgid: different instances of the same program
2009/11/10 Jeff Trawick traw...@gmail.com: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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@httpd.apache.org/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
Re: mod_fcgid: different instances of the same program
On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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@httpd.apache.org/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
Re: mod_fcgid: different instances of the same program
On Mon, Nov 9, 2009 at 6:47 PM, Danny Sadinoff da...@sadinoff.com wrote: On Tue, Nov 10, 2009 at 12:53 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Nov 9, 2009 at 5:16 PM, Danny Sadinoff danny.sadin...@gmail.com 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@httpd.apache.org/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=823178r2=834283diff_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)
Re: mod_fcgid: different instances of the same program
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@httpd.apache.org 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 da...@sadinoff.com
