New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shutdown/halt service? #1971

Open
dhgwilliam opened this Issue Feb 10, 2016 · 17 comments

Comments

Projects
None yet
@dhgwilliam

dhgwilliam commented Feb 10, 2016

Is there a correct way to stop all keybase services? keybase ctl stop doesn't affect the GUI or the fuse daemon, as far as I can tell.

so far I've been doing:

keybase ctl stop
pkill Keybase
sudo umount /keybase
@cjb

This comment has been minimized.

Show comment
Hide comment
@cjb

cjb Feb 10, 2016

Contributor

That looks about right, but I'd expect pkill kbfsfuse rather than sudo umount /keybase.

Contributor

cjb commented Feb 10, 2016

That looks about right, but I'd expect pkill kbfsfuse rather than sudo umount /keybase.

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Feb 10, 2016

Contributor

If you're on Linux, take a look at the first half of /usr/bin/run_keybase:

# Editing out all the echoes...
killall Keybase
fusermount -uz /keybase
killall kbfsfuse
killall keybase

I think the fusermount step is important -- I'm told scary things can happen if you umount a FUSE mount, but I don't know what they are.

Contributor

oconnor663 commented Feb 10, 2016

If you're on Linux, take a look at the first half of /usr/bin/run_keybase:

# Editing out all the echoes...
killall Keybase
fusermount -uz /keybase
killall kbfsfuse
killall keybase

I think the fusermount step is important -- I'm told scary things can happen if you umount a FUSE mount, but I don't know what they are.

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Feb 10, 2016

Contributor

(Maybe I should be using pkill instead of killall there? How standard is pkill?)

Contributor

oconnor663 commented Feb 10, 2016

(Maybe I should be using pkill instead of killall there? How standard is pkill?)

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Feb 10, 2016

Contributor

At some point I'd like to publish a systemd unit for all this stuff. I don't think we could rely on it by default, but folks on compatible distros who want to use systemctl could have the option. (Would need some way to suppress autofork in that case maybe?)

Contributor

oconnor663 commented Feb 10, 2016

At some point I'd like to publish a systemd unit for all this stuff. I don't think we could rely on it by default, but folks on compatible distros who want to use systemctl could have the option. (Would need some way to suppress autofork in that case maybe?)

@cjb

This comment has been minimized.

Show comment
Hide comment
@cjb

cjb Feb 10, 2016

Contributor

pkill's more broad (pattern matching on various fields, not solely on the process name) so I think we're right to use killall.

Contributor

cjb commented Feb 10, 2016

pkill's more broad (pattern matching on various fields, not solely on the process name) so I think we're right to use killall.

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Feb 10, 2016

Contributor

Hmm, there's this from man pkill:

-f, --full
       The pattern is normally only matched against the process name.  When -f is set, the full command line is used.
Contributor

oconnor663 commented Feb 10, 2016

Hmm, there's this from man pkill:

-f, --full
       The pattern is normally only matched against the process name.  When -f is set, the full command line is used.
@cjb

This comment has been minimized.

Show comment
Hide comment
@cjb

cjb Feb 10, 2016

Contributor

By default pkill matches on even more than that (e.g. the pid).

Contributor

cjb commented Feb 10, 2016

By default pkill matches on even more than that (e.g. the pid).

@pirafrank

This comment has been minimized.

Show comment
Hide comment
@pirafrank

pirafrank Jun 18, 2016

on OSX 11.11.5 umounting from GUI has almost no effect, the drive is quickly mounted after 1s. killing everything (both from cli or Activity Monitor) still leaves the drive mounted.

Options to stop GUI, ctl and umounting the drive should be available ootb.

pirafrank commented Jun 18, 2016

on OSX 11.11.5 umounting from GUI has almost no effect, the drive is quickly mounted after 1s. killing everything (both from cli or Activity Monitor) still leaves the drive mounted.

Options to stop GUI, ctl and umounting the drive should be available ootb.

@chrisfosterelli

This comment has been minimized.

Show comment
Hide comment
@chrisfosterelli

chrisfosterelli Jun 21, 2016

It would be nice to have a way to turn off the filesystem or service! I don't use the keybase filesystem features, and even after closing keybase there are three processes using over 500GB of virtual RAM each. For some reason this always makes the OSX UI slow so I've uninstalled keybase.

chrisfosterelli commented Jun 21, 2016

It would be nice to have a way to turn off the filesystem or service! I don't use the keybase filesystem features, and even after closing keybase there are three processes using over 500GB of virtual RAM each. For some reason this always makes the OSX UI slow so I've uninstalled keybase.

@schlomo

This comment has been minimized.

Show comment
Hide comment
@schlomo

schlomo Jun 30, 2016

+1 for way to shut down keybase and use it only when I need it.

Better support this wish than have people removing keybase because it bothers them.

schlomo commented Jun 30, 2016

+1 for way to shut down keybase and use it only when I need it.

Better support this wish than have people removing keybase because it bothers them.

@sjug

This comment has been minimized.

Show comment
Hide comment
@sjug

sjug Sep 10, 2016

Why is this not a thing? How is keybase even starting up I don't see a systemd unit for it?

sjug commented Sep 10, 2016

