I remember of having come across similar situation in BLFS-SVN-20061015. But, 
unfortunately, what I don't remember is whether it was apache or something 
else !! I were too busy to make a not of that.

A start up script I tried to execute manually while in single user mode, went 
into an infinite loop and since I were in a hurry, I just had to shut the 
system down !!

I have been wanting to say about the start up scripts in BLFS. BLFS scripts 
simply check for the pid file of the process in question and if the pid file  
doesn't exist, the script does nothing !! A better way would be (this idea is 
stolen from SuSE scripts !! :-))  to check for the pid of running process and 
to confirm it by presence of pid under the /proc tree and then take the 
necessary actions.  

Sometimes, it just happens that, the daemon crashes and the pid file remains. 
Now if you try to restart the process by executing start-up script, it won't 
work as, the start up script would exit with the message "pid file 
exists....." ! In such case, the start-up script should check for the running 
instance of the process and if it doesn't exist, should remove the pid file 
and start the process again.

Similarly, I have come across situations where a pid file is not created, not 
because the script didn't try to create it but because of some other reasons. 
Now the script would check for the presence of pid and believe that the 
process isn't running !!

I have kerberos installed and when the start-up script for kerberos starts at 
boot time, it simply hangs there and never returns !! A close examination 
revealed that, when the start-up script tries to start the process krb5kdc by 
passing the pidfile and executable as arguments to the funxtion loadproc 
defined in /etc/rc.d/init.d/functions, the loadproc functions tries to 
execute it as usual. But it never returns, as the process krb5kdc doesn't 
background itself automatically and hence runs in the foreground !! For this 
to work, I changed the loadproc functions to execute processes in the 
background explicitly by appending an "&" to the line that actually lauches 
the process. 

For some reason, pid file for krb5kdc never gets created ! I haven't been able 
to understand why ! So, whenever I do a reboot or shutdown, krb5kdc never 
gets killed because the pid file doesn't exist !!

The aforementioned behaviour by start-up scripts is true for some while some 
are coded to check the running instance of the process and take the 
appropriate action.

I have modified some of the scripts to take care of such circumstances yet, I 
believe it is possible to code it better !

Let me know if I could be some assistance in this regard.

Thanks.

Kevin


On Saturday 02 December 2006 13:21, Paul G Rogers wrote:
> I found a race condition in LFS-4.1 function killproc(), but the same
> code is found in the LFS-6.1.1 I recently installed.  LFS-6.1.1 may
> provide a workaround I can't test, but it's still a workaround.
>
> The condition is this: when running Apache, it will spawn a number of
> httpd helper daemons, as specified in its config file.  When shutting
> httpd down, killproc gets a list of all the httpd daemons, which it is
> going to try to kill.  Meanwhile, sending a TERM to the first httpd
> daemon will cause it to try kill all its children.  It may successfully
> kill some daemons that killproc will later try to kill, and receive an
> error.  I suggest killproc should check error codes returned by kill, and
> if the pid is already gone, that's acceptable.
>
> It looks like in LFS-6.1.1 the shutdown script could just kill the first,
> and hope it gets all the rest.  But having the shutdown script killing
> any stragglers is also appealing.
>
> Paul Rogers  ([EMAIL PROTECTED])
> http://www.xprt.net/~pgrogers/
> http://www.geocities.com/paulgrogers/
> Rogers' Second Law: "Everything you do communicates."
> (I do not personally endorse any additions after this line. TANSTAAFL
>
> :-)
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to