1

I installed the Devel module in a Drupal 7 site via Drush. After installing and enabling the module, I got an error message which simply said Killed.

screenshot

What does that mean? What was killed?

I have installed modules with Drush many times. This is the first time I get an error message like that.

Improve this question
5
  • 1
    We regularly use Devel and I'm unfamiliar with "Killed." as an standard error, error or warning message. Where was this output? From running Drush to the console or Drupal's messaging? What does your logs say, i.e., Reports > Recent log messages or your apache error output?
    – Screenack
    Jan 16, 2016 at 14:07
  • 1
    This is fascinating. There is no string "Killed" in the devel module. I'm wondering if a lower-level message, i.e., CentOS is outputting that after installing Devel? I'd look at dmesg and the /var/log/messages to see what created that message.
    – Screenack
    Jan 16, 2016 at 14:38
  • 1
    More digging… this might not be Drupal or drush related: centos.org/forums/viewtopic.php?f=48&t=50296
    – Screenack
    Jan 16, 2016 at 14:39
  • 1
    Your memory allocation may be too low — or you may have set your PHP/APC memory settings too high. How is your account provisioned? Have you increased your site's PHP or APC (if using) memory?
    – Screenack
    Jan 16, 2016 at 14:43
  • 1
    Let us continue this discussion in chat.
    – Screenack
    Jan 16, 2016 at 14:51

2 Answers 2

Reset to default
2

After some chat-back-and-forth, I'm of the mind that this isn't Drupal or Drush related, but, rather, when you enabled the Devel module, your OS killed a process to manage a limited memory condition. Linux kernels will perform memory management by killing processes Adding a module will increase PHP memory, albeit temporarily, and your OS killed a process to manage the spike. I'm curious if you see whether there are "memory exhausted" entries in your site's logs — or, more likely, these will be occurring at the OS level. Stack memory exhaustion isn't too unusual on a low-RAM setup, or where your requested memory allocations, such as explicit Apache, PHP, MySQL or APC memory requests, use up too much memory, and the OS struggles to achieve a running state.

Try reducing your PHP memory allocation in conservative intervals, say, 16 MB, from 256 to 240 to 224, etc. Then test your changes while crawling your whole site to ensure nothing breaks. I'd do this on a staging server that replicates your live server, since the OS impacts how much memory your site will consume. For your site crawl, you can use a site crawler like XENU (Win only) with the Memory Profile module to see what page makes the highest memory request — and then add, say 48 MB on top of that, which should suffice. It is, however, an inexact process, since you must deal with a random number of random page requests.

Improve this answer
2
  • If I understand correct, killing a processes is generally temporary and does not end in loss of existing data.. ?
    – user16289
    Jan 16, 2016 at 19:41
  • 1
    My guess is that an apache process was killed — nothing destructive to your site. Default apache settings tends to spawn many apache processes.
    – Screenack
    Jan 16, 2016 at 20:06
2

In my case, increasing the value of memory_limit in php.ini solved the problem.

I had 128M and I just changed to 512M, for testing purposes, and the "Killed" message just disappeared.

Of course, don't forget restart your web server after that change.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.