Would anyone be opposed to a new option to redirect hs-err files to stderr/out?

[Thomas Stüfe]

Hi David,

I updated the CSR. Further comments inline:

On Mon, Mar 18, 2019 at 10:57 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> I commented on the CSR before I saw this email thread. I really hoped we
> could enhance ErrorFile rather than adding yet-another-flag.
>
> Do we seriously think anyone would realistically use stderr and stdout
> as the names of custom error files? I'd be okay addressing that with a
> release note (though if you wanted to backport this it is more of an
> issue).
>
> That said, given we already have DisplayVMOutputToStderr/Stdout then
> something like -XX:+ErrorFileToStderr/Stdout may be the better choice.
>
>
Okay. I can live with that but lets see what others think. The exact
wordings of the flags does not matter much to me as long as its clear what
they do.


> That aside I see this as a flaw with the environments you're running in.
> If an application can produce files then the container environment
> should provide a way to handle that properly. Writing to stdout/stderr
> is really just a hack - and you may get a real mess of interleaved
> output. :(
>

I agree but it would be a pragmatic solution to a lot of annoying problems.
E.g. I might use this for my builds, to get the output right away when the
build vm crashes.

..Thomas


> Cheers,
> David
>
> On 19/03/2019 2:16 am, Thomas Stüfe wrote:
> > On Mon, Mar 18, 2019 at 4:38 PM Remi Forax <forax at univ-mlv.fr> wrote:
> >
> >> Hi Thomas,
> >>
> >> ----- Mail original -----
> >>> De: "Thomas Stüfe" <thomas.stuefe at gmail.com>
> >>> À: "Aleksey Shipilev" <shade at redhat.com>
> >>> Cc: "hotspot-runtime-dev" <hotspot-runtime-dev at openjdk.java.net>
> >>> Envoyé: Lundi 18 Mars 2019 15:39:00
> >>> Objet: Re: Would anyone be opposed to a new option to redirect hs-err
> >> files to stderr/out?
> >>
> >>> On Mon, Mar 18, 2019 at 2:50 PM Aleksey Shipilev <shade at redhat.com>
> >> wrote:
> >>>
> >>>> On 3/18/19 2:43 PM, Thomas Stüfe wrote:
> >>>>> We have the -XX:ErrorFile option to overwrite the default path and
> >> file
> >>>>> name for the hs-err file. I would like to add the option of
> >> specifiying a
> >>>>> special value which would mean "stdout" or "stderr", respectivly.
> >>>>>
> >>>>> E.g. -XX:ErrorFile=STDERR or -XX:ErrorFile=STDOUT .
> >>>>>
> >>>>> Any objections? If not, I would draft a CSR and implement this.
> >>>>
> >>>> That would be very welcome.
> >>
> >> yes, i've the same issue when using TravisCI
> >>
> >>>>
> >>>> It would be the bikeshedding exercise to come up with the special name
> >>>> that would not clash with
> >>>> potential real user-specified path.
> >>>
> >>>
> >>> :( I was hoping... no, you are right.
> >>>
> >>>
> >>>> On Linux, I'd expect -XX:ErrorFile=/dev/stdout to work -- maybe
> >>>> start from making sure that works reliably?
> >>
> >> -XX:ErrorFileRedirect=stderr is better IMO
> >>
> >>
> > Thanks. I like this better.
> >
> > I opened a CSR for this.
> https://bugs.openjdk.java.net/browse/JDK-8220787
> >
> > Lets see how this is received.
> >
> > ..Thomas
> >
> >
> >>>>
> >>>>
> >>> It fails now with EEXISTS, since we open the file as new. Changing that
> >> to
> >>> accept O_APPEND opens a different can of worms: do you want people to
> >>> append post-mortems to existing files?
> >>>
> >>> Also, /dev/stdout is not supported on all platforms, eg not on Windows
> >> and
> >>> our beloved AIX.
> >>>
> >>> A pragmatic approach but not as elegant as reusing -XX:ErrorFile would
> >>> adding a new option, or options,
> -XX:RedirectHsErrFileTo(Stdout|Stderr).
> >>>
> >>> In that case we would have to think about what to do if both are
> >> specified.
> >>>
> >>> ..Thomas
> >>>
> >>>
> >>>
> >>>> -Aleksey
> >>>>
> >>
>