vim using up 100% CPU, can't kill it
Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:
I ran:
kill 13799
To no effect. I would like to know:
1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.
Thanks )
vim kill top
asked Jan 9 at 13:31
NeilNeil
1162
add a comment |
Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:
I ran:
kill 13799
To no effect. I would like to know:
1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.
Thanks )
vim kill top
asked Jan 9 at 13:31
NeilNeil
1162
kill -9 $(pidof vim)
– kenn
Jan 9 at 13:37
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you haveautoreadenabled? Do you have lots of plugins installed? etc.
– Dan
Jan 9 at 13:41
Maybe clearingvim cachein~/.viminfofix it: stackoverflow.com/questions/2816719/…
– kenn
Jan 9 at 13:55
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57
add a comment |
Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:
I ran:
kill 13799
To no effect. I would like to know:
1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.
Thanks )
vim kill top
asked Jan 9 at 13:31
NeilNeil
1162
Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:
I ran:
kill 13799
To no effect. I would like to know:
1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.
Thanks )
vim kill top
vim kill top
asked Jan 9 at 13:31
NeilNeil
1162
asked Jan 9 at 13:31
NeilNeil
1162
asked Jan 9 at 13:31
NeilNeil
1162
asked Jan 9 at 13:31
NeilNeil
1162
asked Jan 9 at 13:31
NeilNeil
1162
1162
kill -9 $(pidof vim)
– kenn
Jan 9 at 13:37
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you haveautoreadenabled? Do you have lots of plugins installed? etc.
– Dan
Jan 9 at 13:41
Maybe clearingvim cachein~/.viminfofix it: stackoverflow.com/questions/2816719/…
– kenn
Jan 9 at 13:55
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57
add a comment |
kill -9 $(pidof vim)
– kenn
Jan 9 at 13:37
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you haveautoreadenabled? Do you have lots of plugins installed? etc.
– Dan
Jan 9 at 13:41
Maybe clearingvim cachein~/.viminfofix it: stackoverflow.com/questions/2816719/…
– kenn
Jan 9 at 13:55
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57
kill -9 $(pidof vim)– kenn
Jan 9 at 13:37
kill -9 $(pidof vim)– kenn
Jan 9 at 13:37
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have
autoread enabled? Do you have lots of plugins installed? etc.– Dan
Jan 9 at 13:41
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have
autoread enabled? Do you have lots of plugins installed? etc.– Dan
Jan 9 at 13:41
Maybe clearing
vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…– kenn
Jan 9 at 13:55
Maybe clearing
vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…– kenn
Jan 9 at 13:55
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57
add a comment |
1 Answer
1
active
oldest
votes
kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.
You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.
Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.
kill -9 13799
It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).
This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.
answered yesterday
Oli♦Oli
220k86558762
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108290%2fvim-using-up-100-cpu-cant-kill-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.
You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.
Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.
kill -9 13799
It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).
This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.
answered yesterday
Oli♦Oli
220k86558762
add a comment |
kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.
You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.
Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.
kill -9 13799
It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).
This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.
answered yesterday
Oli♦Oli
220k86558762
add a comment |
kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.
You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.
Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.
kill -9 13799
It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).
This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.
answered yesterday
Oli♦Oli
220k86558762
kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.
You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.
Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.
kill -9 13799
It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).
This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.
answered yesterday
Oli♦Oli
220k86558762
answered yesterday
Oli♦Oli
220k86558762
answered yesterday
Oli♦Oli
220k86558762
answered yesterday
Oli♦Oli
220k86558762
220k86558762
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108290%2fvim-using-up-100-cpu-cant-kill-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
kill -9 $(pidof vim)– kenn
Jan 9 at 13:37
It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have
autoreadenabled? Do you have lots of plugins installed? etc.– Dan
Jan 9 at 13:41
Maybe clearing
vim cachein~/.viminfofix it: stackoverflow.com/questions/2816719/…– kenn
Jan 9 at 13:55
Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.
– Neil
Jan 9 at 13:57