how to get crashlogs from cf

[neeraj....@gmail.com]

A startup of an application failed ... The command "cf crashlogs <appname>" shows that there are logs .... But I'm not able to find the logs. Where can I see detailed logs?

[Daniel Mikusa]

On Tue, Jun 10, 2014 at 1:26 PM, <neeraj....@gmail.com> wrote:

A startup of an application failed ... The command "cf crashlogs <appname>" shows that there are logs .... But I'm not able to find the logs. Where can I see detailed logs?

What version of cf are you using?  cf -v

The crashlogs feature is pretty old.  You might try upgrading to the latest version of cf (6.1.2 at the moment) and use the "cf logs --recent <app>" command.

  https://github.com/cloudfoundry/cli/releases

This assume that your application is writing logs to stderr / stdout.  If it's writing to disk, you should change it to log to stdout / stderr.

  http://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html#writing

Dan

[alan moran]

Hi,

Dan is right,

Still the cf logs —recent will give you the crash log of the app failing to start only if the app instance started at least one and the container exist.

In Case you don’t have that first instance running your only solution will be to retrieve this crash logs by ssh into the DEA where that container tried to start and check the data of that container, I did found some logs there with useful information. 

Cheers,

- - - 

Alan Moran 

Altoros — Cloud Foundry deployment, training and integration

http://bonzofenix.com/ 

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CADf97R0T%3D17eR%2BkYyb_CY9kN4ZBu%3Dx6eZU_fv06XsET_rpPu1A%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Daniel Mikusa]

On Tue, Jun 10, 2014 at 8:12 PM, alan moran <alan....@altoros.com> wrote:

Hi,

Dan is right,

Still the cf logs —recent will give you the crash log of the app failing to start only if the app instance started at least one and the container exist.

Sorry I'm not sure I follow you here.  Can you explain this further?  I was curious about this and decided to try and replicate it, but I'm not having any luck.  Here's what I tried.

1.) Create a dummy node app.  It's broken (literally just an empty app.js file) and does nothing.

2.) Push for the first time with "cf push -i 1 -m 64M -c "node app.js" some-node-test"

3.) After some time, the push fails.

4.) Run "cf logs some-node-test --recent".  Display the recent logs.

Do you have steps to replicate this?

Dan

PS. Ran my tests on PWS, which I think is on cf 172 right now.

 

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DF554A74-0F58-4937-A37B-113409DB4EAB%40altoros.com.

[Scott Frederick]

It sometimes works better to stream logs using "cf logs <app-name>" (without the --recent option) while the app is being staged and started to make sure you aren't missing any log output. If the app already exists (i.e. you have pushed it once and are re-pushing it), you can run "cf logs <app-name>" in one window and then start the push in another. For a first-time push, run the "cf push" command and wait until the CLI says "Creating app <app-name> ..." followed by "OK", then start the "cf logs <app-name>" in another window.

Scott

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DF554A74-0F58-4937-A37B-113409DB4EAB%40altoros.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

[Alan Morán]

Hi Everyone,

Nobody have found a better way to do this? it is annoying for me to ssh the DEA to get those crashlogs. When the app never succeed to start its impossible to see those logs. Is there a story on the runtime team to address this issue?

Thanks, 

- - - -

Alan Moran

 
Altoros — Cloud Foundry deployment, training and integration

http://bonzofenix.com/ 

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/d4b6ab3d-9345-490c-a7f3-cc0cbcbb5f93%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Daniel Mikusa]

On Wed, Jun 25, 2014 at 11:50 AM, Alan Morán <alan....@altoros.com> wrote:

Hi Everyone,

Nobody have found a better way to do this? it is annoying for me to ssh the DEA to get those crashlogs. When the app never succeed to start its impossible to see those logs. Is there a story on the runtime team to address this issue?

I do quite a bit of app troubleshooting with various Pivotal customers and I can't recall the last time I had to do this.  The output of "cf logs" has been reliable for me.  Perhaps you can explain this a little more.

Some questions...

1.) What version of CF runtime & CF client are your running when you need to do this?

2.) How could I replicate this issue?  Do you have a test app or will any broken app work?  What is the exact set of cf commands that I should execute?

3.) What is not showing up in the output of "cf logs" versus what you get when you ssh to the DEA?  For example, do you see any of the logs, are they truncated or just missing some statements?

