Bug #2865

facter 1.5.7 changed the report of the virtual fact

Added by Jean Spirat over 2 years ago. Updated about 1 year ago.

Status:Closed Start date:11/26/2009
Priority:High Due date:
Assignee:Rein Henrichs % Done:

0%

Category:library
Target version:1.5.9
Keywords: Affected Facter version:
Branch:ticket/master/2865-virtual-fact-reporting
Votes: 1

Description

Hi,

If i use facter 1.5.6 i got:

facterversion => 1.5.6 virtual => vserver_host

after the upgrade:

facterversion => 1.5.7 virtual => physical

this is major bug to me :( it broke all my virtualisation scripts..

regards, Jean


Related issues

related to Facter - Feature #2755: virtual.rb should detect KVM guests. Closed 10/26/2009
related to Facter - Bug #2747: the virtual fact and xen Closed 10/22/2009

History

Updated by Jean Spirat over 2 years ago

it seems there was a change in util/virtual.rb:

return true if txt =~ /(s_context|VxID)::blank:*[1-9]/

should be

return true if txt =~ /(s_context|VxID)::blank:*[0-9]/

i am using vserver v 2.3

regards, Jean.

Updated by Jean Spirat over 2 years ago

the logic changed:

in 1.5.6 it search /proc/virtual to see if this is a host, if it find a “/proc/self/status” with starting vxid 1-9 then this is a guest.

in 1.5.7 it search a vxid in /proc/self/status and if it find one it search for /proc/virtual BUT the issue is that host have xid of 0 on vserver 2.3 and with vserver 2.1 you do NOT have vixd in proc/self status on the host at all…so the logic fails completly.

Updated by James Turnbull over 2 years ago

  • Category set to library
  • Status changed from Unreviewed to Accepted
  • Target version changed from 1.5.7 to 1.6.0

Updated by Paul Nasrat over 2 years ago

  • Assignee set to Paul Nasrat
  • Target version changed from 1.6.0 to 1.5.8

Updated by Paul Nasrat over 2 years ago

  • Status changed from Accepted to Needs More Information

Can you provide the output of /proc/self/status on both vserver 2.1 and 2.3 as attachments to this bug please.

Updated by Jean Spirat over 2 years ago

here is for 2.3 :

FROM HOST: Name: cat State: R (running) Tgid: 21074 Pid: 21074 PPid: 21020 TracerPid: 0 Uid: 47000 47000 47000 47000 Gid: 4733 4733 4733 4733 FDSize: 64 Groups: 0 4733 VmPeak: 3800 kB VmSize: 3800 kB VmLck: 0 kB VmHWM: 468 kB VmRSS: 468 kB VmData: 176 kB VmStk: 84 kB VmExe: 32 kB VmLib: 1432 kB VmPTE: 28 kB Threads: 1 SigQ: 0/71680 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: fffffffffffffeff Cpus_allowed: ff Cpus_allowed_list: 0-7 Mems_allowed: 1 Mems_allowed_list: 0 VxID: 0 NxID: 0 voluntary_ctxt_switches: 2 nonvoluntary_ctxt_switches: 0

FROM GUEST: Name: cat State: R (running) Tgid: 21149 Pid: 21149 PPid: 21142 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: 0 VmPeak: 1564 kB VmSize: 1564 kB VmLck: 0 kB VmHWM: 384 kB VmRSS: 384 kB VmData: 160 kB VmStk: 84 kB VmExe: 16 kB VmLib: 1284 kB VmPTE: 20 kB Threads: 1 SigQ: 0/71680 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: fffffffffffffeff CapEff: fffffffffffffeff CapBnd: fffffffffffffeff Cpus_allowed: ff Cpus_allowed_list: 0-7 Mems_allowed: 1 Mems_allowed_list: 0 VxID: 40128 NxID: 40128 voluntary_ctxt_switches: 1 nonvoluntary_ctxt_switches: 0

Updated by Jean Spirat over 2 years ago

from 2.1 now:

FROM HOST: Name: cat State: R (running) SleepAVG: 88% Tgid: 24625 Pid: 24625 PPid: 24618 TracerPid: 0 Uid: 47000 47000 47000 47000 Gid: 4733 4733 4733 4733 FDSize: 32 Groups: 0 4733 VmPeak: 1768 kB VmSize: 1768 kB VmLck: 0 kB VmHWM: 396 kB VmRSS: 396 kB VmData: 160 kB VmStk: 88 kB VmExe: 28 kB VmLib: 1468 kB VmPTE: 12 kB Threads: 1 SigQ: 0/4294967295 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 s_context: 0 ctxflags: none initpid: none ipv4root: 0 ipv4root_bcast: 0

FROM GUEST: Name: cat State: R (running) SleepAVG: 58% Tgid: 24671 Pid: 24671 PPid: 24670 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 VmPeak: 1580 kB VmSize: 1580 kB VmLck: 0 kB VmHWM: 372 kB VmRSS: 372 kB VmData: 152 kB VmStk: 88 kB VmExe: 16 kB VmLib: 1280 kB VmPTE: 12 kB Threads: 1 SigQ: 0/4294967295 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000000 CapInh: 0000000000000000 CapPrm: 00000000344c04ff CapEff: 00000000344c04ff s_context: 40074 ctxflags: 1602020010 initpid: 0 ipv4root: 4a00007f/ffffffff 4a24f6d5/00ffffff ipv4root_bcast: 00000000

Updated by Martha Greenberg over 2 years ago

Actually, the vserver_host should always have s_context: 0. s_context is the security context of the vserver, 0 should be the host.

Updated by James Turnbull about 2 years ago

  • Target version changed from 1.5.8 to 1.6.0

Bumped.

Updated by Paul Nasrat about 2 years ago

  • Target version changed from 1.6.0 to 1.5.8

This should be fixed for 1.5.8.

Updated by Rein Henrichs almost 2 years ago

  • Assignee changed from Paul Nasrat to Rein Henrichs

So far, it is my understanding that:

  1. /proc/self/status for vserver 2.1 contains a VxID field while 2.3 contains a s_context field.
  2. In each version, these fields can be used to determine whether we are a vserver

Here’s where my confusion starts.

Jean’s suggested change from:

return true if txt =~ /(s_context|VxID):[[:blank:]]*[1-9]/

to:

return true if txt =~ /(s_context|VxID):[[:blank:]]*[0-9]/

would imply that vserver? should be true if we are a guest or a host. Currently only the guest (non-zero VxID or s_context) returns true for vserver?. Is this correct? My assumption is that the suggested 0-9 behavior is correct (after all, why else would this ticket exist?) but I would like confirmation.

I have a testing harness in place using Jean’s sample data and can submit a patch quickly once I figure out the correct behavior. I’ve pushed my (work in progress) branch to my github at wip/2865 if anyone wants to check my work.

Updated by Paul Nasrat almost 2 years ago

Rein Henrichs wrote:

So far, it is my understanding that:

  1. /proc/self/status for vserver 2.1 contains a VxID field while 2.3 contains a s_context field.
  2. In each version, these fields can be used to determine whether we are a vserver

Here’s where my confusion starts.

Jean’s suggested change from:

return true if txt =~ /(s_context|VxID):[[:blank:]]*[1-9]/

to:

return true if txt =~ /(s_context|VxID):[[:blank:]]*[0-9]/

would imply that vserver? should be true if we are a guest or a host. Currently only the guest (non-zero VxID or s_context) returns true for vserver?. Is this correct? My assumption is that the suggested 0-9 behavior is correct (after all, why else would this ticket exist?) but I would like confirmation.

I have a testing harness in place using Jean’s sample data and can submit a patch quickly once I figure out the correct behavior. I’ve pushed my (work in progress) branch to my github at wip/2865 if anyone wants to check my work.

Looks good and seems to match my understanding of the issue too.

Updated by Jean Spirat almost 2 years ago

hi,

yes the test is there to see it this is a vserver enabled kernel, a second test “vserver_type” is there to see if it is the host or the guest. So this firts test should include the 0 as host are obviously vserver enabled .

def self.vserver?
    return false unless FileTest.exists?("/proc/self/status")
    txt = File.read("/proc/self/status")
    return true if txt =~ /^(s_context|VxID):[[:blank:]]*[1-9]/ <=========== SHOULD INCLUDE 0 TOO
    return false
end
def self.vserver_type
    if self.vserver?
        if FileTest.exists?("/proc/virtual")
            "vserver_host"
        else
            "vserver"
        end
     end
end

virtual => vserver virtual => vserver_host

the second test “vserver_type” is done only if the first return true, the current code just forbid the test to work on host as their vxid is 0 therefor host are considered normal plain linux server and not vserver enabled ones breaking previous behavior of facter (and my recipe).

regards, Jean

Updated by Rein Henrichs almost 2 years ago

  • Status changed from Needs More Information to Merged - Pending Release

Thanks for the confirmation, Paul and Jean. Fix pushed to my branch ticket/master/2865-virtual-fact-reporting and also available in reductivelabs/testing. Please confirm.

[#2865] Fix reporting of virtual facts

Regexp tested the s_context or VxID field if /proc/self/status and
returned false for 0 and true for any other number. 0 indicates a host,
which is still virtual.

Fix changes regexp to correctly report hosts as virtual. Tested against
vserver 2.1 and 2.3.

Updated by Rein Henrichs almost 2 years ago

  • Branch set to ticket/master/2865-virtual-fact-reporting

Updated by Rein Henrichs almost 2 years ago

  • Status changed from Merged - Pending Release to Ready For Checkin
  • Target version changed from 1.5.8 to 1.6.0

Merged into next

Updated by Rein Henrichs over 1 year ago

  • Status changed from Ready For Checkin to Closed

Updated by James Turnbull about 1 year ago

  • Target version changed from 1.6.0 to 1.5.9

Also available in: Atom PDF