When I run this command it shows an error:
C:\wamp64\www>php upgrade-code.phar recompose --write
Upgrading PHP constraint
========================
Done.
Rebuilding dependencies
=======================
! [NOTE] Trying to re-require all packages
* Requiring php:">=5.6" ......... ✔
* Requiring silverstripe/recipe-core:"4.3.0" ....................................................................................... ✔
* Requiring silverstripe/recipe-cms:"*" .................................................................................................................................... ✔
* Requiring silverstripe/reports:"*" ............................................................................................................................................... ✔
* Requiring silverstripe/siteconfig:"*" ............................................................................................................................. ✔
* Requiring silverstripe-themes/simple:"*" .............................................................................................................................. ✔
In Process.php line 1236:
The process "composer update --working-dir="C:\Users\PKGUPT~1\AppData\Local\Temp\ss-upgrader-5c53e7ac309a8" --prefe
r-stable --ignore-platform-reqs --no-plugins" exceeded the timeout of 60 seconds.
recompose [-d|--root-dir ROOT-DIR] [-w|--write] [-S|--strict] [-R|--recipe-core-constraint [RECIPE-CORE-CONSTRAINT]] [--cwp-constraint [CWP-CONSTRAINT]] [-P|--composer-path [COMPOSER-PATH]] [-Q|--quick]
Related
Install NebulaGraph
sudo rpm -ivh nebula-graph-3.3.0.el7.x86_64.rpm
Start NebulaGraph
sudo /usr/local/nebula/scripts/nebula.service start all
[INFO] Starting nebula-metad...
[INFO] Done
[INFO] Starting nebula-graphd...
[INFO] Done
[INFO] Starting nebula-storaged...
[INFO] Done
Run the following command to check the service status of NebulaGraph.
sudo /usr/local/nebula/scripts/nebula.service status all
The returned result is the following one, there is a problem in nebula-graphd. How do I deal with this issue?
[INFO] nebula-metad(33fd35e): Running as 29020, Listening on 9559
[INFO] nebula-graphd(33fd35e): Running as 29095, Listening on 9669
[WARN] nebula-storaged after v3.0.0 will not start service until it is added to cluster.
[WARN] See Manage Storage hosts:ADD HOSTS in https://docs.nebula-graph.io/
[INFO] nebula-storaged(33fd35e): Running as 29147, Listening on 9779
Best to my knowledge, starting from NebulaGraph 3.0.0, the Meta service cannot directly read or write data in the Storage service that you add in the configuration file. The configuration file only registers the Storage service to the Meta service.
You must run the ADD HOSTS command to enable the Meta to read and write data in the Storage service.
A deployment fails with the following message:
Phusion Passenger(R) doesn't seem to be running. If you are sure that it
is running, then the causes of this problem could be one of:
[...]
• You customized Nginx's passenger_instance_registry_dir option
• The instance directory has been removed by an operating system background service. Please set a different instance registry directory Phusion Passenger(R) Standalone's --instance-registry-dir command line argument.
[...]
DEBUG [25d4f5b4] *** Cleaning stale instance directory /tmp/passenger.7OMaC6P
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.7OMaC6P/.
*** Cleaning stale instance directory /tmp/passenger.0bmUABH
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.0bmUABH/.
*** Cleaning stale instance directory /tmp/passenger.n1oLEes
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.n1oLEes/.
*** Cleaning stale instance directory /tmp/passenger.RXBYda3
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.RXBYda3/.
*** Cleaning stale instance directory /tmp/passenger.TrAwTXq
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.TrAwTXq/.
*** Cleaning stale instance directory /tmp/passenger.vZaExdN
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.vZaExdN/.
*** Cleaning stale instance directory /tmp/passenger.dqTKpv1
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.dqTKpv1/.
*** Cleaning stale instance directory /tmp/passenger.hh2TxgL
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.hh2TxgL/.
*** Cleaning stale instance directory /tmp/passenger.rjowwmi
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.rjowwmi/.
passenger-status runs. However two pids are shown
App root: /home/deploy/margin/current
Requests in queue: 0
* PID: 110639 Sessions: 0 Processed: 46 Uptime: 12h 29m 50s
CPU: 1% Memory : 409M Last used: 2m 50s
* PID: 141836 Sessions: 0 Processed: 0 Uptime: 2m 46s
CPU: 0% Memory : 17M Last used: 2m 46s ago
Installation occured via these commands:
sudo apt-get install -y nginx-extras libnginx-mod-http-passenger
if [ ! -f /etc/nginx/modules-enabled/50-mod-http-passenger.conf ]; then sudo ln -s /usr/share/nginx/modules-available/mod-http-passenger.load /etc/nginx/modules-enabled/50-mod-http-passenger.conf ; fi
sudo ls /etc/nginx/conf.d/mod-http-passenger.conf
the conf file has
passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini;
passenger_ruby /home/deploy/.rbenv/shims/ruby;
While there is documentation on this matter, it does not cover a gap in understanding - and thus does not mitigate risk. Namely:
• rather, is not a question of all these stale instances which is gumming up the works? How to get rid of properly?
• uncertainty as to whether passenger standalone or nginx variant is running - how to verify?
• there is no recollection of ever touching passenger_instance_registry_dir
• if a system background service has been run to change the instance directory, how can one verify?
• what is good practice for eventually setting and instance directory?
I just followed the openstack rally quick start guide to create a tempest verifier with Rally v0.9.1 in an Openstack Ocata/stable deployment. The command failed:
(rally-15.1.2) root#infra1-utility-container-f31faeb0:~/.rally/verification# rally verify create-verifier --type tempest --name tempest-verifier
2017-05-21 07:53:13.410 11422 INFO rally.api [-] Creating verifier 'tempest-verifier'.
2017-05-21 07:53:13.528 11422 INFO rally.verification.manager [-] Cloning verifier repo from https://git.openstack.org/openstack/tempest.
2017-05-21 07:53:37.174 11422 INFO rally.verification.manager [-] Creating virtual environment. It may take a few minutes.
2017-05-21 07:53:42.323 11422 ERROR rally.verification.utils [-] Failed cmd: '['pip', 'install', '-e', './']'
2017-05-21 07:53:42.324 11422 ERROR rally.verification.utils [-] Error output: 'Obtaining file:///root/.rally/verification/verifier-091a49ab-1241-40a3-bc9b-531d7f091e37/repo
Collecting pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178)
Could not find a version that satisfies the requirement pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178) (from versions: 1.10.0)
No matching distribution found for pbr!=2.1.0,>=2.0.0 (from tempest==16.0.1.dev178)
'
Command failed, please check log for more info
As the current version of pbr is 2.0.0, I'm not sure why pbr installation failed.
(rally-15.1.2) root#infra1-utility-container-f31faeb0:~/.rally/verification# pip freeze|grep pbr
pbr==2.0.0
The question is how to adjust the requirement checking for pbr? or is it possible to choose an older version of tempest?
Thanks.
It solved.
After uploading the two missing python packages: os_testr-0.8.2-py2-none-any.whl and testrepository-0.0.19.tar.gz into local repo, which is a lxc container had been created by openstack-ansible, the Tempest plugin was finally installed.
I am trying use the package manager in chef and installing nginx server but every time i ran the cook book on my client it is just saying that
Recipe: nginx::default
* yum_package[nginx] action install[2017-03-11T06:16:01-05:00] INFO: Processing yum_package[nginx] action install (nginx::default line 11)
* No candidate version available for nginx
================================================================================
Error executing action `install` on resource 'yum_package[nginx]'
================================================================================
Chef::Exceptions::Package
-------------------------
No candidate version available for nginx
Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/nginx/recipes/default.rb
11: package "nginx" do
12: action :install
13: end
14:
Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/nginx/recipes/default.rb:11:in `from_file'
yum_package("nginx") do
package_name "nginx"
action [:install]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :package
cookbook_name "nginx"
recipe_name "default"
flush_cache {:before=>false, :after=>false}
end
Platform:
---------
x86_64-linux
[2017-03-11T06:16:29-05:00] INFO: Running queued delayed notifications before re-raising exception
Running handlers:
[2017-03-11T06:16:29-05:00] ERROR: Running exception handlers
Running handlers complete
[2017-03-11T06:16:29-05:00] ERROR: Exception handlers complete
Chef Client failed. 1 resources updated in 05 minutes 44 seconds
And even i tried to install epel-release packages but denied with similar errors.
Any idea how we could install nginx with CHEF recipe.
I tried also using yum_package but had no luck in installing
yum_package "nginx" do
action :install
end
Thanks
This means there is no package named nginx in your repositories. If you log into the machine you want to provision (With kitchen login, for example), you can try to search package nginx.
The best way to install it if it is not in your repositories is either adding nginx´s official repo with a chef repository resource (Like yum_repository for Centos) or downloading the tarball with Chef resource remote_file.
If you choose the last option, be sure to generate a sha256 of the tarball you download and add it to the remote_file resource, so among other things you prevent Chef from downloading every run the file.
-Edit-
As Szymon says, you can also use the Nginx cookbook for this and don't write any special recipe.
As discussed here, you can use official NGINX chef cookbook or just install epel-release before installing NGINX:
if platform_family?('rhel')
package 'epel-release'
end
if platform_family?('debian')
apt_update 'update'
end
package 'nginx'
I have a WooCommerce store here: http://vanuatucoffeeroasters.com
Sometime between Jan. 17 and Jan. 26, the admin email notifications stopped working. However, when I place an order, I get a user email notification just fine.
What I have tried:
Testing wp_mail using Email Log plugin (sends successfully)
Testing PHP Mail using PHP mail test script (sends successfully)
Sending email to the email address that's not receiving notifications (successful)
Whitelisting the IP address of the sending server (no effect)
Deactivating and reactivating WooCommerce (no apparent effect)
Here is my system report:
WordPress Environment
Home URL: http://vanuatucoffeeroasters.com
Site URL: http://vanuatucoffeeroasters.com
WC Version: 2.4.10
Log Directory Writable: ✔ /nfs/c07/h01/mnt/99231/domains/vanuatucoffeeroasters.com/html/wp-content/uploads/wc-logs/
WP Version: 4.3.8
WP Multisite: –
WP Memory Limit: 40 MB - We recommend setting memory to at least 64MB. See: Increasing memory allocated to PHP
WP Debug Mode: –
Language: en_US
Server Environment
Server Info: Apache/2.2.22
PHP Version: 5.6.21
PHP Post Max Size: 64 MB
PHP Time Limit: 300
PHP Max Input Vars: 7000
SUHOSIN Installed: –
MySQL Version: 5.1.72
Max Upload Size: 64 MB
Default Timezone is UTC: ✔
fsockopen/cURL: ✔
SoapClient: ✔
DOMDocument: ✔
GZip: ✔
Remote Post: ✔
Remote Get: ✔
Database
WC Database Version: 2.4.10
:
woocommerce_api_keys: ✔
woocommerce_attribute_taxonomies: ✔
woocommerce_termmeta: ✔
woocommerce_downloadable_product_permissions: ✔
woocommerce_order_items: ✔
woocommerce_order_itemmeta: ✔
woocommerce_tax_rates: ✔
woocommerce_tax_rate_locations: ✔
Active Plugins (12)
Column Shortcodes: by Codepress – 0.6.6
Contact Form 7: by Takayuki Miyoshi – 4.3.1
Custom Sidebars: by WPMU DEV – 2.1.0.2
Email Log: by Sudar – 1.9.1
Bundle Rate Shipping Module for WooCommerce: by Eric Daams – 1.3.3
Regenerate Thumbnails: by Alex Mills (Viper007Bond) – 2.2.6
Smart WYSIWYG Blocks Of Content: by Coen Jacobs – 0.6.1
Responsive WordPress Slider - Soliloquy Lite: by Thomas Griffin – 2.4.0.8
Sucuri Security - Auditing, Malware Scanner and Hardening: by Sucuri
Inc – 1.8.3
WooCommerce Product Archive Customiser: by jameskoster – 0.5.0
WooCommerce: by WooThemes – 2.4.10
Yoast SEO: by Team Yoast – 3.0.7
Settings
Force SSL: –
Currency: USD ($)
Currency Position: left_space
Thousand Separator: ,
Decimal Separator: .
Number of Decimals: 2
API
API Enabled: ✔
API Version: 3.0.0
WC Pages
Shop Base: #715 - /buy-a-bag/
Cart: #659 - /cart/
Checkout: #451 - /checkout/
My Account: #452 - /my-account/
Taxonomies
Product Types: external (external)
grouped (grouped)
simple (simple)
variable (variable)
Theme
Name: LaMonte
Version: 1.2
Author URL: http://www.templatesquare.com/
Child Theme: ✔
Parent Theme Name: Klasik
Parent Theme Version: 0.7.13
Parent Theme Author URL: http://www.klasikthemes.com/
WooCommerce Support: ✔
Templates
Overrides: klasik/woocommerce/archive-product.php
There is a bit of an odd issue with contact form 7 at the moment if you are using recaptcha plugins, if you use these turn them off for testing and then try a different plugin.
This is not exactly an answer, but somehow this problem has fixed itself. And the client is shutting down the site, so it is no longer an issue.