4.) What steps are you using to get the logs when you're ssh'd to the dea?

Dan

 

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/DC77DF4F-B06C-4CB1-8FD4-3676F2E7B0CD%40altoros.com.

[Alan Morán]

Hi Dan,

Thanks for the help, and sorry for the delay in my answer.

Let me explain you what is happening so you can you maybe try to reproduce it:

1.) What version of CF runtime & CF client are your running when you need to do this?

CF: cf-173 on openstack

CLI: 6.1.2-6a013ca

2.) How could I replicate this issue?  Do you have a test app or will any broken app work?  What is the exact set of cf commands that I should execute?

you can reproduce it like this:

$ git clone https://github.com/bonzofenix/vanilla-node

$ cd vanilla-node

$ cf push crash-app -c ‘BUM’

And getting logs via:

$ cf logs crash-app

3.) What is not showing up in the output of "cf logs" versus what you get when you ssh to the DEA?  For example, do you see any of the logs, are they truncated or just missing some statements?

I see the following with *cf logs APP*:

5.0, negot...@0.3.0, multi...@2.2.0)

2014-07-02T01:24:20.35+0000 [STG]     OUT -----> Caching node_modules directory for future builds

2014-07-02T01:24:20.42+0000 [STG]     OUT -----> Cleaning up node-gyp and npm artifacts

2014-07-02T01:24:20.43+0000 [STG]     OUT -----> No Procfile found; Adding npm start to new Procfile

2014-07-02T01:24:20.43+0000 [STG]     OUT -----> Building runtime environment

2014-07-02T01:24:20.44+0000 [STG]     ERR

2014-07-02T01:24:22.64+0000 [STG]     OUT -----> Uploading droplet (8.8M)

2014-07-02T01:24:28.94+0000 [DEA]     OUT Starting app instance (index 0) with guid e1d04000-9e70-4a9c-a58f-492887543894

2014-07-02T01:24:30.75+0000 [DEA]     OUT Instance (index 0) failed to start accepting connections

2014-07-02T01:24:30.76+0000 [API]     OUT App instance exited with guid e1d04000-9e70-4a9c-a58f-492887543894 payload: {"cc_partition"=>"default", "droplet"=>"e1d04000-9e70-4a9c-a58f-492887543894", "version"=>"4c01dc53-8ad0-48de-9153-14c635e6f335", "instance"=>"3911c8d8da42477ea1db4519ae31281a", "index"=>0, "reason"=>"CRASHED", "exit_status"=>127, "exit_description"=>"app instance exited", "crash_timestamp"=>1404264270}

Instead of something like this as part of the logs:

The program ‘BUM' is currently not installed. 

4.) What steps are you using to get the logs when you're ssh'd to the dea?

On the DEA I looks for logs in the following folder:

/var/vcap/data/dea_next/crashes/

I seen more post in the list around this [1] so I am guessing I am not the only one.

[1] - https://groups.google.com/a/cloudfoundry.org/forum/#!searchin/vcap-dev/Future$20of$20crashlogs%7Csort:relevance%7Cspell:false/vcap-dev/J7oa89yOViw/1bb518hnp0AJ

- - - -

Alan Moran

 
Altoros — Cloud Foundry deployment, training and integration

http://bonzofenix.com/ 

El 27/06/2014, a las 06:54 a.m., Daniel Mikusa <dmi...@gopivotal.com> escribió:

On Wed, Jun 25, 2014 at 11:50 AM, Alan Morán <alan....@altoros.com> wrote:

Hi Everyone,

Nobody have found a better way to do this? it is annoying for me to ssh the DEA to get those crashlogs. When the app never succeed to start its impossible to see those logs. Is there a story on the runtime team to address this issue?

I do quite a bit of app troubleshooting with various Pivotal customers and I can't recall the last time I had to do this.  The output of "cf logs" has been reliable for me.  Perhaps you can explain this a little more.

Some questions...

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CADf97R36YtsggPSyc9EWwm0%3DTxyrLs2fTyRKNX6T%3Dh_8KTz-uQ%40mail.gmail.com.

[Mike Youngstrom]

Hi Alan,

The response to my other crashlogs post [1] sounds like this is a known issue.  There is a slight delay in loggregator attaching to a DEA instance so it doesn't appear to get instant errors like Command not found.  In my experience Loggregator gets everything except for these very early errors.  Hopefully this is fixed in Diego.

