Kayode,

I am using the default bosh-lite-v231.yml file and the instances for nfs
server is set to 0:

vagrant(a)agent-id-bosh-0:~$ egrep -i "name:.*nfs|instances"
bosh-lite-v231.yml.1603041454
etc...
- instances: 0
- instances: 0
- instances: 0
name: nfs_z1
- name: debian_nfs_server
- instances: 1
- instances: 1
- instances: 1
etc...

So it is not running.

Thanks,

I checked the blobstore is running:

root(a)e83575d2-dfbf-4f7c-97ee-5112560fa137:/var/vcap/sys/log# monit summary
The Monit daemon 5.2.4 uptime: 4h 14m
Process 'consul_agent' running
Process 'metron_agent' running
Process 'blobstore_nginx' running
Process 'route_registrar' running
System 'system_e83575d2-dfbf-4f7c-97ee-5112560fa137' running

But there are thousands of errors saying DopplerForwarder: can't forward
message, loggregator client pool is empty:

root(a)e83575d2-dfbf-4f7c-97ee-5112560fa137:/var/vcap/sys/log# find . -name
"*.log" | xargs grep -i error | cut -c 73-500 | sort -u
,"process_id":246,"source":"metron","log_level":
"error","message":"DopplerForwarder: can't forward message","data":{
"error":"loggregator client pool is empty"},

"file":"/var/vcap/data/compile/metron_agent/loggregator/src/metron/writers/dopplerforwarder/doppler_forwarder.go",
"line":104,

"method":"metron/writers/dopplerforwarder.(*DopplerForwarder).networkWrite"}

Not sure what is wrong.

The log lines saying "/var/vcap/sys/run/cloud_controller_ng/cloud_controller.sock
is not found" is probably just a symptom of the problem, not the root
cause. You're probably seeing those in the nginx logs? Cloud Controller
is failing to start, hence it is not establishing a connection on the
socket. You need to dig deeper into failures in logs in
/var/vcap/sys/log/cloud_controller_ng.

On Sun, Mar 6, 2016 at 10:00 AM, sridhar vennela <
sridhar.vennela(a)gmail.com> wrote:

Hi Wayne,

Looks like it, It is trying to connect to loggregator and failing I guess.


https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/controllers/runtime/syslog_drain_urls_controller.rb

Thank you,
Sridhar

Le 18 févr. 2016 à 11:19, Nitta, Minoru <minoru.nitta(a)jp.fujitsu.com> a écrit :

Hi guys,

I know monit executes connection testing to some processes in CloudFoundry VM
by issuing HTTP requests.
e.g. (in UAA case)
if failed port <%= p('uaa.port') %> protocol http
request "/healthz"
with timeout 60 seconds for 10 cycles
then restart

I am wondering how timeout and cycles configuration values are decided. I mean, are there
any policies or guidelines to set these values? It seems that different values are set to
each process so I guessed there might be any policies in CloudFoundry.

Regards,
Minoru Nitta

Hi CF Colleagues,

I see various PaaS providers provide the UI for entering the User provided
variables' key and value, but they dont seem to validate the "key" at the
save ["set-env"] phase, the validation happens only at
the restage phase. This is also because CF does the same. Is there any
reason that CC doesnt validate keys of user defined environment varibles at
the cf set-env phase ?

Examples:
1.cf set-env spring-music !@#$$%% "foobar" succeeds, but the restage
fails throwing /bin/bash: line 6: export: `!@#49%%=foobar': not a valid
identifier
2.cf set-env spring-music "!@#$$%%" "foobar" succeeds, the restage also
succeeds but the same as above is thrown as message here.

P.S: The above variables are used for only testing purposes and these
would give errros at the runtime usage in the application is implicit here.


Regards,
Ponraj