Thanks both,
Using yet another GFSH command (*export stack-traces*) when the system is
already a distributed deadlock doesn't seem right :-). On the other hand,
*jstack* and *jcmd* both work as expected, but my goal was to make *KILL
-QUIT / KILL -3* work, it's easier and widely known. I'll keep working on
it.
Best regards.
On Wed, Dec 20, 2017 at 3:38 PM, Kirk Lund wrote:
> Sorry, my info on redirecting of stdout and stderr was stale (circa GemFire
> 7.0). Now that the code base is an Apache project, I believe redirecting of
> stdout and stderr no longer occurs. However, it does shut off the Log4j2
> ConsoleAppender to stdout when the LogWriterAppender is activated and turns
> it back on when the LogWriterAppender is closed. The old code base
> redirected stdout and stderr using native code which is not in Apache
> Geode.
>
> If you want to dump stack traces, you need to use the GFSH command "export
> stack-traces".
>
> On Wed, Dec 20, 2017 at 1:33 AM, Juan José Ramos
> wrote:
>
> > Hello Kirk,
> >
> > Thanks for your reply. Please find my answers below, in line for an
> easier
> > follow-up.
> >
> > *>> By default Geode redirects stdout and stderr to the value of the
> > log-file property when the Cache starts. If log-file is set to "" then it
> > won't redirect them.*
> >
> > This doesn't seem to be true at the moment, I've tested the behavior
> > before sending the email and creating the JIRA. If you start a basic
> server
> > with the defaults + *log-file*, the output written from a
> > function/listener to stdout/stderr is lost, nothing is printed on the
> > member's logs.
> >
> >
> > *>> So we reluctantly made the code redirect stdout and stderr when
> > LogWriterAppender is registered (at the same point in Cache startup where
> > the behavior originally existed). If you specify a custom log4j2.xml then
> > this behavior does NOT happen.*
> >
> > Also tested this one and it doesn't seem to be true, the result is the
> same
> > as before: the output written to *stderr/stdout* is lost, nothing is
> > printed on the member's logs.
> >
> >
> > *>> So a user currently has two options:*
> > *>> 1) keep the old behavior,*
> > *>> 2) use a custom log4j2.xml which can be specified using the Log4J 2
> > system property "log4j.configurationFile".*
> >
> > The attached zip file contains a reproducible scenario (you just need to
> > modify *setenv.txt* and execute *reproduce.sh*) showing that both
> > approaches fail, the output from *System.out.println()* and
> > *System.err.println()* is lost, along with the thread dump generated by
> *kill
> > -3 PID*.
> > Hope this is clear now, hope you can answer the questions from my
> previous
> > email so I can proceed with the fix.
> > Best regards
> >
> >
> > On Tue, Dec 19, 2017 at 2:56 PM, Kirk Lund wrote:
> >
> >> By default Geode redirects stdout and stderr to the value of the
> log-file
> >> property when the Cache starts. If log-file is set to "" then it won't
> >> redirect them.
> >>
> >> When we changed GemFire to use Log4J2 internally, we tried to leave
> stdout
> >> and stderr alone such that the LogWriterAppender would append log
> >> statements to the log-file and it would leave the stdout appender
> >> registered and appending to stdout. This was a change in behavior from
> the
> >> previous version of GemFire, and the management at that time decided
> that
> >> it needed to maintain the old behavior, so we reluctantly made the code
> >> redirect stdout and stderr when LogWriterAppender is registered (at the
> >> same point in Cache startup where the behavior originally existed).
> >>
> >> If you specify a custom log4j2.xml then this behavior does NOT happen.
> So
> >> a
> >> User currently has two options: 1) keep the old behavior, 2) use a
> custom
> >> log4j2.xml which can be specified using the Log4J 2 system property
> >> "log4j.configurationFile".
> >>
> >> If you copy geode-core/src/main/resources/log4j2.xml for use as the
> >> starting basis for your log4j2.xml then you must NOT keep this line (or
> >> set
> >> it to false):
> >>
> >> true
> >>
> >> That is the line that Geode uses to determine that it is using its own
> >> default log4j2.xml and this enables redirecting of stdout and stderr
> when
> >> the LogWriterAppender starts up.
> >>
> >> On Tue, Dec 19, 2017 at 7:11 AM, Ju@N wrote:
> >>
> >> > Hello Geode devs,
> >> >
> >> > Currently GEODE is "swallowing" all output sent to stdout and stderr
> by
> >> > default and there's no way of changing this behavior when starting
> >> members
> >> > through *gfsh*.
> >> > This, between other things, prevents users, between other things, from
> >> > playing around with *System.out.println()* during development phases
> and
> >> > getting thread dumps by executing a plain *kill -3* or *kill -QUIT*
> >> using
> >> > the processId, which is critical in troubleshooting.
> >> > Currently there are two internal flags that can be used to prevent
> this
> >> > default behavior, both have to be used a
