From fastcgi-developers at wilber.pointclark.net Wed Jul 1 04:47:19 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Wed, 1 Jul 2009 18:47:19 +1000 Subject: [FASTCGI] mod_fastcgi is ignoring -init-start-delay ?? Message-ID: <013b01c9fa28$8b98e9e0$e701a8c0@cu> I have this line in my /etc/httpd/conf/httpd.conf file: Include conf.d/*.conf and my fast cgi configuration looks like this: [root at server ~]# cat /etc/httpd/conf.d/mod_fastcgi.conf ScriptAlias /fcgi-bin "/var/www/fcgi-bin/" # FastCGI # If the module hasn't been loaded yet, deny access to the directory AllowOverride None Options None Order allow,deny Deny from all LoadModule fastcgi_module modules/mod_fastcgi.so FastCgiIpcDir /etc/httpd/fastcgi AllowOverride None Options +ExecCGI +FollowSymLinks +Includes -Indexes SetHandler fastcgi-script AddHandler fastcgi-script .fcg .fcgi .fpl Order allow,deny Allow from all # Start up the following static FastCGI applications. # By default, the Process Manager will start one instance of the application with the default configuration specified (in parentheses) below. # Should a static application instance die for any reason mod_fastcgi will spawn another to replace it and log the event (at the warn LogLevel). #Include conf.d/fastcgi.static FastCgiServer /var/www/fcgi-bin/someapp.fcgi -init-start-delay 5 FastCgiServer /var/www/fcgi-bin/anotherapp.fcgi -init-start-delay 10 FastCgiServer /var/www/fcgi-bin/newapp.fcgi -init-start-delay 20 FastCgiServer /var/www/fcgi-bin/otherapp.fcgi -init-start-delay 30 FastCgiServer /var/www/fcgi-bin/myspecialapp.fcgi -init-start-delay 60 When I restart httpd: [root at server ~]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] [root at server ~]# Why does /var/log/httpd/error_log look like this: [Wed Jul 01 18:19:48 2009] [notice] FastCGI: process manager initialized (pid 6650) [Wed Jul 01 18:19:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/myspecialapp.fcgi" started (pid 6651) [Wed Jul 01 18:19:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/otherapp.fcgi" started (pid 6652) [Wed Jul 01 18:19:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/newapp.fcgi" started (pid 6653) [Wed Jul 01 18:19:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/anotherapp.fcgi" started (pid 6654) [Wed Jul 01 18:19:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/someapp.fcgi" started (pid 6655) ***** How come all these static FastCGI applications are all starting together at the same time? How come they aren't scatter started? I'd expect to see either: [Wed Jul 01 18:19:48 2009] [notice] FastCGI: process manager initialized (pid 6650) [Wed Jul 01 18:19:53 2009] [warn] FastCGI: server "/var/www/fcgi-bin/someapp.fcgi" started (pid 6651) [Wed Jul 01 18:19:58 2009] [warn] FastCGI: server "/var/www/fcgi-bin/anotherapp.fcgi" started (pid 6652) [Wed Jul 01 18:20:08 2009] [warn] FastCGI: server "/var/www/fcgi-bin/newapp.fcgi" started (pid 6653) [Wed Jul 01 18:20:18 2009] [warn] FastCGI: server "/var/www/fcgi-bin/otherapp.fcgi" started (pid 6654) [Wed Jul 01 18:20:48 2009] [warn] FastCGI: server "/var/www/fcgi-bin/myspecialapp.fcgi" started (pid 6655) OR [Wed Jul 01 18:19:48 2009] [notice] FastCGI: process manager initialized (pid 6650) [Wed Jul 01 18:19:53 2009] [warn] FastCGI: server "/var/www/fcgi-bin/someapp.fcgi" started (pid 6651) [Wed Jul 01 18:20:03 2009] [warn] FastCGI: server "/var/www/fcgi-bin/anotherapp.fcgi" started (pid 6652) [Wed Jul 01 18:20:23 2009] [warn] FastCGI: server "/var/www/fcgi-bin/newapp.fcgi" started (pid 6653) [Wed Jul 01 18:20:53 2009] [warn] FastCGI: server "/var/www/fcgi-bin/otherapp.fcgi" started (pid 6654) [Wed Jul 01 18:21:53 2009] [warn] FastCGI: server "/var/www/fcgi-bin/myspecialapp.fcgi" started (pid 6655) I am using apache installed from rpm: [root at server ~]# rpm --query httpd-2.2.3-22.el5.centos.1.x86_64 httpd-2.2.3-22.el5.centos.1 [root at server ~]# I installed mod_fastcgi from source: 3790 tar xvfz mod_fastcgi-2.4.6.tar.gz 3791 cd mod_fastcgi-2.4.6 3792 cp Makefile.AP2 Makefile 3793 nano -w Makefile 3794 echo "top_dir = /usr/lib64/httpd" 3795 make 3796 make check 3797 make install 3798 cd .. 3799 ldconfig -v 3800 ldconfig -v 3801 service httpd restart I'm using this distro: [root at server ~]# cat /etc/redhat-release CentOS release 5.3 (Final) [root at server ~]# Any help would be appreciated. Thanks. From hoshino at labs.cybozu.co.jp Thu Jul 2 01:05:32 2009 From: hoshino at labs.cybozu.co.jp (Takashi HOSHINO) Date: Thu, 02 Jul 2009 14:05:32 +0900 Subject: [FASTCGI] [PATCH] fcgi-2.4.0-x64: libfcgi.dll build for 64bit Windows Message-ID: <4A4C401C.7080204@labs.cybozu.co.jp> Hello, We've created a patch to build 64bit native libfcgi.dll for Windows. We hope that this patch will be merged into the official distribution. If you are interested in this patch, please try it and give us your comments. Details of this patch are described in README.win64 file. Regards, Hoshino --- HOSHINO Takashi -------------- next part -------------- A non-text attachment was scrubbed... Name: fcgi-2.4.0-x64.patch.gz Type: application/x-gzip Size: 15743 bytes Desc: not available URL: From fastcgi-developers at wilber.pointclark.net Thu Jul 2 01:40:48 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Thu, 2 Jul 2009 15:40:48 +1000 Subject: [FASTCGI] Runtime monitoring of listen queue in realtime Message-ID: <002a01c9fad7$a70c65d0$e701a8c0@cu> >From the documentation: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer -listen-queue-depth n (100) The depth of listen() queue (also known as the backlog) shared by all of the instances of this application. A deeper listen queue allows the server to cope with transient load fluctuations without rejecting requests; it does not increase throughput. Adding additional application instances may increase throughput/performance, depending upon the application and the host. Is there a way is monitor this listen queue at runtime in realtime? Is there a unix signal I can send to the FastCGI Process Manager to print in the apache errors logs how deep the listen queue is? From fastcgi-developers at wilber.pointclark.net Thu Jul 2 01:43:36 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Thu, 2 Jul 2009 15:43:36 +1000 Subject: [FASTCGI] [PATCH] fcgi-2.4.0-x64: libfcgi.dll build for 64bitWindows References: <4A4C401C.7080204@labs.cybozu.co.jp> Message-ID: <003e01c9fad8$0b98c110$e701a8c0@cu> Would this patch also work to build a 64bit native static/shared library of libfcgi for Linux or does the current source code already build a 64bit native for Linux? ----- Original Message ----- From: "Takashi HOSHINO" To: Sent: Thursday, July 02, 2009 3:05 PM Subject: [FASTCGI] [PATCH] fcgi-2.4.0-x64: libfcgi.dll build for 64bitWindows Hello, We've created a patch to build 64bit native libfcgi.dll for Windows. We hope that this patch will be merged into the official distribution. If you are interested in this patch, please try it and give us your comments. Details of this patch are described in README.win64 file. Regards, Hoshino --- HOSHINO Takashi -------------------------------------------------------------------------------- _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers From hoshino at labs.cybozu.co.jp Thu Jul 2 03:13:51 2009 From: hoshino at labs.cybozu.co.jp (Takashi HOSHINO) Date: Thu, 02 Jul 2009 16:13:51 +0900 Subject: [FASTCGI] [PATCH] fcgi-2.4.0-x64: libfcgi.dll build for 64bitWindows In-Reply-To: <003e01c9fad8$0b98c110$e701a8c0@cu> References: <4A4C401C.7080204@labs.cybozu.co.jp> <003e01c9fad8$0b98c110$e701a8c0@cu> Message-ID: <4A4C5E2F.7070303@labs.cybozu.co.jp> Hello Matt, > Would this patch also work to build a 64bit native static/shared library of libfcgi for Linux or does the current source code > already build a 64bit native for Linux? The latter is true. For Linux, we just fixed source code to remove build warnings for 64bit native static/shared library. They work well without the patch and we have not found any critical problem for 64bit Linux. The main problem for 64bit Windows is that sizeof(long) and sizeof(void *) are not the same because it uses LLP64 data model. The patch mainly fixed this issue. We didn't try to build static library for Windows. Regards, Hoshino From panter at gmx.de Thu Jul 2 14:28:42 2009 From: panter at gmx.de (panter at gmx.de) Date: Thu, 02 Jul 2009 20:28:42 +0200 Subject: [FASTCGI] request reply callback Message-ID: <20090702182842.287170@gmx.net> hi, is there a way to catch the action when a request is completely answered, if the http response is sent to a client, within a fastcgi c application similar to phps register_shutdown_function? -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 From hleeyu at gmail.com Sat Jul 4 01:03:19 2009 From: hleeyu at gmail.com (Heinrich Lee Yu) Date: Sat, 4 Jul 2009 13:03:19 +0800 Subject: [FASTCGI] File locking Message-ID: <2ab89cb10907032203w759eeba7k2e93ace008a03aba@mail.gmail.com> Hi, I'm planning to write a fastcgi application with an embedded mysql server using libmysqld. From my understanding, fastcgi spawns multiple instances of my application. This would result in multiple libmysqld servers running on the same data directory. (I also need them to run on the same data dir because data needs to be the same for all instances) Would i be having problems regarding file locking and such with this setup? Or does fastcgi handle this? Also, I know I could also just let fastcgi spawn only one instance of my application. In this case, would performance be significantly slower than with multiple processes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastcgi-developers at wilber.pointclark.net Sat Jul 4 02:08:13 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Sat, 4 Jul 2009 16:08:13 +1000 Subject: [FASTCGI] File locking References: <2ab89cb10907032203w759eeba7k2e93ace008a03aba@mail.gmail.com> Message-ID: <002f01c9fc6d$d090b8b0$e701a8c0@cu> In regards to running single or multiple instances of your program: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html Any URI that Apache identifies as a FastCGI application and which hasn't been explicitly configured using a FastCgiServer or FastCgiExternalServer directive is handled as a dynamic application (see the FastCgiConfig directive for more information). Dynamic applications are not started at server initialization, but upon demand. If the demand is heavy, additional application instances are started. As the demand fades, application instances are killed off. Many of the options govern this process. http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer -init-start-delay n (1 second) The minimum number of seconds between the spawning of instances of this application. This delay decreases the demand placed on the system at server initialization. -processes n (1) The number of instances of the application to spawn at server initialization. http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiConfig ^^ Theres many options which control instance spawning. As for file locking, someone else will need to answer that question. ----- Original Message ----- From: Heinrich Lee Yu To: fastcgi-developers at mailman.fastcgi.com Sent: Saturday, July 04, 2009 3:03 PM Subject: [FASTCGI] File locking Hi, I'm planning to write a fastcgi application with an embedded mysql server using libmysqld. From my understanding, fastcgi spawns multiple instances of my application. This would result in multiple libmysqld servers running on the same data directory. (I also need them to run on the same data dir because data needs to be the same for all instances) Would i be having problems regarding file locking and such with this setup? Or does fastcgi handle this? Also, I know I could also just let fastcgi spawn only one instance of my application. In this case, would performance be significantly slower than with multiple processes? ------------------------------------------------------------------------------ _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From panter at gmx.de Sat Jul 4 15:53:09 2009 From: panter at gmx.de (panter at gmx.de) Date: Sat, 04 Jul 2009 21:53:09 +0200 Subject: [FASTCGI] fcgi: getenv always returns NULL and CreateNamedPipe() failed Message-ID: <20090704195309.240710@gmx.net> hello, in my fastcgi c application getenv always returns NULL for environment vars like REQUEST_URI and REMOTE_ADDR. I did compile mod_fastcgi and fcgi with Visual C++ 2008 and run into the error "CreateNamedPipe() failed" that got fixed with using the Project properties ... General -> Character Set -> Not Set. am i missing something? Pan -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From bicphuongonline at yahoo.com Mon Jul 6 04:40:32 2009 From: bicphuongonline at yahoo.com (bicphuongonline at yahoo.com) Date: Mon, 6 Jul 2009 01:40:32 -0700 (PDT) Subject: [FASTCGI] Failed to "make install" mod_fastcgi 2.4.6 for httpd 2.2.3 on RHEL5 Message-ID: <708465.85077.qm@web35104.mail.mud.yahoo.com> Dear Fastcgi-Developers, I hope to get help from you for this problem that washs two weeks away. After run the "make " command successfully, I type "make install" and press enter. The message is: [root at LINUXSERVER mod_fastcgi-2.4.6]# make install make[1]: Entering directory `/00pub/mapserver/13_fastcgi/mod_fastcgi-2.4.6' make[1]: execvp: /usr/lib/httpd/modules: Permission denied make[1]: *** [install-modules-yes] Error 127 make[1]: Leaving directory `/00pub/mapserver/13_fastcgi/mod_fastcgi-2.4.6' make: *** [install-recursive] Error 1 ...but the path "/usr/lib/httpd/modules" is present and has been changed mode to 777, accessing it is ok These lines are result of ls command: [root at LINUXSERVER ~]# ls /usr/lib/httpd/modules libphp5.so              mod_cgi.so           mod_mime_magic.so mod_actions.so          mod_dav_fs.so        mod_mime.so mod_alias.so            mod_dav.so           mod_negotiation.so mod_asis.so             mod_dbd.so           mod_perl.so mod_auth_basic.so       mod_deflate.so       mod_proxy_ajp.so mod_auth_digest.so      mod_dir.so           mod_proxy_balancer.so mod_authn_alias.so      mod_disk_cache.so    mod_proxy_connect.so mod_authn_anon.so       mod_dumpio.so        mod_proxy_ftp.so mod_authn_dbd.so        mod_env.so           mod_proxy_http.so mod_authn_dbm.so        mod_expires.so       mod_proxy.so mod_authn_default.so    mod_ext_filter.so    mod_python.so mod_authn_file.so       mod_file_cache.so    mod_rewrite.so mod_authnz_ldap.so      mod_filter.so        mod_setenvif.so mod_authz_dbm.so        mod_headers.so       mod_speling.so mod_authz_default.so    mod_ident.so         mod_ssl.so mod_authz_groupfile.so  mod_imagemap.so      mod_status.so mod_authz_host.so       mod_include.so       mod_suexec.so mod_authz_owner.so      mod_info.so          mod_unique_id.so mod_authz_user.so       mod_ldap.so          mod_userdir.so mod_autoindex.so        mod_log_config.so    mod_usertrack.so mod_cache.so            mod_log_forensic.so  mod_version.so mod_cern_meta.so        mod_logio.so         mod_vhost_alias.so mod_cgid.so             mod_mem_cache.so [root at LINUXSERVER ~]# I tried so many times, search through the www and read so many posts but no way to solve this. Please help me! More info: - OS: Red Hat Enterprise Linux 5.3 - httpd version: 2.2.3 - fastcgi version: 2.4.0 - mod_fastcgi version: 2.4.6 - httpd path: [root at LINUXSERVER ~]# whereis httpd httpd: /usr/sbin/httpd /usr/sbin/httpd.event /usr/sbin/httpd.worker /etc/httpd /usr/lib/httpd /usr/include/httpd /usr/share/man/man8/httpd.8.gz [root at LINUXSERVER ~]# Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastcgi-developers at wilber.pointclark.net Mon Jul 6 07:20:30 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Mon, 6 Jul 2009 21:20:30 +1000 Subject: [FASTCGI] Failed to "make install" mod_fastcgi 2.4.6 for httpd2.2.3 on RHEL5 References: <708465.85077.qm@web35104.mail.mud.yahoo.com> Message-ID: <070501c9fe2b$c5c460c0$e701a8c0@cu> Just a stab in the dark but maybe its an selinux related problem. Check out this file: /etc/selinux/config try setting SELINUX=disabled and rebooting and then running make install. If that doesn't fix the problem, then just edit /etc/selinux/config and put it back to how you found it. ----- Original Message ----- From: bicphuongonline at yahoo.com To: fastcgi-developers at mailman.fastcgi.com Sent: Monday, July 06, 2009 6:40 PM Subject: [FASTCGI] Failed to "make install" mod_fastcgi 2.4.6 for httpd2.2.3 on RHEL5 Dear Fastcgi-Developers, I hope to get help from you for this problem that washs two weeks away. After run the "make " command successfully, I type "make install" and press enter. The message is: [root at LINUXSERVER mod_fastcgi-2.4.6]# make install make[1]: Entering directory `/00pub/mapserver/13_fastcgi/mod_fastcgi-2.4.6' make[1]: execvp: /usr/lib/httpd/modules: Permission denied make[1]: *** [install-modules-yes] Error 127 make[1]: Leaving directory `/00pub/mapserver/13_fastcgi/mod_fastcgi-2.4.6' make: *** [install-recursive] Error 1 ...but the path "/usr/lib/httpd/modules" is present and has been changed mode to 777, accessing it is ok These lines are result of ls command: [root at LINUXSERVER ~]# ls /usr/lib/httpd/modules libphp5.so mod_cgi.so mod_mime_magic.so mod_actions.so mod_dav_fs.so mod_mime.so mod_alias.so mod_dav.so mod_negotiation.so mod_asis.so mod_dbd.so mod_perl.so mod_auth_basic.so mod_deflate.so mod_proxy_ajp.so mod_auth_digest.so mod_dir.so mod_proxy_balancer.so mod_authn_alias.so mod_disk_cache.so mod_proxy_connect.so mod_authn_anon.so mod_dumpio.so mod_proxy_ftp.so mod_authn_dbd.so mod_env.so mod_proxy_http.so mod_authn_dbm.so mod_expires.so mod_proxy.so mod_authn_default.so mod_ext_filter.so mod_python.so mod_authn_file.so mod_file_cache.so mod_rewrite.so mod_authnz_ldap.so mod_filter.so mod_setenvif.so mod_authz_dbm.so mod_headers.so mod_speling.so mod_authz_default.so mod_ident.so mod_ssl.so mod_authz_groupfile.so mod_imagemap.so mod_status.so mod_authz_host.so mod_include.so mod_suexec.so mod_authz_owner.so mod_info.so mod_unique_id.so mod_authz_user.so mod_ldap.so mod_userdir.so mod_autoindex.so mod_log_config.so mod_usertrack.so mod_cache.so mod_log_forensic.so mod_version.so mod_cern_meta.so mod_logio.so mod_vhost_alias.so mod_cgid.so mod_mem_cache.so [root at LINUXSERVER ~]# I tried so many times, search through the www and read so many posts but no way to solve this. Please help me! More info: - OS: Red Hat Enterprise Linux 5.3 - httpd version: 2.2.3 - fastcgi version: 2.4.0 - mod_fastcgi version: 2.4.6 - httpd path: [root at LINUXSERVER ~]# whereis httpd httpd: /usr/sbin/httpd /usr/sbin/httpd.event /usr/sbin/httpd.worker /etc/httpd /usr/lib/httpd /usr/include/httpd /usr/share/man/man8/httpd.8.gz [root at LINUXSERVER ~]# Thank you! ------------------------------------------------------------------------------ _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidb at chelsea.net Thu Jul 16 11:53:49 2009 From: davidb at chelsea.net (David Birnbaum) Date: Thu, 16 Jul 2009 11:53:49 -0400 (EDT) Subject: [FASTCGI] Mailing List Repair Message-ID: Folks, The mailing list was broken due to a problem that occurred when we upgraded our SPAM filtration system. I think it's fixed - please let me know if any issues come up subscribing, sending posts, etc. Cheers, David. From richeyrw at gmail.com Thu Jul 16 15:18:22 2009 From: richeyrw at gmail.com (Ross Richey) Date: Thu, 16 Jul 2009 13:18:22 -0600 Subject: [FASTCGI] FastCGI Expert Sought Message-ID: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> Sorry to be somewhat spammy on my first post... We've been using FastCGI+Lighttpd+PERL for many years now and we've had this problem with the FastCGI process not dying cleanly. We're finally sick of this and we're looking to for someone to help us get to the bottom of the problem. We're looking someone who knows the actual FastCGI code. We can definitely demonstrate the problem and we're more than willing to pay for the expertise and help. I'm happy to answer any and all questions and feel free to e-mail me off list if it would be better. Thanks, Ross Richey -------------- next part -------------- An HTML attachment was scrubbed... URL: From webmaster at cosmicperl.com Thu Jul 16 17:00:21 2009 From: webmaster at cosmicperl.com (Lyle) Date: Thu, 16 Jul 2009 22:00:21 +0100 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> Message-ID: <4A5F94E5.5010001@cosmicperl.com> Ross Richey wrote: > Sorry to be somewhat spammy on my first post... > > We've been using FastCGI+Lighttpd+PERL for many years now and we've > had this problem with the FastCGI process not dying cleanly. We're > finally sick of this and we're looking to for someone to help us get > to the bottom of the problem. We're looking someone who knows the > actual FastCGI code. We can definitely demonstrate the problem and > we're more than willing to pay for the expertise and help. I'm happy > to answer any and all questions and feel free to e-mail me off list if > it would be better. > > Thanks, > Ross Richey > Hi Ross, I don't know why, but something is telling me memory leaks in Perl. Unfortunately I'm not FastCGI expert, but I do plan to be when time permits, if only it wasn't for this damn recession :( Lyle From perrin at elem.com Thu Jul 16 17:30:08 2009 From: perrin at elem.com (Perrin Harkins) Date: Thu, 16 Jul 2009 17:30:08 -0400 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> Message-ID: <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> If you haven't already, I'd suggest you ask on the Lighttpd list. - Perrin On Thu, Jul 16, 2009 at 3:18 PM, Ross Richey wrote: > Sorry to be somewhat spammy on my first post... > > We've been using FastCGI+Lighttpd+PERL for many years now and we've had this > problem with the FastCGI process not dying cleanly.  We're finally sick of > this and we're looking to for someone to help us get to the bottom of the > problem.  We're looking someone who knows the actual FastCGI code.  We can > definitely demonstrate the problem and we're more than willing to pay for > the expertise and help.  I'm happy to answer any and all questions and feel > free to e-mail me off list if it would be better. > > Thanks, > Ross Richey > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > From fastcgi-developers at wilber.pointclark.net Thu Jul 16 18:40:19 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Fri, 17 Jul 2009 08:40:19 +1000 Subject: [FASTCGI] Need to disable buffering References: <005601c9f173$9184eab0$8c01a8c0@TSASVR4> Message-ID: First make sure that your PHP program is actually outputting information as its running rather than after it has finished so test it first outside of FastCGI. You might need to make some changes to your PHP program first. I recently had the same problem. There are many solutions, one being ob_implicit_flush() see this url for more information: http://www.andrewdavidson.com/articles/flush-after-print/ Another solution is how(which function call) you use to execute the program in the first place. Another solution was passthru(): http://us3.php.net/manual/en/function.passthru.php I recall some other solution was using a while loop to check to see if the program was still running and if so read from the buffer and then output however this solution relied on php5 but I was still using php4. The solution that was right for me in the end was this one: $command = "some command"; system("mkfifo pipeout > /dev/null 2>&1"); $pipe = popen("$command > pipeout","w"); $pipeout = fopen("pipeout", "r"); while (!feof($pipeout)) { $tempc = fgetc($pipeout); if($tempc == "\n") { echo "
"; } else { echo "$tempc"; } } Google is your friend :) Once your PHP program is working correctly then make sure you add the -flush to the FastCGI config, refer to the manual: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiConfig http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer Regards, Matt "TSA Dave" wrote in message news:005601c9f173$9184eab0$8c01a8c0 at TSASVR4... Greetings Can anyone please advise how I can disable the buffering in fastCGI. We have a Linux server running a Debian OS. fastCGI is installed as well as php4. Previous we were using normal CGI php4. The php command 'flush()' that was outputting data during the php process ( normal CGI ) is now not outputting on fastCGI -- it is buffering all the data until the php process is completed, and then outputting to the browser. How can we set the fastCGI to flush the output to the browser as it is receiving the flushed data from the php process ? As I am a novice, could you plese tell me exactly what to add / change and in which file on the Linux server ? Any help would be greatly appreciated. Regards, Dave ------------------------------------------------------------------------------ _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From hww at wilber.pointclark.net Thu Jul 16 18:31:20 2009 From: hww at wilber.pointclark.net (Matt) Date: Fri, 17 Jul 2009 08:31:20 +1000 Subject: [FASTCGI] Need to disable buffering References: <005601c9f173$9184eab0$8c01a8c0@TSASVR4> Message-ID: First make sure that your PHP program is actually outputting information as its running rather than after it has finished so test it first outside of FastCGI. You might need to make some changes to your PHP program first. I recently had the same problem. There are many solutions, one being ob_implicit_flush() see this url for more information: http://www.andrewdavidson.com/articles/flush-after-print/ Another solution is how(which function call) you use to execute the program in the first place. Another solution was passthru(): http://us3.php.net/manual/en/function.passthru.php I recall some other solution was using a while loop to check to see if the program was still running and if so read from the buffer and then output however this solution relied on php5 but I was still using php4. The solution that was right for me in the end was this one: $command = "some command"; system("mkfifo pipeout > /dev/null 2>&1"); $pipe = popen("$command > pipeout","w"); $pipeout = fopen("pipeout", "r"); while (!feof($pipeout)) { $tempc = fgetc($pipeout); if($tempc == "\n") { echo "
"; } else { echo "$tempc"; } } Google is your friend :) Once your PHP program is working correctly then make sure you add the -flush to the FastCGI config, refer to the manual: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiServer http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiConfig http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer Regards, Matt "TSA Dave" wrote in message news:005601c9f173$9184eab0$8c01a8c0 at TSASVR4... Greetings Can anyone please advise how I can disable the buffering in fastCGI. We have a Linux server running a Debian OS. fastCGI is installed as well as php4. Previous we were using normal CGI php4. The php command 'flush()' that was outputting data during the php process ( normal CGI ) is now not outputting on fastCGI -- it is buffering all the data until the php process is completed, and then outputting to the browser. How can we set the fastCGI to flush the output to the browser as it is receiving the flushed data from the php process ? As I am a novice, could you plese tell me exactly what to add / change and in which file on the Linux server ? Any help would be greatly appreciated. Regards, Dave ------------------------------------------------------------------------------ _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From hww at wilber.pointclark.net Thu Jul 16 18:37:27 2009 From: hww at wilber.pointclark.net (Matt) Date: Fri, 17 Jul 2009 08:37:27 +1000 Subject: [FASTCGI] Mailing List Repair References: Message-ID: <013001ca0665$ff7d8480$e701a8c0@cu> Gday David, Before I directly subscribed to the fastcgi-developers mailing I subscribed to the gmane.comp.web.fastcgi.devel newsgroup on the news.mane.org news server. Doing this allowed me to see the list messages as far back as 27/01/2008. The problem I get when I try to an earlier post via the newsgroup is this: Your mail to 'FastCGI-developers' with the subject Re: Need to disable buffering Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.pins.net/mailman/confirm.cgi/fastcgi-developers/8738daf95d166718bb9a1f0f183c1f921808e426 Any help with this problem would be greatly appreciated. Thanks, Matt ----- Original Message ----- From: "David Birnbaum" To: Sent: Friday, July 17, 2009 1:53 AM Subject: [FASTCGI] Mailing List Repair Folks, The mailing list was broken due to a problem that occurred when we upgraded our SPAM filtration system. I think it's fixed - please let me know if any issues come up subscribing, sending posts, etc. Cheers, David. _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers From davidb at chelsea.net Thu Jul 16 18:45:57 2009 From: davidb at chelsea.net (David Birnbaum) Date: Thu, 16 Jul 2009 18:45:57 -0400 Subject: [FASTCGI] Mailing List Repair In-Reply-To: <013001ca0665$ff7d8480$e701a8c0@cu> References: <013001ca0665$ff7d8480$e701a8c0@cu> Message-ID: <4A5FADA5.8070908@chelsea.net> I passed it through. Cheers, David. ------------------------------------------------------------------------ Matt wrote: > Gday David, > > Before I directly subscribed to the fastcgi-developers mailing I subscribed to the gmane.comp.web.fastcgi.devel newsgroup on the > news.mane.org news server. Doing this allowed me to see the list messages as far back as 27/01/2008. The problem I get when I try to > an earlier post via the newsgroup is this: > Your mail to 'FastCGI-developers' with the subject > > Re: Need to disable buffering > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > http://mailman.pins.net/mailman/confirm.cgi/fastcgi-developers/8738daf95d166718bb9a1f0f183c1f921808e426 > > > Any help with this problem would be greatly appreciated. > > Thanks, > Matt > > > ----- Original Message ----- > From: "David Birnbaum" > To: > Sent: Friday, July 17, 2009 1:53 AM > Subject: [FASTCGI] Mailing List Repair > > > Folks, > > The mailing list was broken due to a problem that occurred when we upgraded our > SPAM filtration system. I think it's fixed - please let me know if any issues > come up subscribing, sending posts, etc. > > Cheers, > > David. > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fastcgi-developers at wilber.pointclark.net Thu Jul 16 18:56:32 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Fri, 17 Jul 2009 08:56:32 +1000 Subject: [FASTCGI] Mailing List Repair References: <013001ca0665$ff7d8480$e701a8c0@cu> <4A5FADA5.8070908@chelsea.net> Message-ID: <019e01ca0668$a9743090$e701a8c0@cu> Is it fixed for the future? Just as a quick test I changed the email address field for the newsgroup account from: hww at wilber dot pointclark dot net to fastcgi-developers at wilber dot pointclark dot net and posted to the newsgroup. I got this reply: ----- Original Message ----- From: "Gmane Autoauthorizer" To: Sent: Friday, July 17, 2009 8:40 AM Subject: gmane.comp.web.fastcgi.devel: Authorization required You have sent a message to be posted on the gmane.comp.web.fastcgi.devel newsgroup. Before the message is posted on the newsgroup, you have to confirm that you exist. Just reply to this message, and the message will be posted. You have to respond within one week. -- Your friendly autoauthorizer at Gmane.org http://gmane.org/ after I replied to that message I got this back: ----- Original Message ----- From: "Gmane Autoauthorizer" To: Sent: Friday, July 17, 2009 8:41 AM Subject: Re: Authorization required to post to gmane.comp.web.fastcgi.devel (63c965bf711b92dcfcd61c5949dcfa11) You are now authorized to post to the gmane.comp.web.fastcgi.devel newsgroup. The original message you sent to the newsgroup will be posted within ten minutes. If you have any questions, they are most likely answered in the FAQ: . -- Your friendly autoauthorizer at Gmane.org http://gmane.org/ I had previously authorised the hww email address via the same method but my postings to the newsgroup weren't getting through. Is this now fixed as well? Thanks, Matt ----- Original Message ----- From: David Birnbaum To: Matt Cc: fastcgi-developers at mailman.fastcgi.com Sent: Friday, July 17, 2009 8:45 AM Subject: Re: [FASTCGI] Mailing List Repair I passed it through. Cheers, David. ------------------------------------------------------------------------------ Matt wrote: Gday David, Before I directly subscribed to the fastcgi-developers mailing I subscribed to the gmane.comp.web.fastcgi.devel newsgroup on the news.mane.org news server. Doing this allowed me to see the list messages as far back as 27/01/2008. The problem I get when I try to an earlier post via the newsgroup is this: Your mail to 'FastCGI-developers' with the subject Re: Need to disable buffering Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.pins.net/mailman/confirm.cgi/fastcgi-developers/8738daf95d166718bb9a1f0f183c1f921808e426 Any help with this problem would be greatly appreciated. Thanks, Matt ----- Original Message ----- From: "David Birnbaum" To: Sent: Friday, July 17, 2009 1:53 AM Subject: [FASTCGI] Mailing List Repair Folks, The mailing list was broken due to a problem that occurred when we upgraded our SPAM filtration system. I think it's fixed - please let me know if any issues come up subscribing, sending posts, etc. Cheers, David. _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From gslin at gslin.org Thu Jul 16 21:44:58 2009 From: gslin at gslin.org (Gea-Suan Lin) Date: Fri, 17 Jul 2009 09:44:58 +0800 Subject: [FASTCGI] getgrgid() and getpwent() not thread-safe causes segfault in worker MPM Message-ID: <20090717014458.GA34443@gslin.org> Hello all, We run apache 2.2 with worker mpm (threading model), and use mod_fastcgi to run PHP 5.2.10 on FreeBSD 7.2-RELEASE-p2. We found httpd will segfault sometimes (2~3 times in one hour) and tried to gdb it, then I found bug is that getgrgid() and getpwent() are not thread-safe. I use getgrgid_r() and getpwent_r() to rewrite (as attachment) and in this 12 hours it looks good. -- * Gea-Suan Lin (public key: Using https://keyserver.pgp.com/ to search) * If you cannot convince them, confuse them. -- Harry S Truman -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-fcgi_util.c Type: text/x-csrc Size: 1799 bytes Desc: not available URL: From richeyrw at gmail.com Thu Jul 16 23:04:59 2009 From: richeyrw at gmail.com (Ross Richey) Date: Thu, 16 Jul 2009 21:04:59 -0600 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> Message-ID: <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> Thanks for all the responses. Some more details: It may be that this is more of a conceptual problem than a technical problem. Several people have suggested that PERL is the problem. And indeed in a sense it is. It's really hard to keep PERL from leaking memory, so hard it's not worth even trying. This wouldn't be a problem if, after a certain number of requests, we could just nicely kill the old FastCGI process and respawn a new one. Instead we get processes which are defunct and Lighttpd will eventually run out of live FastCGI processes to use and then it will no longer be able to serve those requests. So yes this might be something which needs to be handled at the Lighttpd level. But before we do that I just want to ask the conceptual question: Is there some method of nicely killing and respawning a FastCGI process? The reason I asked for an expert and offered money is that we're fully expecting that we might have to get someone to actually add that functionality to FastCGI, but obviously I'm open to other ideas on fixing the problem. Ross On Thu, Jul 16, 2009 at 3:30 PM, Perrin Harkins wrote: > If you haven't already, I'd suggest you ask on the Lighttpd list. > > - Perrin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perrin at elem.com Fri Jul 17 00:03:44 2009 From: perrin at elem.com (Perrin Harkins) Date: Fri, 17 Jul 2009 00:03:44 -0400 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> Message-ID: <66887a3d0907162103m7831d14cj46e6d21ebd81a3ac@mail.gmail.com> On Thu, Jul 16, 2009 at 11:04 PM, Ross Richey wrote: > Several people have suggested that PERL is the problem.  And indeed in a > sense it is.  It's really hard to keep PERL from leaking memory, so hard > it's not worth even trying. Perl doesn't usually leak, at least not in the sense that C programs do. It doesn't have pointer problems and lose track of memory. It will typically grow over time though, as your program uses more memory for data, and it keeps the memory it allocates as a speed optimization for the next time you use the same variable. The common solution to this in mod_perl-land is to check the size of the process at the end of requests and kill the process if it gets too big. Then apache spawns a new one. > So yes this might be something which needs to be handled at the Lighttpd > level.  But before we do that I just want to ask the conceptual question: > > Is there some method of nicely killing and respawning a FastCGI process? > > The reason I asked for an expert and offered money is that we're fully > expecting that we might have to get someone to actually add that > functionality to FastCGI, but obviously I'm open to other ideas on fixing > the problem. I'm no FastCGI expert, but I think you're missing the fact that FastCGI is a protocol, not a piece of code. The code you run that implements FastCGI for Lighttpd is strictly a Lighttpd thing, and it can implement process management in any way it chooses. That's why I suggested you talk to them. - Perrin From unique at idempot.net Fri Jul 17 01:28:50 2009 From: unique at idempot.net (Matthew Weigel) Date: Fri, 17 Jul 2009 00:28:50 -0500 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> Message-ID: <4A600C12.70506@idempot.net> Ross Richey wrote: > So yes this might be something which needs to be handled at the Lighttpd > level. But before we do that I just want to ask the conceptual question: > > Is there some method of nicely killing and respawning a FastCGI process? I run lighttpd on my personal server and do my personal web development as FastCGI; however, I don't rely on lighttpd's process management functionality to do it[1]. If you do use lighttpd's own process management (e.g., specifying in lighttpd.conf the 'bin-path' for a FastCGI process)... first of all, have you looked at http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ModFastCGI ? You should be able to set a minimum number of processes, and a maximum number of processes, for that FastCGI server. I *think* - but again, I don't use this part of lighttpd myself - that if you simply configure your Perl program to exit after handling X number of requests, lighttpd will spawn new processes once the number of remaining processes drops below the minimum. PHP has the functionality you're asking about (each child process dies after X requests) built in, without needing to be spawned/managed by lighttpd, and I wrote a small Perl application that does it as well. The traffic I get for this particular web app is minimal, so I've never needed to take the PHP approach of having a master process that manages multiple children who occasionally restart; it's definitely possible though. > The reason I asked for an expert and offered money is that we're fully > expecting that we might have to get someone to actually add that > functionality to FastCGI, but obviously I'm open to other ideas on > fixing the problem. Attached is the skeleton of the Perl application I wrote, minus the actual HTML generation, form handling, etc. It might help with writing a Perl FastCGI server that isn't managed directly by lighttpd. You might have an easier time simply changing your existing code to exit after X requests, but both options are worth considering. It works for me, but that's no guarantee. :-) 1. I do quite a bit to separate privileges and functionality; I have lighttpd configured to chroot itself to /var/www and drop root privileges when it starts, and for example PHP is spawned via lighttpd's spawn-fcgi in a more restrictive chroot (like /var/www/first.example.net/) as a more restricted user. -- Matthew Weigel hacker unique & idempot . ent -------------- next part -------------- A non-text attachment was scrubbed... Name: foo_srv.pl Type: application/x-perl Size: 3362 bytes Desc: not available URL: From kornelpal at gmail.com Fri Jul 17 04:45:24 2009 From: kornelpal at gmail.com (=?ISO-8859-1?Q?Korn=E9l_P=E1l?=) Date: Fri, 17 Jul 2009 10:45:24 +0200 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> Message-ID: <4A603A24.6040600@gmail.com> Ross Richey wrote: > Several people have suggested that PERL is the problem. And indeed in a > sense it is. It's really hard to keep PERL from leaking memory, so hard > it's not worth even trying. This wouldn't be a problem if, after a > certain number of requests, we could just nicely kill the old FastCGI > process and respawn a new one. Instead we get processes which are > defunct and Lighttpd will eventually run out of live FastCGI processes > to use and then it will no longer be able to serve those requests. If you mean processes marked as by ps that are also known as zombie processes then this has nothing to do with that process. Zomobie processes are caused by the parent process. A zombie process is basically only consuming a PID, there is no real process behind it. There are three ways to get rid of zombie processes: 1) Kill the parent process. 2) Fork a new process at the very beginning of your program an exit the original process that is now the parent that makes init the new parent of your now orphaned process that takes care about calling wait(). 3) Fix the parent by handling SIGCHLD and calling wait() in the handler. This latter is the real solution but if you don't want to touch the parent process you should do number 2. Kornél From webmaster at cosmicperl.com Fri Jul 17 07:22:12 2009 From: webmaster at cosmicperl.com (Lyle) Date: Fri, 17 Jul 2009 12:22:12 +0100 Subject: [FASTCGI] FastCGI Expert Sought In-Reply-To: <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> References: <736532120907161218w6a7d85efk5221b2989a42e9bc@mail.gmail.com> <66887a3d0907161430g691c1346tefd7f8699f997631@mail.gmail.com> <736532120907162004ida57cc8i968a3e993ded29e@mail.gmail.com> Message-ID: <4A605EE4.1020207@cosmicperl.com> Ross Richey wrote: > Thanks for all the responses. Some more details: > > It may be that this is more of a conceptual problem than a technical > problem. > > Several people have suggested that PERL is the problem. And indeed in > a sense it is. It's really hard to keep PERL from leaking memory, so > hard it's not worth even trying. This wouldn't be a problem if, after > a certain number of requests, we could just nicely kill the old > FastCGI process and respawn a new one. Instead we get processes which > are defunct and Lighttpd will eventually run out of live FastCGI > processes to use and then it will no longer be able to serve those > requests. Ok. Couple of things. A) It's Perl not PERL. B) It's not that hard to stop memory leaks in Perl, you just need to weaken variables that contain circular references before they get destroyed. C) If it is a memory leak problem in Perl then it's due to the way the script has been coded and would likely be happening just the same if in another language. There are plenty of Perl experts out there, and plenty of free tools you can use to track down if this is indeed a memory leak. http://letsgetdugg.com/2009/04/19/finding-circular-reference-leaks-in-perl/ For a QnD solution you could always do a simple Perl CRON script that looks for the defunct processes and hits them with a kill -9. Lyle From bruce.axtens at gmail.com Fri Jul 17 09:12:29 2009 From: bruce.axtens at gmail.com (Bruce M. Axtens) Date: Fri, 17 Jul 2009 21:12:29 +0800 Subject: [FASTCGI] FastCGI and VB6 Message-ID: <4A6078BD.1010504@strapper.net> Apologies if this has been asked before. Are there any examples of VB6 being used to write FastCGI applications? I've had a short wander thru the documentation and can't see anything that would stop VB6 being used. However, some of you have a deeper understanding of the issues. Is using VB6 possible? Kind regards, Bruce. From panter at gmx.de Fri Jul 17 12:55:26 2009 From: panter at gmx.de (panter at gmx.de) Date: Fri, 17 Jul 2009 18:55:26 +0200 Subject: [FASTCGI] thousand separator in fcgi c Message-ID: <20090717165526.315380@gmx.net> Is there a portable way to do a thousand separator for numbers in a fcgi c application? Seems %' doesn't work for printf under windows. Pan -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 From fastcgi-developers at wilber.pointclark.net Fri Jul 17 20:42:36 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Sat, 18 Jul 2009 10:42:36 +1000 Subject: [FASTCGI] thousand separator in fcgi c References: <20090717165526.315380@gmx.net> Message-ID: <02b401ca0740$a58db770$e701a8c0@cu> Normally isn't the thousand separator the comma character i.e ','? Have you tried using the escape character? e.g. %\' %\, Matt ----- Original Message ----- From: To: Sent: Saturday, July 18, 2009 2:55 AM Subject: [FASTCGI] thousand separator in fcgi c Is there a portable way to do a thousand separator for numbers in a fcgi c application? Seems %' doesn't work for printf under windows. Pan -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers From jsprenkle at gmail.com Sat Jul 18 14:04:26 2009 From: jsprenkle at gmail.com (Jay Sprenkle) Date: Sat, 18 Jul 2009 13:04:26 -0500 Subject: [FASTCGI] documentation change request Message-ID: <1b5f39a10907181104s4f1c42d6n23e0bb206a513c83@mail.gmail.com> I'm trying to build the mod_fastcgi module for Apache 2.2. The instructions in the distribution here: http://www.fastcgi.com/dist/ are pretty minimal and could use some love. The file INSTALL.AP2 mentions: "If your Apache2 installation isn't in /usr/local/apache2, then set the top_dir variable when running make (or edit the Makefile), e.g." This isn't clear. My installation of what? The Apache source tree or the binary? I'm assuming it's the source tree. If you run make with the defaults and you're not set correctly it fails to find "special.mk". include ${top_builddir}/build/special.mk Perhaps the docs can mention this? If you use a software package manager and you install the server you probably don't have the source tree. Perhaps it should be mentioned that it's required? Well, time to get back to trying to get this thing working. Thanks for your attention -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron at aron.ws Mon Jul 27 04:33:58 2009 From: aron at aron.ws (Aron Szabo) Date: Mon, 27 Jul 2009 10:33:58 +0200 Subject: [FASTCGI] Memory not freed at exit ? Message-ID: <4A6D6676.508@aron.ws> Hi! While debugging my app with valgrind I noticed, that memory is not being freed after FCGX_Init(): ==10496== 768 bytes in 1 blocks are still reachable in loss record 6 of 7 ==10496== at 0x4C278AE: malloc (vg_replace_malloc.c:207) ==10496== by 0x5190A80: OS_LibInit (in /usr/lib/libfcgi.so.0.0.0) ==10496== by 0x518DC6B: FCGX_Init (in /usr/lib/libfcgi.so.0.0.0) ==10496== by 0x40424B: main (bitp_web.c:427) OS_LibInit is allocating memory (asyncIoTable pointer). The memory should be freed by OS_LibShutdown, but that function is not called anywhere in the library. I noticed cgi-fcgi.c has a cleanup routine defined: static void FCGIexit(int exitCode) { if(appServerSock != -1) { OS_Close(appServerSock); appServerSock = -1; } OS_LibShutdown(); exit(exitCode); } #undef exit #define exit FCGIexit Of course it's being freed after the program exited, so it's not critical, but it's not right. Maybe cleanup should be defined and be added to the documentation. #define FCGX_Cleanup OS_LibShutdown(); Yours, Aron From jcxxr at yahoo.com Tue Jul 28 06:59:18 2009 From: jcxxr at yahoo.com (Jean-Christophe Roux) Date: Tue, 28 Jul 2009 03:59:18 -0700 (PDT) Subject: [FASTCGI] Kill fastcgi process Message-ID: <679592.73872.qm@web35307.mail.mud.yahoo.com> Hello, I am running fastcgi processes on a Centos 5 box with Apache 2.2. I am still confused on how I should kill processes before I release a new version of my app. Currently, I am doing something like: while [ 1 ] do pid=`ps -C "${app_name}" -o pid --no-headers` if [[ -z ${pid} ]] ; then echo "No more pid" break else kill -9 ${pid} echo "Pid ${pid} killed" fi done (1) Is that a satisfactory way to kill those processes? (2) Does it make a difference that the process is a static or a dynamic one in order to make sure the older version of my app is completely removed? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From aron at aron.ws Tue Jul 28 07:04:40 2009 From: aron at aron.ws (Aron Szabo) Date: Tue, 28 Jul 2009 13:04:40 +0200 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <679592.73872.qm@web35307.mail.mud.yahoo.com> References: <679592.73872.qm@web35307.mail.mud.yahoo.com> Message-ID: <4A6EDB48.9070301@aron.ws> Hi! (1) : Kill -9 may be a bad idea ... Read this: http://speculation.org/garrick/kill-9.html (2) : Normally no ... I hope it helped ;) Aron Jean-Christophe Roux wrote: > Hello, > > I am running fastcgi processes on a Centos 5 box with Apache 2.2. > > I am still confused on how I should kill processes before I release a > new version of my app. > > Currently, I am doing something like: > > while [ 1 ] > do > pid=`ps -C "${app_name}" -o pid --no-headers` > if [[ -z ${pid} ]] ; then > echo "No more pid" > break > else > kill -9 ${pid} > echo "Pid ${pid} killed" > fi > done > > (1) Is that a satisfactory way to kill those processes? > (2) Does it make a difference that the process is a static or a > dynamic one in order to make sure the older version of my app is > completely removed? > > Thank you > > ------------------------------------------------------------------------ > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > From jcxxr at yahoo.com Tue Jul 28 07:32:55 2009 From: jcxxr at yahoo.com (Jean-Christophe Roux) Date: Tue, 28 Jul 2009 04:32:55 -0700 (PDT) Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <4A6EDB48.9070301@aron.ws> References: <679592.73872.qm@web35307.mail.mud.yahoo.com> <4A6EDB48.9070301@aron.ws> Message-ID: <395501.64461.qm@web35302.mail.mud.yahoo.com> Aron, Thanks for your answer >Kill -9 may be a bad idea ... >Read this: http://speculation.org/garrick/kill-9.html Thank you; I am going to take this into account >> (2) Does it make a difference that the process is a static or a dynamic one in order to make sure the older version of my app is completely removed? >Normally no ... Once I have killed the running processes, what prevents the FastCgi Manager from spawning new processes which could be the older version of my program. Isn't there a way to send a message straight to the FastCgi Process Manager for Apache who would do the job (better than me most probably). How do you guys handle that step of switching to a newer version of your app? ________________________________ From: Aron Szabo To: Jean-Christophe Roux Cc: fastcgi-developers at mailman.fastcgi.com Sent: Tuesday, July 28, 2009 7:04:40 AM Subject: Re: [FASTCGI] Kill fastcgi process Hi! (1) : Kill -9 may be a bad idea ... Read this: http://speculation.org/garrick/kill-9.html (2) : Normally no ... I hope it helped ;) Aron Jean-Christophe Roux wrote: > Hello, > > I am running fastcgi processes on a Centos 5 box with Apache 2.2. > > I am still confused on how I should kill processes before I release a new version of my app. > > Currently, I am doing something like: > > while [ 1 ] > do > pid=`ps -C "${app_name}" -o pid --no-headers` > if [[ -z ${pid} ]] ; then > echo "No more pid" > break > else > kill -9 ${pid} > echo "Pid ${pid} killed" > fi > done > > (1) Is that a satisfactory way to kill those processes? > (2) Does it make a difference that the process is a static or a dynamic one in order to make sure the older version of my app is completely removed? > > Thank you > > ------------------------------------------------------------------------ > > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lynchcr at live.com Tue Jul 28 10:33:10 2009 From: lynchcr at live.com (Tom Lynch) Date: Tue, 28 Jul 2009 08:33:10 -0600 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <679592.73872.qm@web35307.mail.mud.yahoo.com> References: <679592.73872.qm@web35307.mail.mud.yahoo.com> Message-ID: PPPLEASE TAKE ME OFF THIS LIST (yes I unsubscribed already, yes I wrote the moderator) I had one question a long time ago as my script never got called, and no one answered, hence I'm not even using FASTCGI. Date: Tue, 28 Jul 2009 03:59:18 -0700 From: jcxxr at yahoo.com To: fastcgi-developers at mailman.fastcgi.com Subject: [FASTCGI] Kill fastcgi process Hello, I am running fastcgi processes on a Centos 5 box with Apache 2.2. I am still confused on how I should kill processes before I release a new version of my app. Currently, I am doing something like: while [ 1 ] do pid=`ps -C "${app_name}" -o pid --no-headers` if [[ -z ${pid} ]] ; then echo "No more pid" break else kill -9 ${pid} echo "Pid ${pid} killed" fi done (1) Is that a satisfactory way to kill those processes? (2) Does it make a difference that the process is a static or a dynamic one in order to make sure the older version of my app is completely removed? Thank you _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rclemley at booksys.com Tue Jul 28 12:29:49 2009 From: rclemley at booksys.com (Rob Lemley) Date: Tue, 28 Jul 2009 11:29:49 -0500 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: References: Message-ID: <4A6F277D.1040102@booksys.com> Jean-Christophe Roux wrote: > Date: Tue, 28 Jul 2009 04:32:55 -0700 (PDT) > From: Jean-Christophe Roux > Subject: Re: [FASTCGI] Kill fastcgi process > To: Aron Szabo > Cc: fastcgi-developers at mailman.fastcgi.com > Message-ID: <395501.64461.qm at web35302.mail.mud.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > Aron, > > Thanks for your answer > > >> Kill -9 may be a bad idea ... >> Read this: http://speculation.org/garrick/kill-9.html >> > Thank you; I am going to take this into account > If you need to use "kill -9" then something is broken and not working correctly. Indiscriminate use of "kill -9" is a fine way to hose your system. It should be used only as a last resort and is a strong indication that something needs to be analyzed and fixed. > >>> (2) Does it make a difference that the process is a static or a >>> > dynamic one in order to make sure the older version of my app is > completely removed? > >> Normally no ... >> > Once I have killed the running processes, what prevents the FastCgi Manager from spawning new processes which could be the older version of my program. Isn't there a way to send a message straight to the FastCgi Process Manager for Apache who would do the job (better than me most probably). > If you're restarting the app to run the new version, then you should ensure that the FastCgi process manager is unable to start the old version. I'm not aware of a way to tell the FastCgi process manager to do that, short of restarting apache. > How do you guys handle that step of switching to a newer version of your app? > Normally you install the old version, then restart the app. On Unix/Linux systems, you can remove files which are open by other processes. This is because you are removing only the directory entry, not the file data and metadata. The old version continues to run after the old app is removed or replaced. I believe the conventional FastCGI strategy is to upgrade the app in place and immediately restart the app. The DJB DaemonTools package can be useful for managing FastCGI External Servers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronan.klyne at groupbc.com Wed Jul 29 07:12:51 2009 From: ronan.klyne at groupbc.com (RK) Date: Wed, 29 Jul 2009 12:12:51 +0100 Subject: [FASTCGI] Next release of mod_fastcgi? Message-ID: <4A702EB3.7040609@groupbc.com> Hi all, I found this message in the archives: http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/2008-November/000109.html It mentions a snapshot release to fix an incompatibility with mod_deflate (which it does, thanks :-) ), but leaves me wondering when this will make it into a 'proper' release. Is there a plan for when this will happen? Is it on hold pending some other development, or has it simply not been called for? Thanks, Ronan From fastcgi-developers at wilber.pointclark.net Wed Jul 29 09:25:50 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Wed, 29 Jul 2009 23:25:50 +1000 Subject: [FASTCGI] Next release of mod_fastcgi? References: <4A702EB3.7040609@groupbc.com> Message-ID: <032701ca1050$17c9ce10$e701a8c0@cu> I think there have been another patch or two posted to the mailing list since then. Any news when the next release might be? ----- Original Message ----- From: "David Birnbaum" Newsgroups: gmane.comp.web.fastcgi.devel To: "Artur Zaprzala" Cc: Sent: Thursday, November 06, 2008 12:41 AM Subject: Re: Content-Length header should be set using ap_set_content_length Artur, Thanks for the patches - we'll take a peek and see about rolling them into the current SNAP before cutting a new version. David. ----- Original Message ----- From: "Rob Saccoccio" Newsgroups: gmane.comp.web.fastcgi.devel To: Sent: Monday, September 22, 2008 6:05 AM Subject: mod_fastcgi - testing help please I believe that I have incorporated all outstanding mod_fastcgi patches. If I missed yours, please repost. I no longer use FastCGI in my work (I no longer do web related development) and thus need testing support. Please report successes and difficulties to the list. Once it appears to have passed, I'll tag and roll it as 2.4.8. A snapshot that can be found in the usual place: http://www.fastcgi.com/dist/ Rob ----- Original Message ----- From: "RK" To: Sent: Wednesday, July 29, 2009 9:12 PM Subject: [FASTCGI] Next release of mod_fastcgi? Hi all, I found this message in the archives: http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/2008-November/000109.html It mentions a snapshot release to fix an incompatibility with mod_deflate (which it does, thanks :-) ), but leaves me wondering when this will make it into a 'proper' release. Is there a plan for when this will happen? Is it on hold pending some other development, or has it simply not been called for? Thanks, Ronan _______________________________________________ FastCGI-developers mailing list FastCGI-developers at mailman.fastcgi.com http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers From davidb at pins.net Wed Jul 29 10:18:16 2009 From: davidb at pins.net (David Birnbaum) Date: Wed, 29 Jul 2009 10:18:16 -0400 (EDT) Subject: [FASTCGI] Next release of mod_fastcgi? In-Reply-To: <032701ca1050$17c9ce10$e701a8c0@cu> References: <4A702EB3.7040609@groupbc.com> <032701ca1050$17c9ce10$e701a8c0@cu> Message-ID: I spoke to Rob who's been underwater with his day job and will be for a while. However, I think there is a snap that included these late last year, and a handful of newer patches that are waiting a new snap. Maybe next month we can get an official snap cut for people to try out. Sorry for the delays.... David. ----- On Wed, 29 Jul 2009, Matt wrote: > I think there have been another patch or two posted to the mailing list since then. Any news when the next release might be? > > > ----- Original Message ----- > From: "David Birnbaum" > Newsgroups: gmane.comp.web.fastcgi.devel > To: "Artur Zaprzala" > Cc: > Sent: Thursday, November 06, 2008 12:41 AM > Subject: Re: Content-Length header should be set using ap_set_content_length > > > Artur, > > Thanks for the patches - we'll take a peek and see about rolling them into the > current SNAP before cutting a new version. > > David. > > ----- Original Message ----- > From: "Rob Saccoccio" > Newsgroups: gmane.comp.web.fastcgi.devel > To: > Sent: Monday, September 22, 2008 6:05 AM > Subject: mod_fastcgi - testing help please > > > I believe that I have incorporated all outstanding mod_fastcgi patches. If > I missed yours, please repost. > > I no longer use FastCGI in my work (I no longer do web related development) > and thus need testing support. Please report successes and difficulties to > the list. Once it appears to have passed, I'll tag and roll it as 2.4.8. > > A snapshot that can be found in the usual place: > http://www.fastcgi.com/dist/ > > Rob > > ----- Original Message ----- > From: "RK" > To: > Sent: Wednesday, July 29, 2009 9:12 PM > Subject: [FASTCGI] Next release of mod_fastcgi? > > > Hi all, > > I found this message in the archives: > http://mailman.pins.net/mailman/private.cgi/fastcgi-developers/2008-November/000109.html > > It mentions a snapshot release to fix an incompatibility with > mod_deflate (which it does, thanks :-) ), but leaves me wondering when > this will make it into a 'proper' release. > > Is there a plan for when this will happen? > Is it on hold pending some other development, or has it simply not been > called for? > > > Thanks, > > Ronan > _______________________________________________ > FastCGI-developers mailing list > FastCGI-developers at mailman.fastcgi.com > http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers > From nicktook at gmail.com Thu Jul 30 11:47:24 2009 From: nicktook at gmail.com (Bryan White) Date: Thu, 30 Jul 2009 11:47:24 -0400 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <395501.64461.qm@web35302.mail.mud.yahoo.com> References: <679592.73872.qm@web35307.mail.mud.yahoo.com> <4A6EDB48.9070301@aron.ws> <395501.64461.qm@web35302.mail.mud.yahoo.com> Message-ID: <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com> On Tue, Jul 28, 2009 at 7:32 AM, Jean-Christophe Roux wrote: > Aron, > >>> (2) Does it make a difference that the process is a static or a dynamic >>> one in order to make sure the older version of my app is completely removed? >>Normally no ... > Once I have killed the running processes, what prevents the FastCgi Manager > from spawning new processes which could be the older version of my program. > Isn't there a way to send a message straight to the  FastCgi Process Manager > for Apache who would do the job (better than me most probably). > > How do you guys handle that step of switching to a newer version of your > app? What I do is at application startup I record the modtime of the executable. Then before handling each request I compare that with the current modtime. If it has changed the app terminates before accepting the connection. I perform the check between the time that the listen socket becomes readable and accepting the connection. The process manager restarts the app and does not seem to miss a beat. When I have a new version is install by just moving the new version into place. Note, a 'mv' is atomic. A 'cp' could cause all sorts of problems. This approach has been working for me for 9 years. -- Bryan White From fastcgi-developers at wilber.pointclark.net Thu Jul 30 17:00:29 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Fri, 31 Jul 2009 07:00:29 +1000 Subject: [FASTCGI] Kill fastcgi process References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com> Message-ID: <00bb01ca1158$c53e2920$e701a8c0@cu> "Bryan White" writes... ["When I have a new version is install by just moving the new version into place. Note, a 'mv' is atomic. A 'cp' could cause all sorts of problems."] So is it better than to use mv to overwrite a file then to use cp to overwrite the file? Whats the difference? What is the shell/OS doing different for a move Vs a copy? From unique at idempot.net Thu Jul 30 17:25:08 2009 From: unique at idempot.net (Matthew Weigel) Date: Thu, 30 Jul 2009 16:25:08 -0500 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <00bb01ca1158$c53e2920$e701a8c0@cu> References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com> <00bb01ca1158$c53e2920$e701a8c0@cu> Message-ID: <4A720FB4.8000908@idempot.net> Matt wrote: > "Bryan White" writes... > ["When I have a new version is install by just moving the new version > into place. Note, a 'mv' is atomic. A 'cp' could cause all sorts of > problems."] > So is it better than to use mv to overwrite a file then to use cp to overwrite the file? Whats the difference? What is the shell/OS > doing different for a move Vs a copy? It depends, actually. If I recall correctly, within a single filesystem, 'mv' is - internally - just renaming the file. On the other hand, 'cp' creates a new file, and then copies the data from the original file to the new file. Crossing filesystem boundaries, mv behaves the same as cp, except that it deletes the source file afteward. When you need to cross filesystem boundaries (typical filesystems are /, /usr, /home, /var, /tmp - but this really varies quite a bit), it is better to cp the file to some temporary file within the target filesystem, and then mv it to its final destination. -- Matthew Weigel hacker unique & idempot . ent From fastcgi-developers at wilber.pointclark.net Thu Jul 30 18:52:59 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Fri, 31 Jul 2009 08:52:59 +1000 Subject: [FASTCGI] Kill fastcgi process References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com><00bb01ca1158$c53e2920$e701a8c0@cu> <4A720FB4.8000908@idempot.net> Message-ID: <00c501ca1168$7d0faa10$e701a8c0@cu> Matthew writes... ["Matt wrote: > "Bryan White" writes... > ["When I have a new version is install by just moving the new version > into place. Note, a 'mv' is atomic. A 'cp' could cause all sorts of > problems."] > So is it better than to use mv to overwrite a file then to use cp to overwrite the file? Whats the difference? What is the shell/OS > doing different for a move Vs a copy? It depends, actually. If I recall correctly, within a single filesystem, 'mv' is - internally - just renaming the file. On the other hand, 'cp' creates a new file, and then copies the data from the original file to the new file. Crossing filesystem boundaries, mv behaves the same as cp, except that it deletes the source file afteward. When you need to cross filesystem boundaries (typical filesystems are /, /usr, /home, /var, /tmp - but this really varies quite a bit), it is better to cp the file to some temporary file within the target filesystem, and then mv it to its final destination."] ================================================ Let's see if I have this correct. cp is doing some like: ofstream fout; fout.open("somefile.txt"); fout.write(data, length); fout.close(); While mv is just manipulating the file system tables? So if some other process had somefile.txt open for input and was still reading from it, a cp would interrupt that process but an mv would allow that process to finish? From unique at idempot.net Fri Jul 31 01:12:40 2009 From: unique at idempot.net (Matthew Weigel) Date: Fri, 31 Jul 2009 00:12:40 -0500 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <00c501ca1168$7d0faa10$e701a8c0@cu> References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com><00bb01ca1158$c53e2920$e701a8c0@cu> <4A720FB4.8000908@idempot.net> <00c501ca1168$7d0faa10$e701a8c0@cu> Message-ID: <4A727D48.7020807@idempot.net> Matt wrote: > Let's see if I have this correct. cp is doing some like: > ofstream fout; > fout.open("somefile.txt"); > fout.write(data, length); > fout.close(); > > While mv is just manipulating the file system tables? > > So if some other process had somefile.txt open for input and was still reading from it, a cp > would interrupt that process but an mv would allow that process to finish? Yes. I mean, it depends on the particular system to some extent, but this is why operating systems provide locking mechanisms. It doesn't really matter what the exact behavior is... what matters is that you don't know, so you like files you think other processes might be touching. :-) -- Matthew Weigel hacker unique & idempot . ent From fastcgi-developers at wilber.pointclark.net Fri Jul 31 01:47:47 2009 From: fastcgi-developers at wilber.pointclark.net (Matt) Date: Fri, 31 Jul 2009 15:47:47 +1000 Subject: [FASTCGI] Kill fastcgi process References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com><00bb01ca1158$c53e2920$e701a8c0@cu><4A720FB4.8000908@idempot.net> <00c501ca1168$7d0faa10$e701a8c0@cu> <4A727D48.7020807@idempot.net> Message-ID: <013a01ca11a2$6f243b20$e701a8c0@cu> Matthew writes... ["Matt wrote: > Let's see if I have this correct. cp is doing some like: > ofstream fout; > fout.open("somefile.txt"); > fout.write(data, length); > fout.close(); > > While mv is just manipulating the file system tables? > > So if some other process had somefile.txt open for input and was still reading from it, a cp > would interrupt that process but an mv would allow that process to finish? Yes. I mean, it depends on the particular system to some extent, but this is why operating systems provide locking mechanisms. It doesn't really matter what the exact behavior is... what matters is that you don't know, so you like files you think other processes might be touching. :-)"] So you lock files you think other processes might be touching? What locking mechanisms are available in a Linux environment(C++)? From unique at idempot.net Fri Jul 31 02:16:16 2009 From: unique at idempot.net (Matthew Weigel) Date: Fri, 31 Jul 2009 01:16:16 -0500 Subject: [FASTCGI] Kill fastcgi process In-Reply-To: <013a01ca11a2$6f243b20$e701a8c0@cu> References: <679592.73872.qm@web35307.mail.mud.yahoo.com><4A6EDB48.9070301@aron.ws><395501.64461.qm@web35302.mail.mud.yahoo.com> <649cb4eb0907300847s2e78996cy476e0e8ab573dd87@mail.gmail.com><00bb01ca1158$c53e2920$e701a8c0@cu><4A720FB4.8000908@idempot.net> <00c501ca1168$7d0faa10$e701a8c0@cu> <4A727D48.7020807@idempot.net> <013a01ca11a2$6f243b20$e701a8c0@cu> Message-ID: <4A728C30.9040203@idempot.net> Matt wrote: > So you lock files you think other processes might be touching? What locking > mechanisms are available in a Linux environment(C++)? Linux supports the BSD flock() mechanism, as well as the POSIX lockf(). They both require file descriptors, which are lower-level than iostream stuff; Boost provides a file_lock class, but I haven't used it and you'd need to consult the Boost documentation for that. -- Matthew Weigel hacker unique & idempot . ent