2

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:

enter image description here

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 )

Neil
  • 298
  • kill -9 $(pidof vim) – kenn Jan 09 '19 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 09 '19 at 13:41
  • Maybe clearing vim cache in ~/.viminfo fix it: https://stackoverflow.com/questions/2816719/clear-certain-criteria-from-viminfo-file – kenn Jan 09 '19 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 09 '19 at 13:57

1 Answers1

3

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.

Oli
  • 293,335