Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Amazon Linux appears to be derived from RHEL, and uses yum/rpm for package management. The particular release in this case is: https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
The error in question is:
pcntl_exec(): Error has occured: (errno 13) Permission denied hosting_queued.drush.inc:172 [warning]
WD hosting_queued: Could not restart the queue daemon, aborting. [error]
Drush command terminated abnormally due to an unrecoverable error.
The code in question is:
// We need the PCNTL extension to be able to auto restart.
if (function_exists('pcntl_exec')) {
$args = $_ENV['argv'];
$drush = array_shift($args);
// Strip sub-array to avoid warning "Array to string conversion"
unset($_ENV['argv']);
watchdog('hosting_queued', 'Restarting queue daemon with @drush @args.', array('@drush' => $drush, '@args' => implode(" ", $args)));
pcntl_exec($drush, $args, $_ENV);
watchdog('hosting_queued', 'Could not restart the queue daemon, aborting.', array(), WATCHDOG_ERROR);
/* NOTREACHED */
}
Watchdog shows that it tried to restart using the following command:
Restarting queue daemon with /usr/share/pear/drush/drush.php --php=/usr/bin/php --php-options= -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off --quiet @hostmaster hosting-queued.
Comment | File | Size | Author |
---|---|---|---|
#16 | queue_daemon_fails_to_time-2150787-16.patch | 470 bytes | helmo |
#16 | queue_daemon_fails_to-2150787-16.patch | 4.85 KB | helmo |
#7 | hosting-fix_queued_restart-2150787-7.patch | 1.39 KB | zhangtaihao |
#4 | hosting-fix_queued_restart-2150787-4.patch | 1.07 KB | ergonlogic |
Comments
Comment #1
ergonlogicComment #2
ergonlogicThis appear related to #2077793: Queue daemon collecting quotes. We're still calling drush.php directly, which is not executable on PEAR-based installs.
Comment #3
ergonlogicSwitching to using drush_build_drush_command():
... results in:
... with the watchdog message:
Comment #4
ergonlogicThe attached patch is almost certainly the wrong way to do this. It's basically a round-about way to pass '/usr/bin/php' to pcntl_exec(). However, it has the virtue of working. I'm going to to try it on a Debian system, and see how it fares.
Comment #5
ergonlogicThis fails on a normal Debian install, as it tries to restart the daemon by running '/usr/share/php/drush/drush.php /usr/bin/drush @hostmaster hosting-queued'
Comment #6
Liam McDermott CreditAttribution: Liam McDermott commentedHopefully it's not superfluous for me to mention that this is probably the root cause of the bug as I'm seeing it on an Ubuntu installation.
As a workaround I marked /usr/share/php/drush/drush.php executable, haven't seen any errors for a couple of hours and the queue daemon reports it is running.
Comment #7
zhangtaihao CreditAttribution: zhangtaihao commentedBased on #2059225: drush.php is not executable with PEAR install, maybe we could adapt the necessary bits of
drush_build_drush_command()
to obtain PHP binary path (especially given we can't use that function directly forpcntl_exec()
).Or is that not even necessary, i.e. just use
drush_get_option('php', PHP_BINDIR . '/php')
?Comment #8
ergonlogicI'm seeing this on a fresh install on a recent Debian 7. Running
drush @hostmaster hosting-queued --debug
works fine, but then dies as soon as it tries to restart itself with:Specifying the proper path to Drush in hosting_queued_restart() appears to fix it:
Comment #9
zhangtaihao CreditAttribution: zhangtaihao commentedYes it does. Unfortunately the path may also be
/usr/local/bin/drush
(as is the case with the default daemon template). So perhaps awhich drush
is in order for that case. All of that assumes, of course, that Drush is used and exists as an executable shell script and not a PHP script (e.g./usr/share/pear/drush/drush.php
) executed by/usr/bin/php
.EDIT: And without piping the command through Drush internals we might be missing custom Drush arguments (especially if the daemon has been tailored for the hosting solution).
Comment #10
ergonlogicClosing for lack of activity. Consider moving to https://github.com/getvalkyrie/skynet
Comment #11
esolitosIf this could be solved it could very useful! Currently I had to use another daemon to check if the hosting-queued is still running, since it always crashes each time it tries to restart.
System: Ubuntu
Comment #12
Wayne Oliver CreditAttribution: Wayne Oliver commentedlike esolitos, I have puppet making sure it's started.
However it dies exactly 1 hour after being started.
ubuntu 14.04
drush 6.2
hostmaster 2.1
Anybody want some more info or want me to test something?
Comment #13
jpwester CreditAttribution: jpwester commentedI am having this exact issue. I have limited access to the server, so I need some sort of sustainable way to get this working while keeping the standard PEAR-sourced drush. Any progress?
Comment #14
esolitosYes, it's because it is nor able to restart itself, you can change this time to 24h or something, but beware that there will higher memory usage by the daemon, since php leaks some memory with time.
Comment #15
jpwester CreditAttribution: jpwester commentedThe patch in #7 worked for me.
Comment #16
helmo CreditAttribution: helmo at Initfour websolutions commentedTwo patches ... one that improves the daemon a bit to survive a restarting DB server. Adding more try {} catch {}
And the other to actually notice that it's lifetime is over .... in the D7 upgrade a time() call was converted to a constant :P
Comment #18
helmo CreditAttribution: helmo at Initfour websolutions commentedDid another test run with this ... still looks good.
I added one extra commit to prevent a tight loop when lock_acquire fails.
Comment #20
ergonlogicSince 3.5, there have been reports on IRC of:
The commits associated with this issue appear to be the only ones relevant. In particular: f392622a.
Comment #21
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commentedIf we're just trying to get a DB connection back because it's been too long since it was used, then I think you can just unset the connection from the global pool by doing this:
Is that what the code is trying to do?
Comment #22
Steven Jones CreditAttribution: Steven Jones at ComputerMinds commentedOh weird, so there's a loop that's trying to wait for the DB to come back, using the mysqli functions directly.
Comment #23
helmo CreditAttribution: helmo at Initfour websolutions commentedThat code mainly tries to handle interruptions in the db server. Could be a restart... om even a stop ... wait/update... start.
Comment #25
helmo CreditAttribution: helmo at Initfour websolutions commentedJust pushed a relatively simple fix for this.