Some drush commands fail; Some Drupal pages are blank.
The failing drush commands report "Segmentation fault: 11"
The Apache log (e.g. php-error.log in MAMP) also shows the same error.


If you use a gulp or grunt workflow - to compile your theme's SASS etc. - you may run into a problem where drush commands throw a segmentation fault 11 as does Apache whilst serving Drupal pages as blanks (WSDs).

Probable cause

This is because files from your grunt or gulp workflow environment in node_modules are erroneously being registered by Drupal itself as a bi-product of drush cache-clear all for example. There are dozens of these .js files and Drupal can't handle them ... it's possibly a PCRE regex that is the root cause as this is known elsewhere. Anyway ...

It doesn't always happen

It's not clear whether some modules (like Browser Sync for example) induce this error as a node.js style (i.e. gulp or grunt) workflow can work perfectly before failing in this way.

  • I can confirm Browser Sync & gulp-imagemin were troublesome for me too. Overall .info files in nested folders are the problem.
    – polyclick
    Commented Apr 15, 2015 at 13:43
  • FYI: I've met the same issue using ZURB Foundation with Drupal, see issue drupal.org/node/2514350
    – Scorchio
    Commented Jun 29, 2015 at 22:48
  • We are trying to fix this in Drupal core. Add your opinion and test patches from this issue drupal.org/node/2329453
    – corbacho
    Commented Oct 5, 2015 at 23:36
  • There is an issue for Drupal 7 with a patch that solves the problem: drupal.org/node/619542 There is a related (less severe) Drupal 8 issue: drupal.org/node/2329453
    – malcomio
    Commented Oct 6, 2015 at 11:52
  • This also caused many Drush commands to fail for us (e.g. drush cc all), adding to the confusion. Commented Jul 14, 2016 at 15:31

7 Answers 7


Here is the solution you're looking for. Much more elegant and less work:

"scripts": {
  "postinstall": "find node_modules/ -name '*.info' -type f -delete"

Just a slight alteration on @iamcarico's answer above.

note: you may need a .npmrc with just the following content:

unsafe-perm = true
  • It seems to also happen with YML files :( Commented Sep 17, 2016 at 7:02

So, I have a slightly more elegant solution, that will just remove the .info files after npm install. None are needed, so this Should be safe.

Add the following to the end of your package.json:

"scripts": {
  "postinstall": "find node_modules/ -name \"*.info\" -type f -delete"

This works for me:

(With many thanks to @jorgegc for identifying the cause in this thread at d.o. I thought the topic deserved a more general title here.)

  1. Move gulpfile.js and package.json to the new "hidden" directory .npm
  2. cd .npm and npm install (after having deleted theme root level node_modules directory of course)
  3. edit gulpfile.js base directory for source and destination file paths.e.g. In the snippet bellow "../" were prepended to paths
  4. in turn, invoke gulp command from within the .npm directory

Example directory structure for ihit theme

. ├── .editorconfig ├── .git │   ├── HEAD │   ├── ... ├── .gitignore ├── .jshintrc ├── .npm │   ├── gulpfile.js │   ├── node_modules │   └── package.json ├── assets │   ├── images │   ├── js │   └── sass ├── css │   ├── ihit.hacks.css │   └── ihit.styles.css ├── ihit.info ├── ihit.sublime-project ├── ihit.sublime-workspace ├── images │   ├── logo.png │   ├── search-icon.png │   └── sprite.png ├── js │   └── ihit.behaviors.js ├── php │   ├── ihit_breadcrumb.inc │   ├── ihit_form_search_form_alter.inc │   ├── ihit_menu_link.inc │   ├── ihit_menu_tree.inc │   ├── ihit_preprocess_html.inc │   ├── ihit_preprocess_region.inc │   └── ihit_process_page.inc ├── research │   └── Refills ├── screenshot.png ├── template.php └── templates ├── html.tpl.php ├── node--image_gallery.tpl.php ├── node.tpl.php └── page.tpl.php

Head of gulpfile.js

// project-specific var project = { path: { sass: { source: '../assets/sass/**/*.scss', css_dest: '../css' }, // sass . . .

  • This was the ticket!
    – jsheffers
    Commented Oct 29, 2014 at 21:20

You can avoid all of this by installing your workflow tools in the root of the Drupal site. It won't scan a top-level node_modules folder.

Installing at root-level also has other benefits, like allowing you to lint your entire project in a uniform fashion (your custom modules, Features, and themes can share this root-level config). Provided you group sites/all/modules into contrib and custom subdirectories, you can easily ignore contrib and other vendor folders.

  • We had followed the .npm installation folder trick above your comment previously. Then we switched to Gulp. gulp-eslint does not handle navigating to a parent directory for tracking and linting files. So we moved our build scripts (and node_modules) beside the docroot of our site and everything works perfectly now. thanks for this answer! Commented Feb 19, 2016 at 15:10

It still seems to be a problem and I also got the following error: Segmentation fault: 11 after running npm install.

I use gulp version 3.8.11 and node with the version 0.12.

I usually (in this case too) use aurora as base theme and use an own package.json and gulp.js file. My package.json file contains iamcarrico's postinstall script:

  "scripts": {
    "postinstall": "find node_modules -type f -name '*.info' | xargs rm;"

Hmm, at this point I just recognized that the postinstall script is slightly different which might have caused my Segmentation fault error. Anyway.

What I did was I removed the node_modules directory within my theme with rm -rf ./node_modules. Cleared the cache with drush drush cc all. Then I followed the above instructions of iainh ... until no. 3 (3 not included), ran find node_modules -type f -name '*.info' | xargs rm; inside the .npm folder and moved the gulp.js, package.json and the node_modules folder one level up to the original theme folder. I could run gulp without segmentation errors and even browsersync worked as expected.


Here is the issue on drupal.org which addresses this problem, including patch https://www.drupal.org/node/2329453


my solution was in the past to move the node stuff inside of a hidden folder like ".npm" for example.

Your Answer

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

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