I have been using a vagrant setup with VirtualBox for two weeks now and it was working fine. Yesterday I tried to use vagrant and found that none of the commands work. They all result in an error with a callstack (in Ruby?).
I am using Windows 7 with VirtualBox 4.3.12 (because my corporate environment uses BeyondTrust and 4.3.12 was the only version I could get to work).
windows> vagrant status --debug
...
INFO manager: Registered plugin: SMB synced folders
INFO global: Loading plugins!
INFO manager: Registered plugin: vagrant-share
INFO vagrant: `vagrant` invoked: ["reload", "--debug"]
DEBUG vagrant: Creating Vagrant environment
INFO environment: Environment initialized (#<Vagrant::Environment:0x265c728>)
INFO environment: - cwd: C:/Users/Scott/hootenanny
INFO environment: Home path: C:/Users/Scott/.vagrant.d
INFO environment: Local data path: C:/Users/Scott/hootenanny/.vagrant
DEBUG environment: Creating: C:/Users/Scott/hootenanny/.vagrant
INFO environment: Running hook: environment_plugins_loaded
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_plugins_loaded #<Vagrant::Action::Builder:0x385ff50>
INFO environment: Running hook: environment_load
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_load #<Vagrant::Action::Builder:0x3731b38>
INFO cli: CLI: [] "reload" []
DEBUG cli: Invoking command class: VagrantPlugins::CommandReload::Command []
DEBUG command: 'reload' each target VM...
DEBUG command: Getting target VMs for command. Arguments:
DEBUG command: -- names: []
DEBUG command: -- options: nil
DEBUG command: Loading all machines...
INFO loader: Set :root = ["#<Pathname:C:/Users/Scott/hootenanny/Vagrantfile>"]
DEBUG loader: Populating proc cache for #<Pathname:C:/Users/Scott/hootenanny/Vagrantfile>
DEBUG loader: Load procs for pathname: C:/Users/Scott/hootenanny/Vagrantfile
INFO loader: Loading configuration in order: [:home, :root]
DEBUG loader: Loading from: root (evaluating)
DEBUG provisioner: Provisioner defined:
DEBUG provisioner: Provisioner defined:
DEBUG provisioner: Provisioner defined:
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
INFO loader: Set "23533380_machine_default" = []
INFO loader: Loading configuration in order: [:home, :root, "23533380_machine_default"]
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
DEBUG base: Windows, checking for VBoxManage on PATH first
INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "--version"]
INFO subprocess: Command not in installer, restoring original environment...
INFO environment: Running hook: environment_unload
INFO host: Autodetecting host type for [#<Vagrant::Environment: C:/Users/Scott/hootenanny>]
DEBUG host: Trying: arch
DEBUG host: Trying: darwin
DEBUG host: Trying: freebsd
DEBUG host: Trying: gentoo
DEBUG host: Trying: redhat
DEBUG host: Trying: slackware
DEBUG host: Trying: suse
DEBUG host: Trying: bsd
DEBUG host: Trying: linux
DEBUG host: Trying: null
DEBUG host: Trying: windows
INFO host: Detected: windows!
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 1 hooks defined.
INFO runner: Running action: environment_unload #<Vagrant::Action::Builder:0x370c440>
C:/HashiCorp/Vagrant/embedded/gems/gems/childprocess-0.5.8/lib/childprocess/windows/handle.rb:12:in `open': Access is denied. (5) (ChildProcess::Error)
from C:/HashiCorp/Vagrant/embedded/gems/gems/childprocess-0.5.8/lib/childprocess/windows/process.rb:70:in `launch_process'
from C:/HashiCorp/Vagrant/embedded/gems/gems/childprocess-0.5.8/lib/childprocess/abstract_process.rb:82:in `start'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:122:in `block in execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/safe_chdir.rb:26:in `block (2 levels) in safe_chdir'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/safe_chdir.rb:25:in `chdir'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/safe_chdir.rb:25:in `block in safe_chdir'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/safe_chdir.rb:24:in `synchronize'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/safe_chdir.rb:24:in `safe_chdir'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:121:in `execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/subprocess.rb:22:in `execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/base.rb:430:in `block in raw'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/base.rb:429:in `raw'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/base.rb:367:in `block in execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/retryable.rb:17:in `retryable'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/base.rb:362:in `execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/meta.rb:159:in `block in read_version'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/retryable.rb:17:in `retryable'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/meta.rb:158:in `read_version'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/meta.rb:46:in `block in initialize'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/meta.rb:41:in `synchronize'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/driver/meta.rb:41:in `initialize'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/provider.rb:20:in `new'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/providers/virtualbox/provider.rb:20:in `usable?'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:381:in `block in default_provider'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:379:in `each'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:379:in `default_provider'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:174:in `block in with_target_vms'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:210:in `call'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:210:in `block in with_target_vms'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:209:in `map'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/plugin/v2/command.rb:209:in `with_target_vms'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/commands/reload/command.rb:37:in `execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/cli.rb:42:in `execute'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:302:in `cli'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.8.1/bin/vagrant:174:in `<main>'
I have tried:
1) Reinstall vagrant
2) Reinstall VirtualBox
3) Checking permissions in c:/users/scott/.vagrant.d
4) Checking permissions in c:/users/scott/hootenanny/.vagrant
Of course any help is appreciated.
Scott
You could try moving your Vagrant root install directory from C:\Hashicorp to a folder under your User directory ie. C:\Users\Scott\Hashicorp and see if that eliminates any of the issues you have with running. Occasionally IT gets overzealous and anything outside of the user directories get declared read only in case of viruses trying to take over the system.
You may want to see if there is an option to the installer to change the path, otherwise you will probably need to edit the registry entries and shortcuts to point to the new location, which also may require editing your path. If you have administrator access (I'd assume you do if you can uninstall updates) then you should be able to perform all of the above.
I removed all the latest Microsoft security updates for .NET and Windows and Vagrant started working again. They were dated 3/24/2016 on my machine. Then just as I was trying to learn more, the corporate machine I'm on reinstalled the updates. There is nothing I can do about that. My company uses Microsoft Windows 7 Enterprise and I really shouldn't be uninstalling their security updates as I am an engineer, not a system admin.
I hope this information helps someone else who was staring at the same Ruby callstack and wondering what to do.
I have also solved the problem by running Git bash as admin and calling vagrant up through that elevated console.
Thanks to codecomp, who replied on the similiar issue at https://laracasts.com/discuss/channels/servers/vagrant-up-failing-trying-to-add-to-hosts
I had this same problem and it turned out that I did not have VirtualBox installed. As soon as I installed virtualbox, this error disappeared and vagrant status worked as expected (I also am working on a machine which is encumbered by many enterprise security applications, which may be why vagrant did not give me a more helpful error message).
I know this doesn't help OP, but thought I'd share my experience for the next person that follows a google search to this page.
Related
I am writing a Rails 5 application that will be deployed to a RHEL7 host that uses an NFS mount for storage.
The application uses the CarrierWave plugin to write uploaded files to an NFS mount on the RHEL7 host.
class ExampleUploader < CarrierWave::Uploader::Base
# Choose what kind of storage to use for this uploader:
storage :file
def store_dir
"#{Rails.root.to_s}/#{model.class.to_s.underscore}/#{model.id}"
end
end
The code works in a local development environment (on a laptop), however, the same code stops working when deployed to the RHEL7 server.
Puma caught this error: Operation not supported - copy_file_range (Errno::EOPNOTSUPP)
/usr/local/lib/ruby/2.5.0/fileutils.rb:1293:in `copy_stream'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1293:in `block (2 levels) in copy_file'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1292:in `open'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1292:in `block in copy_file'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1291:in `open'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1291:in `copy_file'
/usr/local/lib/ruby/2.5.0/fileutils.rb:432:in `copy_file'
/usr/local/lib/ruby/2.5.0/fileutils.rb:359:in `block in cp'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1463:in `block in fu_each_src_dest'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1479:in `fu_each_src_dest0'
/usr/local/lib/ruby/2.5.0/fileutils.rb:1461:in `fu_each_src_dest'
/usr/local/lib/ruby/2.5.0/fileutils.rb:358:in `cp'
/usr/local/bundle/gems/carrierwave-0.11.2/lib/carrierwave/sanitized_file.rb:213:in `copy_to'
Based on my research, copy_file_range function was disabled in RHEL7 and that's the low-level function that Ruby is supposed to be using to write files. So that means Ruby cannot write to an NFS mount on a RHEL7 host.
https://bugs.ruby-lang.org/issues/16965
http://sourceware-org.1504.n7.nabble.com/Bug-build-26338-New-io-tst-copy-file-range-fails-on-RHEL-7-8-hosts-td645473.html
It looks like there was a recent update made but that simply changed the type of error message, it didn't actually fix the issue.
https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/93df3010482ad52e5ada2e416c996005da956e1e
Question: What are our options for getting this to work? Are there any patches available for Ruby? Or do we need to deploy this on another operating system aside from RHEL7? If so, what OS actually supports Ruby writing to an NFS mount?
This was fixed after updating the host operating system to the latest version of RHEL7.
I installed a vagrant plugin "vagrant-certificates" and added the following config to my ~/.vagrant.d/Vagrantfile
if !['plugin', 'box'].include? ARGV[0]
unless Vagrant.has_plugin?("vagrant-ca-certificates")
raise "Missing required plugin 'vagrant-certificates', run `vagrant plugin install vagrant-certificates`\n"
end
end
config.certificates.enabled = true
config.certificates.certs = Dir.glob('/home/myhomedirectory/.vagrant.d/*.crt')
and the plugin won't run. Other people that I know who are using that plugin get the following output when they run vagrant up:
==> machine: Uploading root certificates to guest instance...
==> machine: -- /var/folders/mb/1pt7p7zd4q736lq4vdq_309w0000gn/T/vagrant-certificates20200122-60457-
wop57o => /usr/share/ca-certificates/private/BA%20ROOT.crt
==> machine: -- /var/folders/mb/1pt7p7zd4q736lq4vdq_309w0000gn/T/vagrant-certificates20200122-60457-
3v8nhs => /usr/share/ca-certificates/private/BA%20NPE%20CA-3%281%29.crt
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
but I see no output related to certs:
and I'm getting an ssl error which indicates that the certs that I need have not been installed.
Can anybody help me debug this?
EDIT: Other ways I've tried to specify the certs:
config.certificates.certs = [
"./certROOT.crt",
"./certNPE_CA_3.crt"
]
config.certificates.certs = [
"http://pki.mycorp.org/certs/certROOT.crt",
"http://pki.mycorp.org/certs/certNPE_CA_3.crt"
]
EDIT 2: Output of vagrant up --debug 2>&1 >/dev/null | grep -i certificate
INFO manager: - vagrant-certificates = [installed: 2.0.0 constraint: > 0]
DEBUG bundler: Current generated plugin dependency list: [<Gem::Dependency type=:runtime name="vagrant-certificates" requirements="= 2.0.0">]
DEBUG bundler: Activating solution set: ["vagrant-certificates-2.0.0"]
DEBUG bundler: Activating gem vagrant-certificates-2.0.0
INFO manager: Loading plugin `vagrant-certificates` with default require: `vagrant-certificates`
INFO manager: Registered plugin: vagrant-certificates
DEBUG manager: Successfully loaded plugin `vagrant-certificates`.
INFO manager: - vagrant-certificates = [installed: 2.0.0 constraint: > 0]
DEBUG bundler: Current generated plugin dependency list: [<Gem::Dependency type=:runtime name="vagrant-certificates" requirements="= 2.0.0">]
DEBUG bundler: Activating solution set: ["vagrant-certificates-2.0.0"]
DEBUG bundler: Activating gem vagrant-certificates-2.0.0
INFO manager: Loading plugin `vagrant-certificates` with default require: `vagrant-certificates`
DEBUG manager: Successfully loaded plugin `vagrant-certificates`.
INFO warden: Calling IN action: #<VagrantPlugins::Certificates::Action::InstallCertificates:0x0000000002eea438>
INFO warden: Calling OUT action: #<VagrantPlugins::Certificates::Action::InstallCertificates:0x0000000002eea438>
DEBUG subprocess: stdout: fatal: [k8s-master]: FAILED! => {"changed": false, "msg": "Failed to validate the SSL certificate for packages.cloud.google.com:443. Make sure your managed systems have a valid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificat
s/cacert.org, /etc/ansible. The exception msg was: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)."}
INFO interface: detail: fatal: [k8s-master]: FAILED! => {"changed": false, "msg": "Failed to validate the SSL certificate for packages.cloud.google.com:443. Make sure your managed systems have a valid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible. The exception msg was: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)."}
When a machine gets rebooted. it fails on chef-client run(run from rc.local) but if i run it manually it gets success and same error return on next auto chef-run.when i restart the chef-client the error stop coming .
in fact when chef-client was failing on auto run ,ohai was giving the correct output.
root#something:~# ohai | grep 'fqdn'
"fqdn": "something.someone",
root#something:~# chef-client -v
Chef: 12.20.3
root#something:~# ohai -v
Ohai: 8.23.0
root#something:~# hostname -f
something.someone
Output of stacktrace
root#something:~# cat /var/chef/cache/chef-stacktrace.out Generated at
2018-04-02 15:36:30 +0000 Chef::Exceptions::CannotDetermineNodeName:
Unable to determine node name: configure node_name or configure the
system's hostname and fqdn
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:299:in
node_name'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:313:in
register'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:416:in
do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:213:in
block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:207:in
fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:207:in
run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application.rb:237:in
run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:338:in
block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:327:in
loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:327:in
run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application.rb:55:in
run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/bin/chef-client:26:in
' /usr/bin/chef-client:23:in load'
/usr/bin/chef-client:23:in'root#web1.cst.webpod1-cph3:~#
You've clearly got a mismatch in what you are running. Your CLI says Chef 12, but the stack trace says Chef 11. I'm guessing you installed one via our Omnibus packages and the other via Rubygems? No matter the cause, fix that conflict and you'll probably be happier.
I have tried to troubleshoot an UnknownError returned by the CodeDeploy Agent on an Amazon Linux EC2 instance. I push files from my local git repo on my Mac to a S3 bucket, and deploy from there to the EC2 instance.
I have edited the /etc/codedeploy-agent/conf/codedeployagent.yml and set :verbose: to true on a EC2 instance. I tried to deploy again and open codedeploy-agent.log at /var/log/aws/codedeploy-agent.
The last lines in log before failing shows that the agent installs ELB scripts provided by AWS.
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandBuilder: Copying /opt/codedeploy-agent/deployment-root/c6b25857-8911-4f61-8b30-b39f0c34c395/d-6UZ0VFID9/deployment-archive/scripts/stop_server.sh to /var/www/html/scripts/stop_server.sh
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandBuilder: Copying /opt/codedeploy-agent/deployment-root/c6b25857-8911-4f61-8b30-b39f0c34c395/d-6UZ0VFID9/deployment-archive/scripts/register_with_elb.sh to /var/www/html/scripts/register_with_elb.sh
2015-06-19 08:09:13 DEBUG [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Calling PutHostCommandComplete: "Code Error"
2015-06-19 08:09:13 INFO [codedeploy-agent(7637)]: [Aws::CodeDeployCommand::Client 200 0.084236 0 retries] put_host_command_complete(command_status:"Failed",diagnostics:{format:"JSON",payload:"{\"error_code\":5,\"script_name\":\"\",\"message\":\"\\\"\\\\xCC\\\" from ASCII-8BIT to UTF-8\",\"log\":\"\"}"},host_command_identifier:"WyJjb20uYW1hem9uLmFwb2xsby5kZXBsb3ljb250cm9sLmRvbWFpbi5Ib3N0Q29tbWFuZElkZW50aWZpZXIiLHsiZGVwbG95bWVudElkIjoiQ29kZURlcGxveS9ldS13ZXN0LTEvUHJvZC9hcm46YXdzOnNkczpldS13ZXN0LTE6NzMzNTE3MzY5MDAyOmRlcGxveW1lbnQvZC02VVowVkZJRDkiLCJob3N0SWQiOiJhcm46YXdzOmVjMjpldS13ZXN0LTE6NzMzNTE3MzY5MDAyOmluc3RhbmNlL2ktZWRjYTkzNDciLCJjb21tYW5kTmFtZSI6Ikluc3RhbGwiLCJjb21tYW5kUG9zaXRpb24iOjQsImNvbW1hbmRBdHRlbXB0IjoxfV0=")
The last files installed are not related. Since I also have tried to remove the scripts I mention above. The error seems to be upstream and Ruby related.
2015-06-19 08:09:13 ERROR [codedeploy-agent(7637)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Error during perform: Encoding::UndefinedConversionError - "\xCC" from ASCII-8BIT to UTF-8 - /opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `encode'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `to_json'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/install_instruction.rb:165:in `to_json'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:38:in `block in install'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:37:in `open'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:37:in `install'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:103:in `block in <class:CommandExecutor>'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_executor.rb:51:in `execute_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:123:in `process_command'
/opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/command_poller.rb:56:in `perform'
/opt/codedeploy-agent/lib/instance_agent/agent/base.rb:28:in `run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:38:in `block in run'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:37:in `run'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:70:in `block in run_with_error_handling'
/opt/codedeploy-agent/lib/instance_agent/runner/child.rb:55:in `with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:69:in `run_with_error_handling'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:33:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `loop'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/child.rb:22:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:198:in `block in spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:196:in `spawn_child'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:188:in `block in spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:187:in `times'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:187:in `spawn_children'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:133:in `start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:36:in `block in start'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:35:in `fork'
/opt/codedeploy-agent/vendor/gems/process_manager-0.0.13/lib/process_manager/master.rb:35:in `start'
/opt/codedeploy-agent/bin/codedeploy-agent:37:in `block (2 levels) in <main>'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/command_support.rb:130:in `execute'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:262:in `block in call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:275:in `call_command'
/opt/codedeploy-agent/vendor/gems/gli-2.5.6/lib/gli/app_support.rb:69:in `run'
/opt/codedeploy-agent/bin/codedeploy-agent:84:in `<main>'
I have tried $ grep --color -in -r '\xCC' /my/folder/ which returns something like
Binary file /my/folder/a.png matches
But also returned /my/folder/wp-content/plugins/wordpress-seo/admin/class-metabox.php:348:'Ì'
So I removed the plugin and tried to convert the filenames from ASCII to UTF-8 with convmv (it didn't convert anything). But without success.
I have also updated several gems according to a couple of StackOverflow threads.
How could I mitigate this error? I find the error message from Amazon CodeDeploy vaugue and hard to troubleshoot and I've run out of ideas.
Issue looks to be LANG env has not been set when Installing / Starting CodeDeploy.
I found that if I were to restart CodeDeploy via the CLI then the app would deploy without issue.
You can check the LANG env of the codedploy process by running
ps auxe |grep codede
We deploy CodeDeploy via puppet and have to set (environment => 'LANG=en_US.UTF-8') when running the install script.
Try updating codedeploy-agent. It worked for me.
SSH into your instance and run this command:
sudo /opt/codedeploy-agent/bin/install auto
The LANG environment variable must be defined when the deployment starts or else the CodeDeploy install event fails.
You can ensure that CodeDeploy has it by editing the CodeDeploy agent service configuration:
sudo vim /etc/init.d/codedeploy-agent
You can export the variable when the service first starts with this line: export LANG="en_US.UTF-8".
So the start block will look like this:
start() {
echo -n $"Starting $prog:"
export LANG="en_US.UTF-8"
cd $AGENT_ROOT
nohup $BIN start >/dev/null </dev/null 2>&1 # Try to start the server
exit $?
}
Some additional notes
For me the problem was only occurring during an auto scale event. In other words I could manually launch the instance and then deploy just fine, but not right when a new instance was launched. This indicates a race condition in the sense that the environment is not ready as soon as the service starts. I tried changing the upstart timing by running:
update-rc.d -f codedeploy-agent remove
update-rc.d codedeploy-agent start 99 2 3 4 5 . stop 20 0 1 6 .
but this did not work. Setting the variable in the start block guaranteed that it was available in time.
To ensure you have all required environment variables available to CodeDeploy as soon as it starts it's probably wise to follow Amazon's advice:
we recommend that you keep the agent service in a stopped state and use the launch scripts to start the agent service
I am trying to setup redmine on my server which is Redhat 6.2
I intend it to run with Nginx using thin ruby gem.
I was following http://www.redmine.org/projects/redmine/wiki/HowTo_configure_Nginx_to_run_Redmine
I did following things
gem install thin
thin install
this gives me init script under /etc/rc.d/thin The YML file config is as follows:
---
chdir: /app/redmine-root/
environment: development
address: 0.0.0.0
port: 5000
timeout: 30
log: log/thin.log
pid: tmp/pids/thin.pid
max_conns: 1024
max_persistent_conns: 100
require: []
wait: 30
servers: 4
daemonize: true
Now when I do /etc/rc.d/thin start it shows
Starting server on 0.0.0.0:5000 ...
Starting server on 0.0.0.0:5001 ...
Starting server on 0.0.0.0:5002 ...
Starting server on 0.0.0.0:5003 ...
but when I see pids under /app/redmine-root/tmp/pids there are no Pids.
therefore, I can't see any service running. This is issue number 1
Second thing I'd like to ask that, in Nginx conf as suggested by the above link the upstream block is like as follows:
upstream thin_cluster {
server unix:/tmp/thin.0.sock;
server unix:/tmp/thin.1.sock;
server unix:/tmp/thin.2.sock;
server unix:/tmp/thin.3.sock;
}
But the pid file is in /app/redmine-root/tmp/pids should this work?
Third, At the time of Install I marked the env as production
RAILS_ENV=production rake db:migrate
But whenever I do thin config -C /etc/thin/redmine.yml it changes to development.
Please note that I have RVM also. And the user & owner of /app/redmine-root/ is apache.
My nginx runs with apache and I am trying to run thin also as apache.
I have no background in Ruby. Any help is much appreciated.
EDIT
After suggestions, I found this in log.
/usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/tcp_server.rb:16:in `connect': cannot load such file -- thin/connection (LoadError)
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/base.rb:55:in `block in start'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `call'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:86:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:187:in `run_command'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:152:in `run!'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/bin/thin:6:in `<top (required)>'
from /usr/local/bin/thin:23:in `load'
from /usr/local/bin/thin:23:in `<main>'
is it because, I am trying to configure on UNIX socket or its something else??
You should add gem thin to your Gemfile
PS: see at https://github.com/macournoyer/thin/issues/115 for example.