Gluster users - May 2011 - Best practice to stop the Gluster CLIENT process?

Hi all!

What's the best way to stop the CLIENT process for Gluster?

We have dual systems, where the Gluster servers also act as clients, so
both, glusterd and glusterfsd are running on the system.

Stopping the server app. works via "/etc/init.d/glusterd stop" but the
client is stopped how? 

I need to unmount the filesystem from the server in order to do a fsck on
the ext4 volume; we have the "needs_recovery" flag set. But the client
is
hogging it as well due to the log files being located on the volume (might
be a good idea to log somewhere else...)

Any pointers welcome, I find it difficult to obtain "simple"
instructions
like this from the Gluster pages.

Even google doesn't help, sigh. Or I'm too blind...

Best, Martin

Martin,

Would it work to just umount the share that the client is working through?
That is, if you have

 mount -t glusterfs localhost:/blah /mnt/blah

then

 umount /mnt/blah

should get the client out of your way, right? Doesn't take it out of the
process list, but it should be concerned with your ext4 volume after that,
that I can see.

Whit

On Fri, May 06, 2011 at 06:15:14PM +0200, Martin Schenker
wrote:
> Hi all!
> 
> What's the best way to stop the CLIENT process for Gluster?
> 
> We have dual systems, where the Gluster servers also act as clients, so
> both, glusterd and glusterfsd are running on the system.
> 
> Stopping the server app. works via "/etc/init.d/glusterd stop"
but the
> client is stopped how? 
> 
> I need to unmount the filesystem from the server in order to do a fsck on
> the ext4 volume; we have the "needs_recovery" flag set. But the
client is
> hogging it as well due to the log files being located on the volume (might
> be a good idea to log somewhere else...)
> 
> Any pointers welcome, I find it difficult to obtain "simple"
instructions
> like this from the Gluster pages.
> 
> Even google doesn't help, sigh. Or I'm too blind...
> 
> Best, Martin

Thanks Joe!

...thought so! Thanks for the confirmation. Time to redesign... system was
set up before my time. Oh, well...

Perhaps this should be added in the manual? Or is that already in there and
was overlooked?

Best, Martin

-----Original Message-----
From: Joe Landman [mailto:landman at scalableinformatics.com] 
Sent: Friday, May 06, 2011 10:22 PM
To: Martin Schenker
Subject: Re: [Gluster-users] Best practice to stop the Gluster CLIENT
process?

On 05/06/2011 04:13 PM, Martin Schenker wrote:
> Won't help if it's the logging process itself, I guess?!? Had that
> earlier...
>
> Is it recommended to log somewhere else than the Gluster file system?
Yes.  You should log to a file system on a device that the Gluster file 
system is not on.
>
> Best, Martin
>
> -----Original Message-----
> From: gluster-users-bounces at gluster.org
> [mailto:gluster-users-bounces at gluster.org] On Behalf Of Joe Landman
> Sent: Friday, May 06, 2011 9:36 PM
> To: gluster-users at gluster.org
> Subject: Re: [Gluster-users] Best practice to stop the Gluster CLIENT
> process?
>
> On 05/06/2011 03:14 PM, Martin Schenker wrote:
>> So if I get this right, you'll have to rip the heart out (kill all
gluster
>> processes; server AND client) in order to get to the local server
>> filesystem.
>>
>> I had hoped that the client part could be left running (to the second
> mirror
>> brick) when doing repairs etc. Looks like a wrong assumption, I
guess...
>
> or use fuser/lsof to determine which process is locking which volume.
> Kill only that process.
>
>

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman at scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/sicluster
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615