Why is this not a thing? How is keybase even starting up I don't see a systemd unit for it?

@oconnor663

This comment has been minimized.

Show comment
Hide comment
@oconnor663

oconnor663 Sep 10, 2016

Contributor

We haven't taken a systemd dependency yet, though we might in the future. Right now we use ~/config/.autostart/keybase_autostart.desktop to start our 3 services (the keybase daemon, the kbfsfuse mount, and the GUI). If you want to disable autostart, there's a comment in that file about how to do it. (You can't just delete the file, though, because it'll get recreated.)

I do have the following function in my shell, for emergencies. Not guaranteed to be stable, of course:

kbdown () {
        if killall Keybase &> /dev/null
        then
                echo Shutting down Keybase GUI...
        fi
        if fusermount -uz /keybase &> /dev/null
        then
                echo Unmounting /keybase...
        fi
        if killall kbfsfuse &> /dev/null
        then
                echo Shutting down kbfsfuse...
        fi
        if killall keybase &> /dev/null
        then
                echo Shutting down keybase service...
        fi
}

@cjb, do you know what the current thinking is about whether quitting in the GUI should kill keybase/kbfsfuse?

Contributor

oconnor663 commented Sep 10, 2016

We haven't taken a systemd dependency yet, though we might in the future. Right now we use ~/config/.autostart/keybase_autostart.desktop to start our 3 services (the keybase daemon, the kbfsfuse mount, and the GUI). If you want to disable autostart, there's a comment in that file about how to do it. (You can't just delete the file, though, because it'll get recreated.)

I do have the following function in my shell, for emergencies. Not guaranteed to be stable, of course:

kbdown () {
        if killall Keybase &> /dev/null
        then
                echo Shutting down Keybase GUI...
        fi
        if fusermount -uz /keybase &> /dev/null
        then
                echo Unmounting /keybase...
        fi
        if killall kbfsfuse &> /dev/null
        then
                echo Shutting down kbfsfuse...
        fi
        if killall keybase &> /dev/null
        then
                echo Shutting down keybase service...
        fi
}

@cjb, do you know what the current thinking is about whether quitting in the GUI should kill keybase/kbfsfuse?

@AloisMahdal

This comment has been minimized.

Show comment
Hide comment
@AloisMahdal

AloisMahdal Sep 22, 2016

If anyone wants to try out, I just wrote my first shot at keybase user unit files; placed them under /keybase/netvor/systemd-user.

Disclaimer: I'm just learning systemd; I'm almost sure I've missed something. The services are able to start but I haven't yad yet opportunity to try and re-login to see if they work properly. So, feedback is more than welcome; I'll update the files on the go. Also I'll gladly PR them somewhere if anybody tells me where.

AloisMahdal commented Sep 22, 2016

If anyone wants to try out, I just wrote my first shot at keybase user unit files; placed them under /keybase/netvor/systemd-user.

Disclaimer: I'm just learning systemd; I'm almost sure I've missed something. The services are able to start but I haven't yad yet opportunity to try and re-login to see if they work properly. So, feedback is more than welcome; I'll update the files on the go. Also I'll gladly PR them somewhere if anybody tells me where.

@gravyboat

This comment has been minimized.

Show comment
Hide comment
@gravyboat

gravyboat Oct 10, 2016

I'll add a 👍 for having this actually be managed. I don't use the filesystem at all and don't want to. I just want the command line (not to mention the resource usage by keybase when I'm not even using it). This should definitely be considered a service and not a desktop startup script. Even if it remains as a desktop startup script it needs to be documented more thoroughly, it took me several minutes of Googling before I found the right term to get to this issue.

gravyboat commented Oct 10, 2016

I'll add a 👍 for having this actually be managed. I don't use the filesystem at all and don't want to. I just want the command line (not to mention the resource usage by keybase when I'm not even using it). This should definitely be considered a service and not a desktop startup script. Even if it remains as a desktop startup script it needs to be documented more thoroughly, it took me several minutes of Googling before I found the right term to get to this issue.

@rkujawa

This comment has been minimized.

Show comment
Hide comment
@rkujawa

rkujawa Jan 12, 2017

Hey hackers, I've also tried to manage keybase processes with systemd, but ran into minor issue with restarting of keybase process after updates. Maybe some of you will have ideas regarding issue #5355 ?

rkujawa commented Jan 12, 2017

Hey hackers, I've also tried to manage keybase processes with systemd, but ran into minor issue with restarting of keybase process after updates. Maybe some of you will have ideas regarding issue #5355 ?

@panicbit

This comment has been minimized.

Show comment
Hide comment
@panicbit

panicbit May 2, 2018

keybase ctl app-exit works

panicbit commented May 2, 2018

keybase ctl app-exit works

@arderyp

This comment has been minimized.

Show comment
Hide comment
@arderyp

arderyp Jul 10, 2018

can this be closed? @panicbit's solution (keybase ctl app-exit) worked for me

On another note, for those of us who don't load KB on boot, keybase ctl app-start would be nice as well

arderyp commented Jul 10, 2018

can this be closed? @panicbit's solution (keybase ctl app-exit) worked for me

On another note, for those of us who don't load KB on boot, keybase ctl app-start would be nice as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment