Date: Mon, 22 Sep 1997 22:06:57 -0400 (EDT) From: Stanley Gambarin <email@example.com> To: fastcgi-developers@OpenMarket.com Subject: some thoughts about starting process manager... Message-Id: <Pine.GSO.3.96.970922213911.26078A-100000@csa> I was just thinking about some stuff and I thought other people maybe interested in it... The code for the starting of the process manager in Apache's mod_fastcgi was changed in 2.0.x to perform the following... - the process manager gets invoked in the stage when the configuration files are read (ModFastCGIInit()). This constituted a problem since the config files are read by the Apache twice on the startup. I had put in some code not to start the process manager during the first time (since it was previously causing a lot of FCGI processes to be parentless, when the process manager was killed). However, the following situation is still a problem: - start the server without any AppClass - edit config files to add AppClass directives - send server SIGHUP/SIGUSR1 I am pretty sure that the server will not start the process manager (although... i am writing this from memory) The process manager will think this is a first time config files are being read and it will NOT fork/exec process manager, so none of the FCGI apps will get started. However, sending it another SIGHUP would make it start the process manager and all FCGI apps. This maybe related to the problem that one of the people on th list had reported (sorry, email was accidentally deleted). I just want people to be aware of this problem (if it is one) The proper fix would be to move start of the process manager to the child_init() phase of the apache server, but that's also no good because: - still have the same problem of when do I need to terminate/restart the process manager (since new information is in the config files) - and how to do it with graceful restarts ??? - this also breaks the backward compatibility with the Apache 1.1.x series, where child_init() phase is not present.. oh well.. Stanley.