I am not a Dev so I don't have a clue where would this come from.

I've installed and enabled the famous Devel module in my Drupal 7 site via Drush 7 on my CentOS online server after connecting with SSH.

After installing and enabling the module I got the message "Killed", not more not less.

enter image description here

My only question is - What was killed?... I've installed modules with Drush many times, on both Druapl 7&8, and both online and locally, and never had this message before. The install and enabling seem to have been successful.

Material I've found in Google and here deals with Drupal 6 and other commands.

  • 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 '16 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 '16 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 '16 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 '16 at 14:43
  • 1
    Let us continue this discussion in chat. – Screenack Jan 16 '16 at 14:51

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.

  • If I understand correct, killing a processes is generally temporary and does not end in loss of existing data.. ? – JohnDoea Jan 16 '16 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 '16 at 20:06

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.