Improving the Identication of Linux Distributions when Dumping

[Paul Hohensee]

First, some Oracle bug process suggestions. :)

You should add the content of the 100137 to 6986195 so the latter isn't
dependent on the former staying around.  Add the Description from 100137 to
the Description of 6986195 and add the patch as either text in 'Suggested
Fix' or as an attachment to 6986195.  Then, add your email to the 
'Evaluation'
field of 6986195 so it gets archived.  I'll add this one (mine) after that.

I rummaged around and found that /etc/lsb_release seems to be part of 
core Linux, vis

http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

So it seems that unlike the suggested patch, you might dump 
/etc/lsb_release first
rather than in the middle of the list of files.  And I'd change 
_print_debian_lsb_file
to _print_lsb_file.

The rest of your proposed change sounds good to me, except that maybe we 
can have
the best of both worlds and have the jvm dump its best guess, plus the 
content of the
/etc files as you propose.  Doing so might make it easier for existing 
hs_err file parsers
to work.

Are there any hs_err file parsers you or anyone else knows about that 
might be affected?
I'm not too concerned about such parsers in general though, because it's 
expected that
the hs_err file format will change every now and then.

Paul


On 4/3/11 9:51 PM, Robert Ottenhag wrote:
>
> I am about to improve the identification of popular Linux distros 
> during dumping, see bug [1] and [2], that states that we should 
> "correctly identify Ubuntu as the operating system in crash report 
> instead of 'Debian'".
>
> I am somewhat reluctant to directly apply the suggested patch though 
> which only adds to the existing problematic implementation where some 
> distros not are identified at all, or are identified as a different 
> distro.
>
> The current implementation [4] relies on the fact that most Linux 
> distros have /etc/XXX-release files, where some distros have multiple 
> files (see [3]). It then checks a fixed set of these files in order, 
> and stops at the first matching file, so the order is important.
>
> (0) the current order is "/etc/mandrake-release", "/etc/sun-release", 
> "/etc/redhat-release", "/etc/SuSE-release", "/etc/turbolinux-release", 
> "/etc/gentoo-release", "/etc/debian_version", "/etc/ltib-release", 
> "/etc/angstrom-version", and the proposed patch is to insert 
> "/etc/lsb-release" right before "/etc/debian_version".
>
> If we instead of (0) replace it by (1) and (2) below it will be 
> improved in many ways.
>
> (1) call the "lsb_release" tool, if it exists, which returns distro 
> specific info based on either /etc/lsb_release or /etc/XXX-release, 
> and that also knows which of multiple /etc/XXX-release files to check 
> first, e.g. /etc/enterprise-linux before /etc/redhat-linux.
>
> (2) list all /etc/*-release and /etc/*_version files, headed by the 
> respective file names
>
> The problem with (1) is that it calls an external process during a 
> phase with might be very critical on resources, and it might not be 
> available on specific old or embedded distros.  Thus we still need (2) 
> for which we need to verify that directory listing does not violate 
> similar resource contraints.  Regarding (2) the order of listed files 
> should also be considered if it simplifies parsing of the dump output.
>
> The new solution would look something like
>
>   OS:
>
>     /etc/debian_version
>
> <content>
>
>     /etc/lsb-release
>
> <content>
>
> Fundamentally, instead of having the JVM to try identify the Linux 
> distro, it becomes up to the reader/parser of the dump output, but 
> with the benefit of having all data available.
>
> References:
>
> [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100137
>
> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195
>
> [3] http://linuxmafia.com/faq/Admin/release-files.html
>
> [4] hotspot/src/os/linux/vm/os_linux.cpp:os::print_os_info().
>
> I appreciate any comments and ideas.
>
> Thanks
>
> /Robert
>
> -- 
> Oracle <http://www.oracle.com>
> Robert Ottenhag | Senior Member of Technical Staff
> Phone: +46850630961 <tel:+46850630961> | | Fax: +46850630911 
> <fax:+46850630911> | | Mobile: +46707106161 <tel:+46707106161>
> OracleOracle Java VM
> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm
>
> Oracle Svenska AB, Kronborgsgränd 17, S-164 28 KISTA, reg.no. 556254-6746
>
> Green Oracle <http://www.oracle.com/commitment>
>
> 	
>
> Oracle is committed to developing practices and products that help 
> protect the environment
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110405/3a31bd8f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110405/3a31bd8f/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 356 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110405/3a31bd8f/attachment-0003.gif