pushing app fail with warden container log with info value empty #97
Comments
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/96417090. |
Hi @dagong123, Unfortunately we do not see the root cause of your error while looking at your logs. However, we do see that the application "Exited with status 1". You could try taking a look at some common issues and their fixes, particularly the section on "App Fails to Start". Hope this helps, |
Hi DanLavine, thanks for your reply. But the common logs for the failure cases was "memory_stat":"#","cpu_stat":"#","disk_stat":"#","bandwidth_stat":"#". I am wondering whether the warden container is started correctly with such log info? Can it be the env issue, for example, lack of memory or other resource for the new warden container that cause "info" request get the respond with informatin "memory_stat":"#","cpu_stat":"#","disk_stat":"#","bandwidth_stat":"#" ? Thanks. |
Hi @dagong123, The logs during the failure case are coming from an info request from the DEA to the Warden container. These are fairly common logs and on running applications and we noticed that before a container is destroyed, warden requests the info one last time for logging purposes (if the container is not already destroyed). Unfortunately we cannot determine why your application is failing based on what you provide. All logs for a particular application/warden handle from the DEA and Warden are required for a deeper investigation. If you think that the problem is memory, disk or cpu bound I would try going to the DEA which failed to run the application and checking the system health through common linux commands such as Hope this helps, |
Hi DanLavine, Here is the log related with my app push failure "Exited with status 1". Part of Dea log: And part of the warden log: /var/vcap/sys/log/warden/warden.log.1:531755:{"timestamp":1433214013.4829319,"message":"run (took 0.168858)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","request":{"handle":"18ndqsq7ilr","script":" set -o pipefail\n package_size= /var/vcap/sys/log/warden/warden.log.1:531756:{"timestamp":1433214013.5506377,"message":"Wrote snapshot in 0.000522","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr"},"thread_id":70313730315000,"fiber_id":70313770441960,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":334,"method":"write_snapshot"} /var/vcap/sys/log/warden/warden.log.1:531757:{"timestamp":1433214013.5508575,"message":"spawn (took 0.009004)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","request":{"handle":"18ndqsq7ilr","script":"set -o pipefail; export VCAP_APPLICATION={\"limits\":{\"mem\":512,\"disk\":1024,\"fds\":16384},\"application_version\":\"b0e41932-bcba-4bef-a568-53e7da2ae1f9\",\"application_name\":\"A1-StatusTestApp1433213994852\",\"application_uris\":[\"A1-StatusTestApp1433213994852.testXXX.net\"],\"version\":\"b0e41932-bcba-4bef-a568-53e7da2ae1f9\",\"name\":\"A1-StatusTestApp1433213994852\",\"space_name\":\"uptime\",\"space_id\":\"2f389dba-73b4-47fa-82de-90f73a4caa65\",\"uris\":[\"A1-StatusTestApp1433213994852.testXXX.net\"],\"users\":null};\nexport VCAP_SERVICES={};\nexport MEMORY_LIMIT="512m";\nexport BUILDPACK_CACHE="/var/vcap/packages/buildpack_cache";\nexport STAGING_TIMEOUT="900.0";\nexport MEMORY_LIMIT="512m";\nexport CF_STACK="lucid64";\n /usr/bin/ruby /var/vcap/packages/dea_next/buildpacks/bin/run /var/vcap/data/dea_next/staging/d20150602-22454-449ozp/plugin_config | tee -a /tmp/staged/logs/staging_task.log","discard_output":true},"response":{"job_id":2221}},"thread_id":70313730315000,"fiber_id":70313770441960,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":300,"method":"dispatch"} /var/vcap/sys/log/warden/warden.log.1:531800:{"timestamp":1433214018.2599485,"message":"Exited with status 1 (4.713s): [["/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/src/closefds/closefds", "/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/src/closefds/closefds"], "/var/vcap/data/warden/depot/18ndqsq7ilr/bin/iomux-link", "-w", "/var/vcap/data/warden/depot/18ndqsq7ilr/jobs/2221/cursors", "/var/vcap/data/warden/depot/18ndqsq7ilr/jobs/2221"]","log_level":"warn","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","stdout":"","stderr":""},"thread_id":70313730315000,"fiber_id":70313743220340,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/spawn.rb","lineno":135,"method":"set_deferred_success"} /var/vcap/sys/log/warden/warden.log.1:531801:{"timestamp":1433214018.260702,"message":"Wrote snapshot in 0.000468","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr"},"thread_id":70313730315000,"fiber_id":70313743220340,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":334,"method":"write_snapshot"} /var/vcap/sys/log/warden/warden.log.1:531802:{"timestamp":1433214018.3262737,"message":"info (took 0.064934)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","request":{"handle":"18ndqsq7ilr"},"response":{"state":"active","events":[],"host_ip":"10.254.1.89","container_ip":"10.254.1.90","container_path":"/var/vcap/data/warden/depot/18ndqsq7ilr","memory_stat":"#","cpu_stat":"#","disk_stat":"#","bandwidth_stat":"#","job_ids":[]}},"thread_id":70313730315000,"fiber_id":70313732324000,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":300,"method":"dispatch"} /var/vcap/sys/log/warden/warden.log.1:531803:{"timestamp":1433214018.3266022,"message":"link (took 4.755165)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","request":{"handle":"18ndqsq7ilr","job_id":2221},"response":{"exit_status":1,"stdout":"","stderr":"","info":"#"}},"thread_id":70313730315000,"fiber_id":70313732324000,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":300,"method":"dispatch"} Hope my log can give you some clue on why my app fail at buildpack step. |
I don't see much in those logs other than info that the app had an exit status of 1. Is there nothing in the logs for the app itself? |
no, I didn't take the app log for the moment of failure. But the app is a testing case which runs every certain time of period in my env. And for over 80% (the number maybe not very exact) , the push app sucess, but others will fail. I will check the app logs next time when I meet the failure. |
Hi dagong123, we are not aware of a known issue which would result in a exit 1. The best thing you can do is look at your applications logs. @Quintaminant & @MarcSchunk of runtime team |
Hi @dagong123, We are going to close this issue due to inactivity. If you have any additional information please feel free to reopen the issue. Thanks, |
Hi, when I pushed a app in CF, it failed with bellow log info:
/var/vcap/sys/log/warden/warden.log
{"timestamp":1433214013.4825037,"message":"info (took 0.057741)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","request":{"handle":"18ndqsq7ilr"},"response":{"state":"active","events":[],"host_ip":"10.254.1.89","container_ip":"10.254.1.90","container_path":"/var/vcap/data/warden/depot/18ndqsq7ilr","memory_stat":"#","cpu_stat":"#","disk_stat":"#","bandwidth_stat":"#","job_ids":[]}},"thread_id":70313730315000,"fiber_id":70313783729620,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/base.rb","lineno":300,"method":"dispatch"}
.... ...
{"timestamp":1433214018.2599485,"message":"Exited with status 1 (4.713s): [["/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/src/closefds/closefds", "/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/src/closefds/closefds"], "/var/vcap/data/warden/depot/18ndqsq7ilr/bin/iomux-link", "-w", "/var/vcap/data/warden/depot/18ndqsq7ilr/jobs/2221/cursors", "/var/vcap/data/warden/depot/18ndqsq7ilr/jobs/2221"]","log_level":"warn","source":"Warden::Container::Linux","data":{"handle":"18ndqsq7ilr","stdout":"","stderr":""},"thread_id":70313730315000,"fiber_id":70313743220340,"process_id":19819,"file":"/var/vcap/data/packages/warden/e4c65ef1dc975c3a06df74c0182ce9b31a20eded.1-57517380391b74c50acd1bb0f7f6a12919d563f4/warden/lib/warden/container/spawn.rb","lineno":135,"method":"set_deferred_success"}
I am wondering why the "info" request get the respond with informatin like "memory_stat":"#","cpu_stat":"#","disk_stat":"#","bandwidth_stat":"#" ? What might be the root cause for such case?
Could anyone help on this?
PS: I met such failures for serveral times during my APP push.
The text was updated successfully, but these errors were encountered: