Bug 545170 - libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No such file or directory
Summary: libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No s...
Keywords:
Status: CLOSED DUPLICATE of bug 555805
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: numactl
Version: 5.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On: 484552
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-07 19:28 UTC by Marc Milgram
Modified: 2010-11-09 12:57 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 484552
Environment:
Last Closed: 2010-01-15 16:41:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
remove warning (490 bytes, patch)
2009-12-07 19:28 UTC, Marc Milgram
no flags Details | Diff

Description Marc Milgram 2009-12-07 19:28:42 UTC
Created attachment 376755 [details]
remove warning

+++ This bug was initially created as a clone of Bug #484552 +++

With libvirt-0.6.0-2.fc10.i386:

$> virsh list --all
libnuma: Warning: /sys not mounted or no numa system. Assuming one node: No such file or directory

Pretty sure this is new with 0.6.0

--- Additional comment from berrange on 2009-02-09 03:58:27 EDT ---

This messages comes from  libnuma.so, in libnuma.c, the method

static void
set_configured_nodes(void)
{
        DIR *d;
        struct dirent *de;

        d = opendir("/sys/devices/system/node");
        if (!d) {
                numa_warn(W_nosysfs,
                   "/sys not mounted or no numa system. Assuming one node: %s",
                        strerror(errno));
                maxconfigurednode = 0;
...


The 'set_configured_nodes' call is done from

static void
set_sizes(void)
{
        sizes_set++;
        set_configured_nodes(); /* configured nodes listed in /sys */
....


Which is in turn called from:

/*
 * There are two special functions, _init(void) and _fini(void), which
 * are called automatically by the dynamic loader whenever a library is loaded.
 *
 * The v1 library depends upon nodemask_t's of all nodes and no nodes.
 */
void
numa_init(void)
{
        int max,i;

        set_sizes();
....



So this function is triggered the momment libnuma.so is loaded by the linker, and libvirt has no way to make it STFU :-(

The reason you won't have seen it with previous libvirt build in F10 is that the libvirt RPM (and numa build) was buggy and thus not actually enabling NUMA  on F10 when it should have been.

We need to fix libnuma so it doesn't print this junk to stderr/out. It should be upto apps using libnuma to decide whether to print a warning, not have it foisted on them at library load time.

--- Additional comment from nhorman on 2009-02-09 07:09:41 EDT ---

Actually, it seems like the right fix would be to understand why /sys isn't mounted at the time that this initalization routine is called.  To do anything else will keep numa from getting initalized.  At what point during the boot is this happening?

--- Additional comment from berrange on 2009-02-09 07:23:26 EDT ---

I don't think its a missing /sys that's the problem here, but rather the sub-directory. The warning is triggered by:

        d = opendir("/sys/devices/system/node");


This can occurr if /sys is mounted, but /sys/devices/system/node does not exist. The kernel does not appear to create the trailing 'node' directory on machines which aren't NUMA. For example, it is not present on my laptop

# ls /sys/devices/system
clocksource  cpu  i8237  i8259  ioapic  irqrouter  kvm  lapic  timekeeping
# ls /sys/devices/system/node
ls: cannot access /sys/devices/system/node: No such file or directory

--- Additional comment from markmc on 2009-02-09 07:26:14 EDT ---

(In reply to comment #3)
> The kernel does not appear to create the trailing 'node' directory on
> machines which aren't NUMA. For example, it is not present on my laptop

Right, that's the case here too

--- Additional comment from nhorman on 2009-02-09 11:14:21 EDT ---

ah, my bad, didn't realize that we didn't create that node on non-numa systems.  I'll put together a patch for this shortly.

--- Additional comment from nhorman on 2009-02-09 11:29:20 EDT ---

Created an attachment (id=331331)
patch to change numa warning conditions

here you go, give this a try please.  I figure we still need to warn in the event that /sys isn't mounted (because then we can't tell if a system is numa or not), but just runniing libnuma on a non-numa system probably doesn't warrant a warning.

--- Additional comment from markmc on 2009-02-09 11:47:17 EDT ---

Yeah, seems to work fine

--- Additional comment from nhorman on 2009-02-09 15:39:29 EDT ---

fixed in -3.fc10

--- Additional comment from yaneti on 2009-03-05 08:27:21 EDT ---

F10 is all set but rawhide is still waiting for this fix.

--- Additional comment from michael.monreal+bugs on 2009-03-16 13:32:45 EDT ---

Is this just a "harmless" warning or does it break libvirt? (having problems with virt-manager on RawHide where this is still not fixed and try to figure out what causes them)

--- Additional comment from markmc on 2009-03-25 06:56:10 EDT ---

Sure enough, it's not fixed in rawhide

--- Additional comment from nhorman on 2009-03-25 07:07:30 EDT ---

Its not fixed yet, the fix is upstream, in release 2.0.3 (which has rc2 released at the moment, I've been planning to do a wholesale update to that release as soon as its pushed, at which point this bug will get fixed.

--- Additional comment from markmc on 2009-03-25 09:01:28 EDT ---

Mind if I just go ahead and copy the fix from F10 in the mean time? The warning is fairly annoying for virt users

--- Additional comment from nhorman on 2009-03-25 09:35:50 EDT ---

If you like, sure, you can also just remove the warning entirely, as that appears to be the upstream fix.

--- Additional comment from markmc on 2009-03-25 11:10:20 EDT ---

Thanks

* Wed Mar 25 2009 Mark McLoughlin <markmc> - 2.0.2-4
- Remove warning from libnuma (bz 484552)

--- Additional comment from mmilgram on 2009-12-07 13:45:30 EDT ---

(From update of attachment 331331 [details])
fstat was used incorrectly in this patch.  A different fix was actually used.

Comment 2 RHEL Program Management 2009-12-22 15:09:36 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 3 Neil Horman 2010-01-15 16:41:59 UTC

*** This bug has been marked as a duplicate of bug 555805 ***


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