[OpenAFS] Salvage and .gconf lock and other problems with OpenAFS 1.2.10 and 1.2.11

[Renata Maria Dart]

Hi Derrick, 

>> So, I did a ctl-C to stop it.  At this point the fileserver process
>> jumped up to use 100% of of one of our cpus (there are 2 on a 280R).
>> I noticed that there was still a salvage-tmp process in the output
>> of bos status and there were 2 salvage processes running.  So, I did
>> a bos shutdown of salvage-tmp.  But, the salvage processes continued
>> to run, accumulating no cpu time.   So I killed these 2 processes.
>> But the fileserver continued to take all of one cpu.  Top showed
>> it to be all in user, very little in kernel.  While the fileserver
>> was using so much cpu, no vos commands would complete.
>>
>> I ended up doing a bos shutdown, which responded quickly and cleanly.
>> I upgraded to 1.2.11 and rebooted the system.
>
>no guesses on this one, either, at least not without more information.
>

I do have 3 runs of showProcInfo for the high cpu fileserver situation.
Would they be of any help?



>> Does anyone have any ideas about the .gconf lock file being unremovable
>> after a fileserver crash?  Should that hard link be there in a normal
>
>*if* the problem is caused by a fileserver restart (crash would be a
>subset of that) perhaps it would make sense. peoploe have reported this
>problem without a fileserver crash and i didn't think of "did the
>fileserver restart".
>
>basically, a reproducible test case would go miles towards finding an
>answer.

I think there are two .gconf lock file issues going on.  The one is where 
a gnome user finds a lock file that needs to be removed before they can 
launch their gnome session, they remove the lock file, and then they can 
proceed.  We have been experiencing that for some time now and we haven't 
seen any obvious connection with an event that might cause it.  The other 
more recent .gconf problem that we have been seeing concerns the same lock 
file that needs to be removed before the user can launch a gnome session, 
but in this new case the lock file can't be removed unless the users home 
directory is salvaged.  This latest problem seems to be connected with 
unclean fileserver restarts. 

Then, in addition, when we bos salvage to fix the unremovable lock, on at 
least two occasions the bos salvage has run amok and refused to complete 
as I described in my previous mail....with the unpleasant side-effect of 
the high cpu usage by the fileserver and consequent loss of vos capability.

Thanks for dealing with my lengthy email,

Renata

>
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info

 Renata Dart                         | renata@SLAC.Stanford.edu  
 Stanford Linear Accelerator Center  |    
 2575 Sand Hill Road, MS 97          | (650) 926-2848 (office)
 Stanford, California   94025        | (650) 926-3329 (fax)