Sometimes I see a ksfetch process on my Mac. After a little googling I found out that it is Google software updater. However, there is no detailed answer i.e. what is ksfetch process used for? Is it really required? Can I get rid of it? Sometimes it uses my internet bandwidth so it frustrates me hence the query. Thanks.
-
Why not just block KSFetch with Little Snitch by denying connections? Would that work?– FrankFeb 15 '19 at 22:55
Add a comment
|
Keystone Fetch / ksfetch
The ksfetch process on OS X is part of Google Chrome's update mechanism. The ks prefix is an abbreviation of Keystone. The process appears to be responsible for fetching updates to Google's products. It is this role that uses your bandwidth.
Using slick's answer you can disable the corresponding process that uses ksfetch.
Alternatively, it appears possible to adjust the frequency of update checks:
Entering the following code into your terminal will make it check once a week rather than every few hours:
defaults write com.google.Keystone.Agent checkInterval 604800
To learn more about, follow the links below:
answered Sep 29 '15 at 8:24
-
What I find troubling is that it tries to access a cryptic domain at gvt1.com. Dec 15 '16 at 0:28
-
-
2As of today, the longest possible period is 24 hours, i.e. a value of 86400 (support.google.com/chrome/answer/6315311?hl=en).– huhJan 8 '17 at 15:10
Yes, you can disable it.
To do this just for you in Terminal type:
~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py --uninstall
for all users:
/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py --uninstall
On some machines it's ksinstall instead of install.py.
answered Sep 29 '15 at 6:12
-
Thanks. Can you also answer other parts of the question like what is this process used for? Is it required? etc. Sep 29 '15 at 7:59
-
3
-
/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/install.py: No such file or directoryNov 12 '20 at 0:27 -
1In bigSur ~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/ksinstall --nuke– vpuenteJan 12 '21 at 16:57
-
@vpuente Thanks for that. I was searching exactly for that and saw that the answear didn't apply anymore. Dec 17 '21 at 0:54
You can uninstall it, type /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall --help to see available options.
--nuke can uninstall everything related to it, just like this: /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall --nuke
-
-
Run that ksinstall --help command, you will find out. <br/>
[--nuke] Remove Keystone and all tickets.[--uninstall] Remove Keystone program files but do NOT delete the ticket store.– YilingJul 12 '16 at 18:14 -
I had already removed it with the
uninstallcommand so I cannot check without reinstalling everything. Thanks! Jul 12 '16 at 19:36 -
They have changed this command to --nuke instead of --uninstall and the path is now different as well. So the new command for all users would be:
/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources/ksinstall --nuke
-
1Welcome to Ask Different. We like answers to stand on their own. Could you either edit this to explain the essence of the solution or perhaps edit the other answer with this update. Bonus points for identifying what version of the app needs the new command argument.– bmike ♦Mar 14 '16 at 14:15
There is an issue with Google Chrome that it creates a temp file to check for updates every x hours. Since it's making a new temp file for some reason it sets off Little Snitch, which is quite annoying.
By entering the following code into Terminal, it will make it check once a week rather than every few hours:
defaults write com.google.Keystone.Agent checkInterval 604800
Hopefully one of the next versions of Google Chrome they will address this, as it is very annoying having to click allow/deny every x hours.
ksinstall didn't seem to do anything, no matter how many incantation of --nuke I used. Nor ksadmin.
This seemed to help:
$ ps -ef | grep ksfetch
501 976 855 0 3:54PM ?? 0:00.09 /Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/ksfetch
then rename it
sudo mv /Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/ksfetch /Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/MacOS/ksfetch.dis
It goes away for "awhile"
If that doesn't work that this seems to help (if it's bandwidth you're concerned with):
$ irb
> loop { sleep 0.5; system("killall ksfetch") }
Software update checks really shouldn't be using noticeable bandwidth or CPU, although actual Updates may, of course.
But this is Google software, a notorious RAM and disk space hog. (If you didn't know that Chrome archives old versions inside the current one, bloating at every update, here's a short summary of to how to fix it). So...
As a fan of the GUI approach, my instinct is always to open the .plist first, located in this case at:
~/Library/Preferences/com.google.Keystone.Agent.plist
Here you can see the default SU checkInterval value is 18000 seconds (5 hours). With a suitable editor, or the terminal command in previous replies, you can change this to eg 604800 (7 days).
However, it's also possible to edit lastCheckStartDate and lastServerCheckDate, which I'm going to experiment with in case this fools Keystone into to laying low until a set date. Here I'm setting them one month in the future to see what happens.
I've had major issues with Keystone in the past (and struggled to kill and completely remove it) and there are websites dedicated to claims that it slows Macs and causes high CPU usage on Window Server.
I can't comment on the current version. For now, I'm hoping that messing with the lastServerCheckDate will put the Keystone dragon to sleep until a predetermined date.
I'll post any insights I gain.
