[Gluster-devel] 2.0.0rc4 (and rc5) locks up when used as root

[Harshavardhana]

Gordan,

    were the permissions changed being over replicate by any chance?. can
you write an additional script to check for the permission of files or
atleast have a dump to compare permissions over replicate and without it.

Regards
--
Harshavardhana
"Yantra Shilpi"
Z Research Inc - http://www.zresearch.com



On Fri, Mar 20, 2009 at 11:46 PM, Gordan Bobic <gordan at bobich.net> wrote:

> As suspected, chmod -x /etc/sysconfig/modules/udev-stw.modules fixes the
> immediate problem. It would appear things like:
>
> for file in /etc/sysconfig/modules/*.modules ; do
>  [ -x $file ] && $file
> done
>
> seem to cause it to lock up.
>
> Unfortunately, that sort of thing happens all over the place in the boot
> scripts, and now it locks up a few steps later. The last version this worked
> with was rc2 (possibly rc3, I haven't tested it). It's definitely not
> working on rc4 and rc5.
>
> Gordan
>
>
> Gordan Bobic wrote:
>
>> Anand Avati wrote:
>>
>>> It looks like it locks up when used as root (afr/replicate) at the point
>>>> where it initially starts up udev (not 100% sure where exactly yet, will
>>>> have to put some trace code in rc.sysinit).
>>>>
>>>> 2.0.0rc2 didn't have this problem.
>>>>
>>>>
>>> Can you try rc5? Though still it is still under QA, you might want to
>>> give it a try since some transport related code changes have gone it
>>> which might be the reason for your lockup.
>>>
>>
>> The lock-up still occurs with rc5.
>>
>> I've done some more digging, however. It appears to die at this pint in
>> rc.sysinit, between debug 3 and debug 4:
>>
>> #################
>> echo "debug 3"
>> # Load other user-defined modules
>> for file in /etc/sysconfig/modules/*.modules ; do
>>  [ -x $file ] && $file
>> done
>>
>> # Load modules (for backward compatibility with VARs)
>> if [ -f /etc/rc.modules ]; then
>>        /etc/rc.modules
>> fi
>> echo "debug 4"
>> #################
>>
>> There is no rc.modules file, so contents of that can be ruled out.
>>
>> # ls -l /etc/sysconfig/modules/
>> total 8
>> -rwxr-xr-x 1 root root 100 May 25  2008 udev-stw.modules
>>
>> # cat /etc/sysconfig/modules/udev-stw.modules
>> #!/bin/sh
>> for i in nvram floppy parport lp snd-powermac;do
>>        modprobe $i >/dev/null 2>&1
>> done
>>
>> I have just rebuilt my initrds separately with rc2 and rc5. rc2 works
>> fine, rc5 fails. No other changes to the system between the two attempts.
>>
>> Oh, and the first access failure bug is still there.
>>
>> I couldn't test for the memory leak in rc5 since I couldn't get it to boot
>> due to the lock-up mentioned above.
>>
>> I'll try disabling those modules listed above since I don't need them on
>> this setup, but I can confirm that modprobe itself works fine. So it sounds
>> like a problem/bug elsewhere. Possibly a buffer-overrun somewhere that gets
>> triggered by rc4/rc5.
>>
>> BTW, in case it's relevant, I'm using the fuse kernel module from
>> 2.6.24.7, rather than the one from the patched package, because the one in
>> the kernel appears to be later. Can anyone confirm if there are any known
>> problems with this? Is there any strong reason why I should use a different
>> kernel module (e.g. one from the patched fuse 2.7.4 package)?
>>
>> Gordan
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090321/e7612578/attachment-0003.html>