Disclaimer: I have found a way to fix this problem short-term, but I'm curious if anyone can explain to me why it's happening, or if someone has found a better fix than what I'm doing. If it exists already, Google has not revealed it to me.

Problem: (on a LAMP Server) When I use 'drush up' to update a module, or even core, the selinux context on the files is changed. This is new behavior as far as I can tell. I have used 'drush up' to update core and modules in the past with no problems. The changed selinux context results in a WSOD. To fix this, I run restorecon -R on the drupal root, which results in a series of


and then things work again, until the next 'drush up'. If I have multiple modules to update I either update and restorecon repetitively, or take my chances and drush up -y, restorecon, and then hope for the best (not ideal obviously).

Drush 7 and Drush 8 both behave this way. Oddly enough, when I 'drush dl' a module, it's brought in to the modules folder with the appropriate selinux context. Based on an ll -Z of files in the temp folder, I'm guessing (emphasis on guessing) that the files are getting moved from there rather than copied during an update, but I do not know enough about the inner workings of drush to be able to trouble shoot. Any insight would be welcome. Thank you.

  • 1
    Adding the --debug option to the command will give you a verbose output of what it's doing which should help in finding what might be causing it. – Shawn Conn Oct 22 '16 at 6:39
  • 1
    This isn't really a Drupal or Drush question as it is about PHP and SELinux. A normal copy (using cp on the command line) would change the selinux context to the context of the parent directory. Either the context of the parent directory (sites/all/modules or similar) is wrong or copying using PHP bypasses the normal SELinux mechanisms. The normal problem with PHP and SELinux is connected to move_file_upload, but I don't think that is the case here as Drush is a command line tool. Using --debug as suggested is probably needed to see what is going on. – hansfn Oct 22 '16 at 18:34
  • Thank you both for pointing to --debug. While I don't have it all figured out yet, I think I've nailed down the basic problem. Drush uses php's rename() function, which is a move and not a copy. If rename isn't available for some reason, drush performs a copy followed by a delete. By commenting out the portion that uses rename() and allowing the fallback copy/delete to happen, I get the functionality that I want/expect. Thanks again. – J.P. Oct 24 '16 at 15:50

Your Answer

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

Browse other questions tagged or ask your own question.