hosting fails on ubuntu with drush wrapper script or via cron

This is a typical symptom of a text file being processed as a shell script. Before 2.1, the drush.php script had a #! header that was telling the shell interpreter which command to call to actually execute the script. Now, that is gone and everything needs to go through the shell wrapper, which is a sham in my opinion, but I didn't have time to review the comments on that issue before 2.1 was released: #586466: Drush.php is no longer directly executable (can interfere with backend invoke).

That said, this error means that drush.php is called *without* the php prefix. It's called like:

instead of:

So there's got to be, somewhere in hosting, a place that this script is called directly.

I think this whole thing is ridiculous personally. There's no sane reason why we would need a shell script to execute PHP, and I will make sure the drush package is self-executable without that silly shell wrapper.

Stay tuned.

Now, that is gone and everything needs to go through the shell wrapper, which is a sham in my opinion, but I didn't have time to review the comments on that issue before 2.1 was released:

that is not true.

our original mechanism (php /path/to/drush/drush.php) still works too.

you just can't use (/path/to/drush/drush.php) directly.

ALSO, i use hosting dispatch on the cli on osx with the drush wrapper script and it works fine, so the issue is not hosting.

Changing the title to something that's hopefully a bit more accurate.

i use hosting dispatch on the cli on osx with the drush wrapper script and it works fine, so the issue is not hosting
Ah, ok. Except as I said I can run drush status from cron and on the cli without issue, so it has to be some combination of ubuntu/dash, drush and hosting.

So there's got to be, somewhere in hosting, a place that this script is called directly.
I'll do a bit more digging today.

A bit more info, runing drush with the -d debug option.

Standard cron command, runs as /bin/sh (aka dash):

Basically drush runs ok, but breaks when it forks (presumably it forgets where php is?) and runs: "Forking : ( /var/aegir/drush/drush.php" without calling php first.
There's a similar error when running via drush wrapper from the command line:

Again, when hosting dispatch is called and the fork occurs the command is malfomed: "Forking : (/usr/bin/env /var/aegir/drush/drush.php", again missing php.

In both cases I was able to remove the errors by doing as the drush error suggested and use --php, e.g. for cron:

I don't know if the bug is in drush, or the way hosting calls drush_backend_fork() or something else, but it does look like this problem with dash occurs at the fork. As though it doesn't inherit php from the parent. Maybe this issue belongs on Drush, anyway, out of my depth now.

So, drush itself runs fine via dash, but the backend fork fails.

Looks like this isn't fixing the cron issue, the 1min cron for dispatch queue errors are gone, but the error is still there when the main cron runs, every 10 minutes. Which seems even more bizzare. That and the epoch date tasks now use...

Giving up with this and sticking:

Which works around this issue, but apparently only works for linux crontab.

i have a patch fro you to try,

this wipes out the crontab entirely and adds the SHELL= and PATH= at the top of the file.

you just need to run hosting setup --uri=url.com

#7 patch includes work not related to this ticket. Not a dirty git! :D

Here's an updated patch

Yeah, I noticed the cruft :)

I applied anyway, and yes it works, as does adding just SHELL= to crontab without the path (but then I've copied my .bashrc to aegir's home folder so that probably extends the path in bash anyway...).

Believe Adrian committed his patch here.

For the record, anarcat patched drush in the last 24 hours to actually fix this mess at that level. Everyone's a winner baby (that's the truth)

subscribe

Automatically closed -- issue fixed for 2 weeks with no activity.