Bug 804705 - Native (sigar) Platform plugin states "Win32" even on 64 bit systems
Summary: Native (sigar) Platform plugin states "Win32" even on 64 bit systems
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 4.3
Hardware: x86_64
OS: Windows
medium
low
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On: 804701
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-19 15:55 UTC by Tom Fonteyne
Modified: 2015-02-01 23:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 804701
Environment:
Last Closed: 2013-09-04 07:48:29 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 653496 0 low CLOSED Platform plugin shows OS Name for 64bit Windows servers as Win32 2021-02-22 00:41:40 UTC

Internal Links: 653496

Description Tom Fonteyne 2012-03-19 15:55:43 UTC
+++ This bug was initially created as a clone of Bug #804701 +++

Description of problem:

64 bit Windows systems will be reported as being "Win32"

This is because 
   org/​ rhq/​ core/​ system/​ NativeSystemInfo.java 
report the string "as-is" from the native Sigar library

Version-Release number of selected component (if applicable):


How reproducible: always


Steps to Reproduce:
1. Start an agent in 64 bit JDK on a 64 bit Windows and let it discover the platform.
2. Import it in the JON server, and look at the details of the OS.
3.
  
Actual results:

Win32

Expected results:

Windows Server 2008 R2   (or similar for other Windows versions of course)

Additional info:

This is easy to fix by always reading the OS version from Java and NOT from Sigar.

org/​ rhq/​ core/​ system/​ NativeSystemInfo.java:

106     public String getOperatingSystemName() {
107         return OperatingSystem.getInstance().getName();
108     }

should be changed to (line numbers from JavaSystemInfo.java):

098     public String getOperatingSystemName() {
099         return System.getProperty("os.name");
100     }

It is debatable, but advisable to do the same for other calls in this class where Java is delivering a "good" result. Examples would be:
 getOperatingSystemVersion()
 getNumberOfCpus()

and likely more.

Comment 1 Mike Foley 2012-03-26 15:57:37 UTC
medium, no target release 

per bz triage (crouch, mfoley, asantos, loleary)

Comment 2 Charles Crouch 2012-03-26 16:02:36 UTC
This should be raised as a Sigar JIRA

Comment 3 Tom Fonteyne 2012-03-26 16:09:13 UTC
fixing it in RHQ by simply avoiding to use the Sigar getOperatingSystemName is likely going to be much faster methinks

Comment 4 Charles Crouch 2012-03-26 22:39:21 UTC
TomF
Its almost always a good idea to see if fixes can be applied upstream.


Ian
Can you quickly create a JIRA at https://jira.hyperic.com/browse/SIGAR 

Title: OperatingSystem getName() returns "Win32" on a 64 bit Windows machine
Priority: High
Description:
Sigar version 1.6.5
-Run the java bindings for sigar on a 64 bit JDK on a 64 bit Windows machine.
-Check that OperatingSystem.getInstance().getName() returns Win32.

Comment 5 Ian Springer 2012-03-27 03:48:18 UTC
We already have a workaround for the SIGAR issue in the WindowsPlatformComponent class in the platform plugin (see bug #653496):

    @Override
    protected MeasurementDataTrait getMeasurementDataTrait(MeasurementScheduleRequest request) {
        MeasurementDataTrait trait = super.getMeasurementDataTrait(request);
        // SIGAR returns "Win32" as the OS name for all Windows systems, even 64-bit ones, so add some special code
        // to instead return "Win64" for 64-bit systems.
        if (trait.getName().equals(TRAIT_OSNAME) && trait.getValue().equals(OS_NAME_WIN32)) {
            if ("x64".equals(getSysinfo().getSystemArchitecture())) {
                trait.setValue(OS_NAME_WIN64);
            }
        }
        return trait;
    }

Tom, is there another place you're seeing the bogus "Win32" value seep through?

Charles, I'll file a SIGAR bug tomorrow.

Comment 6 Tom Fonteyne 2012-03-27 07:56:30 UTC
@Ian:  indeed, I found that workaround as well, due to me searching for "Win32"

The other place is as reported in this bug in

org/​ rhq/​ core/​ system/​ NativeSystemInfo.java

Comment 7 Ian Springer 2012-03-27 20:30:43 UTC
I filed a SIGAR bug:

https://jira.hyperic.com/browse/SIGAR-238

Comment 8 Ian Springer 2012-03-27 21:10:55 UTC
NativeSystemInfo.getOperatingSystemName() now returns "Windows", rather than "Win32", for Windows systems, since "Win32" does not seem like an appropriate value in the case of 64-bit Windows systems:

master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=891804d

Comment 10 Heiko W. Rupp 2013-09-04 07:48:29 UTC
Bulk closing of some old issues


Note You need to log in before you can comment on or make changes to this bug.