Mike

[1] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/2acNlom2MHc/y6tHtwxvs8AJ

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/871DE91A-8763-438E-97E3-B4A191CE2123%40altoros.com.

[Daniel Mikusa]

On Tue, Jul 1, 2014 at 9:42 PM, Alan Morán <alan....@altoros.com> wrote:

Hi Dan,

Thanks for the help, and sorry for the delay in my answer.

Let me explain you what is happening so you can you maybe try to reproduce it:

1.) What version of CF runtime & CF client are your running when you need to do this?

CF: cf-173 on openstack

CLI: 6.1.2-6a013ca

2.) How could I replicate this issue?  Do you have a test app or will any broken app work?  What is the exact set of cf commands that I should execute?

you can reproduce it like this:

$ git clone https://github.com/bonzofenix/vanilla-node

$ cd vanilla-node

$ cf push crash-app -c ‘BUM’

I don't use the "-c" option very often, which probably explains why I haven't encountered this.  I'll play around with it and see what I can figure out.

Some suggestions off the top of my head.  Not sure if these will help or not.

 1.) Use "sleep 1 && <cmd>".  Perhaps this will give loggregator more time to connect.

 2.) Have you tried a Procfile?  Is that any better?

 3.) What about "scripts.start"?  Is that the same?

 

Dan

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/871DE91A-8763-438E-97E3-B4A191CE2123%40altoros.com.

[Mike Youngstrom]

Thanks for the response Dan!  See comments inline:

 

Some suggestions off the top of my head.  Not sure if these will help or not.

 1.) Use "sleep 1 && <cmd>".  Perhaps this will give loggregator more time to connect.

I was thinking the same thing.  Though it assumes you're already aware of the loggregator connect time problem.  This is a bigger problem for beginners.  Who's apps fails to start and loggregator logs aren't helping them.

Would it be possible for the DEA to inject a sleep into app startup?  Giving Loggregator time to connect?

 

 2.) Have you tried a Procfile?  Is that any better?

 3.) What about "scripts.start"?  Is that the same?

I'm not sure what you mean by these options?  I know an invalid "start_command" from the buildpack has the same problem.  Is there a particular hope that these other start options might yield a different result?  Regardless I think the core problem is a beginner's experience not the actual logistics once you're aware of the problem.

 

Thanks,

Mike

[Daniel Mikusa]

On Wed, Jul 2, 2014 at 7:16 PM, Mike Youngstrom <you...@gmail.com> wrote:

Thanks for the response Dan!  See comments inline:

 

Some suggestions off the top of my head.  Not sure if these will help or not.

 1.) Use "sleep 1 && <cmd>".  Perhaps this will give loggregator more time to connect.

I was thinking the same thing.  

I tested this with Alan's Node.js app and bosh-lite.  Adding the sleep worked for me.

Ex:

  cf push -c 'sleep 1 && BUM' node-1

It results in the following output from "cf logs".

2014-07-03T12:04:37.17-0400 [App/0]   ERR /bin/bash: line 25: BUM: command not found

Seems like an easy enough workaround.  At least until Diego and a proper fix.

 

Though it assumes you're already aware of the loggregator connect time problem.  This is a bigger problem for beginners.  Who's apps fails to start and loggregator logs aren't helping them. 

 

Would it be possible for the DEA to inject a sleep into app startup?  Giving Loggregator time to connect?

 

 2.) Have you tried a Procfile?  Is that any better?

 3.) What about "scripts.start"?  Is that the same?

I'm not sure what you mean by these options?  I know an invalid "start_command" from the buildpack has the same problem.  Is there a particular hope that these other start options might yield a different result?  Regardless I think the core problem is a beginner's experience not the actual logistics once you're aware of the problem.

I was just thinking that specifying the command in a different manner might have an affect on the timing.  It was just a guess and from a few tests, it doesn't seem to help.

Dan

 

[Alan Morán]

Great so thats a possible workaround that we can use :).

Thanks for the insight, I did not know about this run that happened between loggregator and DEAs when staging an app.

Hopefully with diego we can forget about this!

- - - -

Alan Moran

 
Altoros — Cloud Foundry deployment, training and integration

http://bonzofenix.com/ 

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CADf97R15K%2BkdNejLwQeZNq3GninopG6X7AEvxw8qtQEWe0YYbA%40mail.gmail.com.