core/0 doesn't start correctly #43
Comments
|
|
Processes that were running on core/0: |
|
|
|
On an m1.small without postgresql_gateway, core/0 started successfully. |
|
acm is still not running and confirmed by monit.log |
|
acm startup error: |
|
Why is postgres binding to public IP? From its startup.log |
|
Bah, at the very least it looks like I built off |
|
I am having this issue. Whats going wrong ? How do I debug the problem ? Preparing DNS Creating bound missing VMs Binding instance VMs Preparing configuration Updating job core Error 400007: `core/0' is not running after update Task 3 error |
|
If you re-run "bosh deploy" does it work? Next run: bosh ssh core/0 And see if you can find out what's not starting (in time). On Wed, Mar 13, 2013 at 9:45 AM, Pradeep Tummala notifications@github.com
|
|
Nothing is running on core/0. I had decreased number of workers to 4. Is that a problem ? [UTC Mar 14 05:44:04] info : 'system_ce923067-79b4-4dbb-b707-ea798617b322' Monit reloaded |
|
I forgot to mention I am executing "bosh cf deploy" |
|
Deleted deployment and started again. Still same problem. |
|
If apps aren't starting, then your monit logs are the place to go first: tail -f -n 200 /var/vcap/monit/monit.log On Thu, Mar 14, 2013 at 3:13 AM, Pradeep Tummala
Dr Nic Williams |
|
I had mentioned the monit logs in my previous comment. Here it is again, [UTC Mar 14 05:44:04] info : 'system_ce923067-79b4-4dbb-b707-ea798617b322' Monit reloaded |
|
Sorry that wasn't very enlightening was it. I forgot that cf-release monit doesn't have the monit_wrapper from bosh-gen. All the job logs are in /var/vcap/sys/log// Dr Nic Williams On Thu, Mar 14, 2013 at 10:26 PM, Pradeep Tummala
|
|
Tuning OpenStack to respect cloud foundry demands. Will run the whole process once again and let you know. |
|
1 doubt - Are the worker VMs supposed to get deleted before core VM starts ? All the 10 VMs are spawning perfectly then after few steps core VM spawns and workers vanish. Also, is it ok if I reduce number of workers to say,4 or 6 ? |
|
Inside var/vcap/sys/log/monit, log contents of various jobs are /var/vcap/jobs/cloud_controller/config/sudoers: parsed OK router looks fine - rsyslog start/running, process 14878 nats net.ipv4.neigh.default.gc_thresh3 = 4096 Postgresql kernel.shmmax = 284934144 The database cluster will be initialized with locale en_US.UTF-8. fixing permissions on existing directory /var/vcap/store/postgres ... ok Success. You can now start the database server using: or Starting PostgreSQL: |
|
uaa [2013-03-15 13:16:30.060] batch/batch - 15046 [localhost-startStop-1] .... DEBUG --- DelegatingFilterProxy: Initializing filter 'springSecurityFilterChain' |
|
Please check the above mentioned logs. I cant understand the root cause of the problem,esp. of cloud controller Thanks |
|
As I understand things this is correct behaviour. The worker VMs are spawned to compile the source into packages stored in The core VM is then started and those compiled packages are installed from If you On 15 March 2013 10:29, Pradeep Tummala notifications@github.com wrote:
David Laing |
|
Thanks mate. That clears few things. It's a bit difficult for me to reverse engineer cloud foundry code. The architecture is quite complex. |
|
Pradeep, he's technically describing bosh behaviour. You've still got CF architecture to learn. :) On Sun, Mar 17, 2013 at 11:44 AM, Pradeep Tummala
|
|
Correct me here, The packages like health manager, cloud controller and others belong to CF. Yes, you are right. There's lot to learn including OpenStack (going On Monday, March 18, 2013, Dr Nic Williams wrote:
|
|
@drnic I am not able to get past this core/0 error. Can you please look at the logs and see whats going wrong. Thanks ==> /var/vcap/sys/log/uaa/varz.log <== ==> /var/vcap/sys/log/vcap_redis/vcap_redis.log <== ==> /var/vcap/sys/log/vcap_registrar/vcap_registrar.log <== ==> /var/vcap/sys/log/vcap_registrar/vcap_registrar.stderr.log <== ==> /var/vcap/sys/log/vcap_registrar/vcap_registrar.stdout.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/health_manager_next_ctl.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/cloud_controller/db_migrate.stderr.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.stderr.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/health_manager_next_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/cloud_controller/db_migrate.stderr.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.stderr.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/health_manager_next_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/cloud_controller/db_migrate.stderr.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.stderr.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/health_manager_next_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/cloud_controller/db_migrate.stderr.log <== ==> /var/vcap/sys/log/monit/cloud_controller_ctl.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.log <== ==> /var/vcap/sys/log/health_manager_next/health_manager_next.stderr.log <== |
|
A new error Updating job core Error 450001: Expected sha1: b6c18cb2c5b7baf55f7d0b4cc655d24f52535821, Downloaded sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709: ["/var/vcap/bosh/agent/lib/agent/util.rb:42:in Task 66 error |
|
Resyncing blobs and checking again Backing to original error. |
|
Im stuck in this same issue |
|
I am a new bosh user but concerning cloudfoundry it cannot work: using release 130 (I don't know if it is linked) the configs files in the core/0 vm make some services listening on localhost or local address (nats for instance) and most of services are using the public ip . I checked on the cf-release and it is clear that the ref are not the same : From /cf-release / jobs / health_manager_next / templates / health_manager_next.yml.erb mbus: nats://<%= properties.nats.user %>:<%= properties.nats.password %>@<%= properties.nats.address %>:<%= properties.nats.port %>and From /cf-release / jobs / nats / templates / nats.yml.erb (updated 4 month ago) net: <%= spec.networks.send(properties.networks.apps).ip %> |
Does it start correctly on the VM (and need to increase the timeout?)
The text was updated successfully, but these errors were encountered: