Last modified: 2014-10-14 06:33:22 UTC
Created attachment 16736 [details] vagrant provision debug output background ---------- when provisioning a role that uses the puppet method, mediawiki::import_dump, after a clean install of vagrant, luasandbox is not available and the import_dump method fails. after a second attempt at provisioning the role, the luasandbox is available. steps to reproduce ------------------ 1. install a clean version of mw vagrant https://www.mediawiki.org/wiki/MediaWiki-Vagrant#Quick_start 2. vagrant up 3. vagrant enable-role gwtoolset 4. vagrant provision expected result --------------- scribunto should be available for use when importing dumps that use scribunto actual result ------------- see line 2004 of attached provision output using: PUPPET_DEBUG=1 vagrant provision ==> default: Notice: /Stage[main]/Role::Gwtoolset/Mediawiki::Import_dump[template_de]/Exec[import_dump_template_de]/returns: [fd5c8acc] [no req] Exception from line 220 of /vagrant/mediawiki/extensions/Scribunto/engines/LuaSandbox/Engine.php: The luasandbox extension is not present, this engine cannot be used.
Fix the role to have the import "require => Class['::role::scrubunto']"
the require ::role statement was already present. i tried adding the require statement in the extension statement, but that didn’t resolve the issue either. class role::gwtoolset { require ::role::scribunto // this was already in the role mediawiki::extension { 'GWToolset': settings => template('role/gwtoolset-config.php.erb') // tried adding this require => [ Mediawiki::Extension['Scribunto'] ] } } also tried changing the scribunto role, by switching its include ::role statements to require ::role statements., but that didn’t work either.
The Scribunto role is definitely installed first: ==> default: Notice: /Stage[main]/Role::Scribunto/Mediawiki::Extension[Scribunto]/Mediawiki::Settings[Scribunto]/File[/vagrant/settings.d/puppet-managed/10-Scribunto.php]/ensure: created ==> default: Info: Mediawiki::Extension[Scribunto]: Scheduling refresh of Service[apache2] ==> default: Notice: /Stage[main]/Role::Gwtoolset/Mediawiki::Extension[GWToolset]/Mediawiki::Settings[GWToolset]/File[/vagrant/settings.d/puppet-managed/10-GWToolset.php]/ensure: created ==> default: Notice: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]/ensure: defined content as '{md5}ee2d19b020f6a7600b5192436ae03b4d' ==> default: Info: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]: Scheduling refresh of Service[apache2] ==> default: Info: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/File[/etc/php5/mods-available/_gwtoolset.ini]: Scheduling refresh of Exec[/usr/sbin/php5enmod -s ALL _gwtoolset] ==> default: Notice: /Stage[main]/Role::Gwtoolset/Php::Ini[GWToolset]/Exec[/usr/sbin/php5enmod -s ALL _gwtoolset]: Triggered 'refresh' from 1 events ==> default: Notice: /Stage[main]/Role::Gwtoolset/Mediawiki::Import_dump[template_de]/Exec[import_dump_template_de]/returns: [1ce8dfae] [no req] Exception from line 220 of /vagrant/mediawiki/extensions/Scribunto/engines/LuaSandbox/Engine.php: The luasandbox extension is not present, this engine cannot be used. It's definitely not an issue of not requiring that role, it's a problem with the freshly installed php extension being unavailable. Maybe mwscript uses the http server to process the request? In which case a workaround might be (if there's a way to do that) to reload the http server after the php extension is installed. The server reload happens at the end of the provision session. If that's the requirement that would explain why doing it in two steps (first provision a role that installed the lua stuff, then provision a role that imports the templates) works.
The scribunto role does have: notify => Service['apache2'] Which I'm guessing is what's used to reload apache. But vagrant/puppet doesn't do it right after installing the role. Maybe it does it just once at the end of the provision session if anything "notified" apache2?
Ugh... my theory was stupid, the log I pasted above shows that apache2 does get refreshed by the scribunto role.
Or maybe since it states "Scheduling refresh of Service" it's not synchronous, and thus we're possibly dealing with a race condition?
(In reply to Gilles Dubuc from comment #6) > Or maybe since it states "Scheduling refresh of Service" it's not > synchronous, and thus we're possibly dealing with a race condition? This is likely. I'm fairly certain that Puppet collects restart requests during the run and then only does a single restart of each service at the end. Cli scripts however should not require a restart of apache or hhvm as they are run in dedicated interpreters. I think your investigations are likely on the right track though. If doing the imports works on a second puppet run then we have missed expressing some dependency in the Puppet manifests.
I have confirmation that despite puppet being asked to install php-luasandbox and hhvm-luasandbox and having them required as dependencies, running a mwscript command from cli will show that the PHP extension isn't installed. Sleeping for 10 seconds doesn't help. Test files used to draw that conclusion: https://phabricator.wikimedia.org/P10 https://phabricator.wikimedia.org/P11 https://phabricator.wikimedia.org/P12 phpinfo.php is a small script thrown into /maintenance that runs... phpinfo Not sure how to take it from here. Clearly puppet is "finalizing" the installation of the php extension in some teardown step of "vagrant provision", or it needs to current shell/process to be over before the change is visible to clis it launches.
I've also noticed that the php-luasandbox has a dirty uninstall. Purging it with puppet leaves the .ini files behind while unlinking the .so library, making PHP spew errors about the missing dynamic library.
It would be great if people who've been working on php-luasandbox (Ori? Brad?) can shed some light about how it's packaged, and specifically what might be going on with the way the php .ini files are installed in relation to puppet.
If vagrant is using hhvm, you need hhvm to be restarted, not apache. I don't think this has anything to do with the packaging.
how do you restart hhvm? i tried adding the following to the scribunto role, but it didn’t work: notify => Service['apache2, hhvm']
I had the zend role enabled during all my testing. I verified that the php cli wasn't using hhvm.
