I use gentoo and it's init scripts do stop all the daemons too. I never use it though.

Pat.

On 10/04/2013 10:58 AM, Joe Julian wrote:
I just discovered yesterday that the systemd configs (in the fedora rpms) do, indeed, stop the bricks. I think I know how to fix that and will test that and submit a bug report today and a patch.

Patrick Irvine <[email protected]> wrote:

    Hey,

    stopping the glusterd instance does not stop any of the other
    spawned daemons.  I know this for a fact as I start and stop
    glusterd all the time with out it affecting any of the other daemons.

    As for stopping the spawned daemons, Craig Carl ??  ( I think
    that's right)  years ago when glusterd first came out said to just
    kill <pid> each of the others.  To restart them your just stop and
    restart the glusterd process and it will respawn any it finds are
    not already running.

    Hope this helps,

    Pat.

    On 10/04/2013 9:54 AM, Jay Vyas wrote:
    This is a great question, something I've been wondering.

    Reposting some details from jeff darcy's email regarding a
    similar question which i asked could help shed some light on this:

    1) The daemons that run in gluster are:

    glusterd = management daemon
            glusterfsd = per-brick daemon
            glustershd = self-heal daemon
    glusterfs = usually client-side, but also NFS on servers

    2) The lifecycle of the daemons:
    *** The others are all started from glusterd, in response to
    volume start and stop commands ***
    *** They're actually all the same executable with different
    translators ***
    *** glusterfs-server = the server side gluster implementation,
    which needs to be instaled for serving gluster data ***

    3) When glusterd starts up: It spawns any daemons that "should"
    be running (according to which volumes are started, which have
    NFS or replication enabled, etc.) and seem to be missing.


    So...

    If thats the case then I would say that ***stopping glusterd***
    should invert the "starting" of the above processes ... right?
    But I would leave it to the gluster vets to answer this
    definitively...




    On Wed, Apr 10, 2013 at 11:51 AM, Guido De Rosa
    <[email protected] <mailto:[email protected]>> wrote:

        Hello list,

        I've installed GlusterFS via Debian experimental packages,
        version
        3.4.0~qa9realyalpha2-1.

        ( For the records, the reason I use an alpha release is that
        I want
        this feature:
        
http://raobharata.wordpress.com/2012/10/29/qemu-glusterfs-native-integration/
        )

        I've also followed the Quick Start Guide and now I have a
        cluster of 2
        virtual machines, each contributing to a Gluster volume with
        one brick
        each.

        Now my issue:

        Let's assume no machine has actually mounted the Gluster volume.

        If I do:

            ps aux | grep gluster

        I get a couple of daemons: glusterd, glusterfsd, glusterfs.

        If I do:

            /etc/init.d/glusterfs-server stop

        I find (re-issuing ps) that glusterd has been terminated BUT
        the other
        processes (glusterfs and glusterfsd instances) *are still
        running*.

        (The same happens if I manually kill the glusterd process).

        Is this normal? Doesn't this leave the system in an inconsistent
        state? (For example on system shutdown).

        Should the init script be fixed? (maybe including "gluster volume
        stop" or something)?

        What's the best practice to terminate *all* Gluster related
        process
        (especially on system shutdown/reboot)?

        Thanks,
        Guido
        _______________________________________________
        Gluster-users mailing list
        [email protected] <mailto:[email protected]>
        http://supercolony.gluster.org/mailman/listinfo/gluster-users




-- Jay Vyas
    http://jayunit100.blogspot.com


    _______________________________________________
    Gluster-users mailing list
    [email protected]
    http://supercolony.gluster.org/mailman/listinfo/gluster-users

    ------------------------------------------------------------------------

    Gluster-users mailing list
    [email protected]
    http://supercolony.gluster.org/mailman/listinfo/gluster-users


_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Reply via email to