>>> Dejan Muhamedagic <[email protected]> schrieb am 01.02.2013 um 13:01 in
Nachricht <[email protected]>:
> On Fri, Feb 01, 2013 at 09:47:21AM +0100, Ulrich Windl wrote:
> > >>> Dejan Muhamedagic <[email protected]> schrieb am 01.02.2013 um 08:53 
> > >>> in
> > Nachricht <[email protected]>:
> > > Hi,
> > > 
> > > On Fri, Feb 01, 2013 at 08:24:46AM +0100, Ulrich Windl wrote:
> > > > Hi!
> > > > 
> > > > While trying to develop an improved exportfs RA that can export one 
> > > filesystem to a list of names (instead of just one name), I found an 
> error:
> > > > 
> > > > exportfs is returning exit code 0 even if the filesystem could not be 
> > > exported, like in
> > > > 
> > > > > h02:~ # exportfs h012:/mnt; echo $? # h012 does not exist
> > > > > exportfs: Failed to resolve h012 
> > > > > 0 
> > > > 
> > > > Accordingly the start operation for the exportfs alway reports success, 
> > > even if the operation failed! That's due to
> > > > 
> > > > [...]
> > > > >         ocf_run exportfs -v ${OPTIONS} 
> > > ${OCF_RESKEY_clientspec}:${OCF_RESKEY_directory} || exit $OCF_ERR_GENERIC 
> > >  
> 
> > >   
> > > > >     
> > > > >         # Restore the rmtab to ensure smooth NFS-over-TCP failover    
> > > > >         restore_rmtab    
> > > > >     
> > > > >         ocf_log info "File system exported"    
> > > > >         return $OCF_SUCCESS    
> > > > [...]
> > > > 
> > > > However the monitor operation does the correct thing, thus reporting an 
> > > error (rc==7).
> > > 
> > > We could insert the monitor operation after the call to exportfs.
> > > Would there be any timing issues? I guess not.
> > > 
> > > Thanks,
> > > 
> > > Dejan
> > 
> > Hi!
> > 
> > I'd fix the root of the problem: exportfs is unreliable!
> 
> That also, but it is probably going to take some time. Did you
> open a bugzilla somewhere?

Hi,

yes I did, but it didn't really help 8-(

Regards,
Ulrich


> 
> Thanks,
> 
> Dejan
> 
> > Regards,
> > Ulrich
> > 
> > 
> > 
> > > 
> > > > This combination leads to the message of ocf-tester:
> > > > * rc=1: Monitoring an active resource should return 0      
> > > > 
> > > > (The tester thinks the resource was started when it was not)
> > > > 
> > > > I had reported this for SLES10 SP2 to support in November, but after a 
> long 
> > > time of waiting and repeating the same facts over and over, support told 
> me 
> > > it's "working as designed"; lvscan and lvcreate would be similar.
> > > > 
> > > > A quick test showed that this is actually not true vor lvcreate:
> > > > # lvcreate -n bar -L40G foobar; echo $?
> > > >   Volume group "foobar" not found
> > > > 5
> > > > # lvcreate -n foo -L1T sys; echo $?
> > > >   Volume group "sys" has insufficient free space (1855 extents): 32768 
> > > required.
> > > > 5
> > > > 
> > > > I got the impression that my support is just unwilling to fix the 
> > > > rather 
> > > trivial problem. My exportfs comes from nfs-kernel-server-1.2.3-18.23.1.
> > > > 
> > > > Getting the exportfs sources, it took me two minutes to find out that 
> > > exportfs uses variable export_errno to define the exit code, and that 
> > > variable is nowhere set. The worker routine exportfs() does return 
> > > nothing 
> at 
> > > all. What a design!
> > > > 
> > > > Here's an example from an old HP-UX system that didn't get any updates 
> > > > for 
> 
> > > three years:
> > > > 
> > > > # exportfs nohost:/mnt; echo $?
> > > > exportfs: no entry for nohost:/mnt in /etc/dfs/dfstab
> > > > 1
> > > > 
> > > > Here it works!
> > > > 
> > > > I wonder why some Linux people are so ignorant occasionally...
> > > > 
> > > > Regards,
> > > > Ulrich
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Linux-HA mailing list
> > > > [email protected] 
> > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha 
> > > > See also: http://linux-ha.org/ReportingProblems 
> > > _______________________________________________
> > > Linux-HA mailing list
> > > [email protected] 
> > > http://lists.linux-ha.org/mailman/listinfo/linux-ha 
> > > See also: http://linux-ha.org/ReportingProblems 
> > > 
> > 
> >  
> >  
> > 
> > _______________________________________________
> > Linux-HA mailing list
> > [email protected] 
> > http://lists.linux-ha.org/mailman/listinfo/linux-ha 
> > See also: http://linux-ha.org/ReportingProblems 
> _______________________________________________
> Linux-HA mailing list
> [email protected] 
> http://lists.linux-ha.org/mailman/listinfo/linux-ha 
> See also: http://linux-ha.org/ReportingProblems 
> 

 
 
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to