I have several crons running at various times every day. Occasionally, one or another will get 'stuck' and its process will never die. This isn't consistent, but after a change in a function in a different file which several of the crons access, there's been a marked increase in the number of times. Not always to the same file, not always to the same time, and running the files manually works fine.
My questions:
If I modify this external file, the running cron should pick up the change, right? (Tried and it isn't working, so either it doesn't, or it didn't get to that point in my code, which brings me to my second question:)
How can I print a stack trace of the running cron in order to see where it gets stuck? Running on Linux, Centos version 7
Edit: pstack gives me main() - how can I get farther in than that?
#0 0x00007f710a129e0d in poll () from /lib64/libc.so.6
#1 0x00007f7102391ab9 in Curl_poll () from /lib64/libcurl.so.4
#2 0x00007f710238aa4d in curl_multi_wait () from /lib64/libcurl.so.4
#3 0x00007f7102383baf in curl_easy_perform () from /lib64/libcurl.so.4
#4 0x00007f71025c96f6 in zif_curl_exec () from /usr/lib64/php/modules/curl.so
#5 0x00007f71029e6a4d in xdebug_execute_internal (current_execute_data=0x7f710d8f14a0, return_value_used=1) at /var/tmp/xdebug/xdebug.c:1547
#6 0x00007f710dc61271 in zend_do_fcall_common_helper_SPEC ()
#7 0x00007f710dbde617 in execute ()
#8 0x00007f71029e5e3a in xdebug_execute (op_array=0x7f70fa316bc8) at /var/tmp/xdebug/xdebug.c:1435
#9 0x00007f710dc6190d in zend_do_fcall_common_helper_SPEC ()
#10 0x00007f710dbde617 in execute ()
#11 0x00007f71029e5e3a in xdebug_execute (op_array=0x7f710f89efb0) at /var/tmp/xdebug/xdebug.c:1435
#12 0x00007f710dc6190d in zend_do_fcall_common_helper_SPEC ()
#13 0x00007f710dbde617 in execute ()
#14 0x00007f71029e5e3a in xdebug_execute (op_array=0x7f710d921838) at /var/tmp/xdebug/xdebug.c:1435
#15 0x00007f710dbb727f in zend_execute_scripts ()
#16 0x00007f710db56656 in php_execute_script ()
#17 0x00007f710dc63548 in do_cli ()
#18 0x00007f710da1015e in main ()
Thanks for any help!
If any of the crons are leaving the file open then this might be the cause when a concurrent access attempt is made to the same file by different cron instances. You could write a small shell script to execute the code file preceded by something like
$ok = `lsof | grep -c <filename>`
if($ok != "0")
then sleep 5
fi
Related
I am trying to run setup:di:compile on Magento 2.4.4, but I am getting a strange error and have no idea where to look or how to debug this.
Here is the code from the error log:
Proxies code generation... 1/9 [===>------------------------] 11% 1 sec 139.0 MiB Repositories code generation... 1/9 [===>------------------------] 11% 1 sec 139.0 MiBClass "Magento\Framework\DB\DataConverter\SerializedToJson" not found #0 /public_html/vendor/composer/ClassLoader.php(444): include() #1 /public_html/vendor/composer/ClassLoader.php(322): Composer\Autoload\includeFile() #2 [internal function]: Composer\Autoload\ClassLoader->loadClass() #3 /public_html/setup/src/Magento/Setup/Module/Di/Code/Reader/ClassesScanner.php(134): class_exists() #4 /public_html/setup/src/Magento/Setup/Module/Di/Code/Reader/ClassesScanner.php(117): Magento\Setup\Module\Di\Code\Reader\ClassesScanner->includeClass() #5 /public_html/setup/src/Magento/Setup/Module/Di/Code/Reader/ClassesScanner.php(87): Magento\Setup\Module\Di\Code\Reader\ClassesScanner->extract() #6 /public_html/setup/src/Magento/Setup/Module/Di/App/Task/Operation/RepositoryGenerator.php(61): Magento\Setup\Module\Di\Code\Reader\ClassesScanner->getList() #7 /public_html/setup/src/Magento/Setup/Module/Di/App/Task/Manager.php(56): Magento\Setup\Module\Di\App\Task\Operation\RepositoryGenerator->doOperation() #8 /public_html/setup/src/Magento/Setup/Console/Command/DiCompileCommand.php(216): Magento\Setup\Module\Di\App\Task\Manager->process() #9 /public_html/vendor/symfony/console/Command/Command.php(255): Magento\Setup\Console\Command\DiCompileCommand->execute() #10 /public_html/vendor/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run() #11 /public_html/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand() #12 /public_html/vendor/magento/framework/Console/Cli.php(115): Symfony\Component\Console\Application->doRun() #13 /public_html/vendor/symfony/console/Application.php(149): Magento\Framework\Console\Cli->doRun() #14 /public_html/bin/magento(23): Symfony\Component\Console\Application->run() #15 {main}
Tried to redeploy static files and so on, but the issue still persists.
Thanks very much for your help!
I have tried:
clearing generated folder
deploying static content
clearing cache
reindexing
What you can simply do is:
Remove the vendor directory and launch the terminal again and execute the command
composer install
to regenerate all the Magento standard codes. You can check your vendor folder to ensure all dependencies are installed and run the compilation command later to load the dependencies.
Please make sure to backup the previous folder as well for safer side.
First I like to say I'm new to Magento, and have been given the task to work on the site but I'm having an issue taking the live site and installing locally for development work. Here is the errors I'm receiving when trying to install site locally.
Fatal error: Uncaught Error: Function name must be a string in
/Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Model/Layout.php:556
Stack trace: #0
/Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Action.php(390):
Mage_Core_Model_Layout->getOutput() #1
/Applications/MAMP/htdocs/site/app/code/core/Mage/Install/controllers/WizardController.php(120):
Mage_Core_Controller_Varien_Action->renderLayout() #2
/Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Action.php(418):
Mage_Install_WizardController->beginAction() #3
/Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254):
Mage_Core_Controller_Varien_Action->dispatch('begin') #4
/Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Front.php(172):
Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
5 /Applications/MAMP/htdocs/site in /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Model/Layout.php
on line 556
I've followed these steps so far:
Download the magento files using any ftp client.
Export the database from live server.
Put the downloaded Magento files in your localhost root folder.
Create a blank database in my local computer and import the database backup that I exported from the live one.
Delete/Rename the file app/etc/local.xml
Change secure and unsecure URL's in 'core_config_data' table.
Any help will be appreciated as I really need to get this working.
Using Magento version 1.9.0.1 and line 556 is the
$out .= $this->getBlock($callback[0])->$callback[1]();
Here is the whole function:
public function getOutput()
{
$out = '';
if (!empty($this->_output)) {
foreach ($this->_output as $callback) {
$out .= $this->getBlock($callback[0])->$callback[1]();
}
}
return $out;
}
This is the exception log printout:
Exception: load error: failed to find /var/www/vhosts/siteuk.virtualsplash.com/httpdocs/skin/frontend/mtbelano/default/css/styles.less in /Applications/MAMP/htdocs/site/lib/Soczed/less/lessc.inc.php:2379
Stack trace:
#0 /Applications/MAMP/htdocs/site/lib/Soczed/less/lessc.inc.php(2528): lessc->__construct('/var/www/vhosts...')
#1 /Applications/MAMP/htdocs/site/app/code/community/Soczed/Less/Model/Observer.php(178): lessc::cexecute(Array, false, Array, Array)
#2 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Model/App.php(1338): Soczed_Less_Model_Observer->beforeLayoutRender(Object(Varien_Event_Observer))
#3 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Soczed_Less_Model_Observer), 'beforeLayoutRen...', Object(Varien_Event_Observer))
#4 /Applications/MAMP/htdocs/site/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('controller_acti...', Array)
#5 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Action.php(384): Mage::dispatchEvent('controller_acti...')
#6 /Applications/MAMP/htdocs/site/app/code/core/Mage/Cms/Helper/Page.php(137): Mage_Core_Controller_Varien_Action->renderLayout()
#7 /Applications/MAMP/htdocs/site/app/code/core/Mage/Cms/Helper/Page.php(52): Mage_Cms_Helper_Page->_renderPage(Object(Mage_Cms_IndexController), 'new_home_page')
#8 /Applications/MAMP/htdocs/site/app/code/core/Mage/Cms/controllers/IndexController.php(45): Mage_Cms_Helper_Page->renderPage(Object(Mage_Cms_IndexController), 'new_home_page')
#9 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Cms_IndexController->indexAction()
#10 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('index')
#11 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#12 /Applications/MAMP/htdocs/site/app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#13 /Applications/MAMP/htdocs/site/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#14 /Applications/MAMP/htdocs/site/index.php(94): Mage::run('', 'store')
#15 {main}
Change the line $out .= $this->getBlock($callback[0])->$callback[1](); with the below-mentioned code
$out .= $this->getBlock($callback[0])->{$callback[1]}();
When we configured site from one place to another place, in magento we need to do fillowing thigs.
Change secure and unsecure URL's in 'core_config_data' table.
Configured your new server detail in this file.
app\etc\local.xml
<connection>
<host><![CDATA[localhost]]></host>
<username><![CDATA[YOUR_DATABASE_USER_NAME]]></username>
<password><![CDATA[YOUR_DATABASE_USER_PASSWORD]]></password>
<dbname><![CDATA[YOUR_DATABASE_NAME]]></dbname>
</connection>
I have same problem with Laravel 5.3 (on windows server). I did all possible attempts: checked .env file, config, artisan new key generation, cache: clear, config: clear, composer update, but the problem randomly persists.
Note that the same code with exactly same version of apache, mysql, php, doesn't generate this problem on Mac OS.
I found that the key (first parameter of Encrypter constractor) arrives "sometimes" empty and of course it fails. Most of the times the key is correct, but randomly the key arrives empty from EncryptionServiceProvider that in turns asks it to the app config.
So the only solution that worked for me was to add an if ($key) in EncryptionServiceProvider so that the Encryption constructor doesn't get called with empty key.
Of course is not a "clean" solution nor it explains the problem, but at least avoids to find the log file filled with the error:
RuntimeException: The only supported ciphers are AES-128-CBC and
AES-256-CBC and pages are displayed correctly.
If this is a Laravel bug I don't know, but of course if someone could explain this I will be more then happy to know.
Below is my modified class: I just added the if ($key) line before new Encrypter:
class EncryptionServiceProvider extends ServiceProvider
{
/**
* Register the service provider.
*
* #return void
*/
public function register()
{
$this->app->singleton('encrypter', function ($app) {
$config = $app->make('config')->get('app');
// If the key starts with "base64:", we will need to decode the key before handing
// it off to the encrypter. Keys may be base-64 encoded for presentation and we
// want to make sure to convert them back to the raw bytes before encrypting.
if (Str::startsWith($key = $config['key'], 'base64:')) {
$key = base64_decode(substr($key, 7));
}
if ($key)
return new Encrypter($key, $config['cipher']);
});
}
}
Further details and backtrace log:
Of course, as I wrote I checked, .env file, config, artisan new key generation, cache: clear, config: clear, composer update.
This stuff is ok since it works 99% of the time but randomly I get the error.
Here the back trace:
[2017-01-09 10:25:40] test.ERROR: RuntimeException: The only supported
ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths.
in
C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Encryption\Encrypter.php:43
Stack trace:
#0 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Encryption\EncryptionServiceProvider.php(27): Illuminate\Encryption\Encrypter->__construct('', 'AES-256-CBC')
#1 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(746): Illuminate\Encryption\EncryptionServiceProvider->Illuminate\Encryption\{closure}(Object(Illuminate\Foundation\Application), Array)
#2 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(644): Illuminate\Container\Container->build(Object(Closure), Array)
#3 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Application.php(709): Illuminate\Container\Container->make('encrypter', Array)
#4 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(864): Illuminate\Foundation\Application->make('encrypter')
#5 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(819): Illuminate\Container\Container->resolveClass(Object(ReflectionParameter))
#6 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(788): Illuminate\Container\Container->getDependencies(Array, Array)
#7 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Container\Container.php(644): Illuminate\Container\Container->build('App\\Http\\Middle...', Array)
#8 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Application.php(709): Illuminate\Container\Container->make('App\\Http\\Middle...', Array)
#9 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(127): Illuminate\Foundation\Application->make('App\\Http\\Middle...')
#10 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(33): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#11 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\View\Middleware\ShareErrorsFromSession.php(49): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#12 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(137): Illuminate\View\Middleware\ShareErrorsFromSession->handle(Object(Illuminate\Http\Request), Object(Closure))
#13 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(33): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#14 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Session\Middleware\StartSession.php(64): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#15 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(137): Illuminate\Session\Middleware\StartSession->handle(Object(Illuminate\Http\Request), Object(Closure))
#16 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(33): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#17 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse.php(37): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#18 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(137): Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse->handle(Object(Illuminate\Http\Request), Object(Closure))
#19 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(33): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#20 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(104): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#21 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Router.php(655): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#22 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Router.php(629): Illuminate\Routing\Router->runRouteWithinStack(Object(Illuminate\Routing\Route), Object(Illuminate\Http\Request))
#23 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Router.php(607): Illuminate\Routing\Router->dispatchToRoute(Object(Illuminate\Http\Request))
#24 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Http\Kernel.php(268): Illuminate\Routing\Router->dispatch(Object(Illuminate\Http\Request))
#25 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(53): Illuminate\Foundation\Http\Kernel->Illuminate\Foundation\Http\{closure}(Object(Illuminate\Http\Request))
#26 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode.php(46): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#27 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(137): Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode->handle(Object(Illuminate\Http\Request), Object(Closure))
#28 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Routing\Pipeline.php(33): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(Illuminate\Http\Request))
#29 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Pipeline\Pipeline.php(104): Illuminate\Routing\Pipeline->Illuminate\Routing\{closure}(Object(Illuminate\Http\Request))
#30 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Http\Kernel.php(150): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#31 C:\Apache24\htdocs\sph\vendor\laravel\framework\src\Illuminate\Foundation\Http\Kernel.php(117): Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter(Object(Illuminate\Http\Request))
#32 C:\Apache24\htdocs\sph\public\index.php(53): Illuminate\Foundation\Http\Kernel->handle(Object(Illuminate\Http\Request))
#33 {main}
The issue occurs when using thread-safe versions of PHP on multi-threaded web servers, instead of multi-process web servers. You can read about the issue a little more on the Github issue here, Github issue here, and a PHP bug report here. There are a few more links, but they are just branched off from those few I posted.
The basic gist is that with the multi-threaded web server, you have a single process that handles multiple threads. However, the putenv()/getenv() methods are not thread safe, and change environment variables at the process level, so all threads under that process are affected.
So, you end up with something like this: (as described in this issue):
Request 1: {starts --- loads env --- work --- finishes}
Request 2: {starts ----- loads env --- work --- finishes}
So, request 1 comes in, loads the environment fine, and gets to work. While request 1 is working, request 2 comes in and starts on another thread. Before request 2 reads the environment variables, request 1 finishes and PHP clears out all variables set by putenv(). Now, request 2 attempts to read the environment, but gets null because the variables were cleared when request 1 finished.
This issue can be mitigated in two ways:
Don't use a .env file in production. Set the environment variables directly, and disable phpdotenv. This is also suggested by the package itself:
phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request.
Never use the env() method outside of config files, and make sure you cache your config files. By using this method, the environment is read once: when you create the config file cache. Every actual web request will read the data from the cache, and the environment variables will never be touched again.
I installed Laravel 5.3 and I didn't found a .env file there. And boom.... That was the issue. I created .env file in root of application and ran
php artisan key:generate
in terminal and it generated base 64 encoded string in terminal. Copy that string in to .env file as
APP_KEY=base64:************************************************
where **** is generated encoded string. Run application again and it should work.
APP_KEY cipher if AES-256-CBC is selected, the length must be 32 characters.
'key' => env('APP_KEY'),
'cipher' => 'AES-256-CBC',
APP_KEY=base64:iT7PDx7j8yKVTj0AW81vTnEQmqLwnVfW => 32 characters
It is so simple, copy the APP_KEY from .env file to config/app.php -> key or run command below:
php artisan key:generate
I am having a strange problem using WebJobs on Azure to run Laravel Background tasks.
I have this code in my Laravel ExpireContactsFromDatabase command's handle() method
public function handle()
{
* Update contacts that are old and past their expiry date but that have not been deleted
* Set their deleted at to the current timestamp
*/
$contact = Contact::where('expiry_date', '<=', date('Y-m-d H:i:s'))
->whereNull('deleted_at')
->update(array('deleted_at' => date('Y-m-d H:i:s')));
Log::info("200" . " " . "Contacts clearing executed successfully, see response from db :::: " . serialize($contact));
}
I have successfully registered this command in app\Console\Kernel.php, like so:
class Kernel extends ConsoleKernel
{
/**
* The Artisan commands provided by your application.
*
* #var array
*/
protected $commands = [
Inspire::class,
ExpireContactsFromDatabase::class,
];
/**
* Define the application's command schedule.
*
* #param \Illuminate\Console\Scheduling\Schedule $schedule
* #return void
*/
protected function schedule(Schedule $schedule)
{
$schedule->command('inspire')
->hourly();
$schedule->command('expire:contacts')
->everyMinute()
->sendOutputTo('expired_contacts_results_dbresponse.txt');
}
}
This is running very well on my local development machine. I configured a cron job on my laptop and it executes this command and expires the old contacts as expected.
The problem comes in when I migrate the application from localhost to Ms Azure. I configure a WebJob to run continuosly, give it the path to artisan and issue schedule run. I do this in using a .bat file, like so:
php D:\home\site\wwwroot\artisan schedule:run > D:\home\site\wwwroot\expired_contacts_results_confirmation.txt
PHP is on my web applications path so no worries.
The challenge is when the command executes/ when I run php artisan schedule::run and I check my log files, I see the response from the database (logged into expired_contacts_results_dbresponse.txt) as follows:
[2016-10-20 12:21:43] local.ERROR: exception 'PDOException' with message 'SQLSTATE[HY000] [2002] An attempt was made to access a socket in a way forbidden by its access permissions.
' in D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Connectors\Connector.php:55
My guess is that the way laravel is connecting to the database has issues in this case. However, other components of my application use the same connection codes and they are working well so In am confused. Scouring the internet for an exact solution to this problem has not worked.
I am running my app on Azure on the D1 Shared Hosting Plan and using the convenient Azure MySQLInApp database for my database storage.
Here is my full stack trace.
Stack trace:
#0 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Connectors\Connector.php(55): PDO->__construct('mysql:host=;dbn...', '', '', Array)
#1 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Connectors\MySqlConnector.php(22): Illuminate\Database\Connectors\Connector->createConnection('mysql:host=;dbn...', Array, Array)
#2 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Connectors\ConnectionFactory.php(60): Illuminate\Database\Connectors\MySqlConnector->connect(Array)
#3 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Connectors\ConnectionFactory.php(49): Illuminate\Database\Connectors\ConnectionFactory->createSingleConnection(Array)
#4 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\DatabaseManager.php(175): Illuminate\Database\Connectors\ConnectionFactory->make(Array, 'mysql')
#5 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\DatabaseManager.php(67): Illuminate\Database\DatabaseManager->makeConnection('mysql')
#6 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(3224): Illuminate\Database\DatabaseManager->connection(NULL)
#7 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(3190): Illuminate\Database\Eloquent\Model::resolveConnection(NULL)
#8 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(1870): Illuminate\Database\Eloquent\Model->getConnection()
#9 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(1813): Illuminate\Database\Eloquent\Model->newBaseQueryBuilder()
#10 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(1787): Illuminate\Database\Eloquent\Model->newQueryWithoutScopes()
#11 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(3442): Illuminate\Database\Eloquent\Model->newQuery()
#12 [internal function]: Illuminate\Database\Eloquent\Model->__call('where', Array)
#13 [internal function]: App\Contact->where('expiry_date', '<=', '2016-10-20 12:2...')
#14 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Database\Eloquent\Model.php(3458): call_user_func_array(Array, Array)
#15 D:\home\site\wwwroot\app\Console\Commands\ExpireContactsFromDatabase.php(53): Illuminate\Database\Eloquent\Model::__callStatic('where', Array)
#16 D:\home\site\wwwroot\app\Console\Commands\ExpireContactsFromDatabase.php(53): App\Contact::where('expiry_date', '<=', '2016-10-20 12:2...')
#17 [internal function]: App\Console\Commands\ExpireContactsFromDatabase->handle()
#18 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Container\Container.php(507): call_user_func_array(Array, Array)
#19 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Console\Command.php(150): Illuminate\Container\Container->call(Array)
#20 D:\home\site\wwwroot\vendor\symfony\console\Command\Command.php(256): Illuminate\Console\Command->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Console\Command.php(136): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 D:\home\site\wwwroot\vendor\symfony\console\Application.php(846): Illuminate\Console\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#23 D:\home\site\wwwroot\vendor\symfony\console\Application.php(190): Symfony\Component\Console\Application->doRunCommand(Object(App\Console\Commands\ExpireContactsFromDatabase), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#24 D:\home\site\wwwroot\vendor\symfony\console\Application.php(121): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#25 D:\home\site\wwwroot\vendor\laravel\framework\src\Illuminate\Foundation\Console\Kernel.php(107): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#26 D:\home\site\wwwroot\artisan(36): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
Will greatly appreciate any help I can get.
It seems the internal PHP runtime in Web App doesn't have sufficient permission to access to MySQL in App. In my test, I even create a test script leveraging the test connection code at Get the database connection string, and execute PHP test.php in KUDU console site, I would get the same issue with you.
But it worked fine if I access it via HTTP request (Which will be handled via IIS). So please try the following workaround. Implementing your functionality and expose as a Restful API. In Webjob script, you can generate a HTTP request to call this API.
Any further concern, please feel free to let me know.
The scenario is supported - please see this. We are working toward making this scenario better.
Ok, I'm running a PHP app on command line on Ubuntu, and it ends with "Segmentation fault (core dumped)".
How do I go from here to debug it? I'm pretty sure there is no memory leak as I checked it already with get_memory_usage().
Edit: Alright, as explained by Brendan and Ulricht, I tried gdb. That's not my environment at all so sorry for the oncoming newbie questions.
I ran my code under gdb and got the segfault. Here are the first 22 lines.
(gdb) bt
#0 0x00000000006f5d36 in ?? ()
#1 0x00000000006f7625 in ?? ()
#2 0x00000000006f7b68 in zend_parse_parameters ()
#3 0x0000000000610584 in zif_array_rand ()
#4 0x00000000006dd9bb in dtrace_execute_internal ()
#5 0x000000000079da15 in ?? ()
#6 0x0000000000717748 in execute_ex ()
#7 0x00000000006dd8b9 in dtrace_execute_ex ()
#8 0x000000000079e060 in ?? ()
#9 0x0000000000717748 in execute_ex ()
#10 0x00000000006dd8b9 in dtrace_execute_ex ()
#11 0x000000000079e060 in ?? ()
#12 0x0000000000717748 in execute_ex ()
#13 0x00000000006dd8b9 in dtrace_execute_ex ()
#14 0x000000000079e060 in ?? ()
#15 0x0000000000717748 in execute_ex ()
#16 0x00000000006dd8b9 in dtrace_execute_ex ()
#17 0x000000000079e060 in ?? ()
#18 0x0000000000717748 in execute_ex ()
#19 0x00000000006dd8b9 in dtrace_execute_ex ()
#20 0x000000000079e060 in ?? ()
#21 0x0000000000717748 in execute_ex ()
#22 0x00000000006dd8b9 in dtrace_execute_ex ()
According to https://bugs.php.net/bugs-generating-backtrace.php, I should get "execute" calls, instead I have "execute_ex". Same thing?
The following command anyway does not return the function name (after having done frame 6):
print (char *)(executor_globals.function_state_ptr->function)->common.function_name
Attempt to extract a component of a value that is not a structure.
Edit2: I'd appreciate knowing why the downvote. I think it's a valid question and I haven't found a similar one for PHP. If there is then you're free to comment.
There are several things to pinpoint the error, but the first is to run the executable in gdb:
> gdb /usr/bin/php
....
(gdb) run path/to/script
Note that you can also load the dumped core into gdb. Other tools for finding out what could cause the issue are strace and valgrind.