RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 743584 - starting userspace STP failed
Summary: starting userspace STP failed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Neil Horman
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-05 12:50 UTC by Johnny Hughes
Modified: 2012-03-08 21:34 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 555400
Environment:
Last Closed: 2012-03-08 19:34:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Johnny Hughes 2011-10-05 12:50:19 UTC
+++ This bug was initially created as a clone of Bug #555400 +++

At the end of the boot process, I always see the following:

Bridge firewalling registered
virbr0: starting userspace STP failed, starting kernel STP

I am not sure if this indicates any real problem (would be nice to know). However, having the line flash up between boot splash and GDM startup is simply not that nice...

--- Additional comment from berrange on 2010-03-02 10:25:29 EST ---

THis isn't a libvirt problem it happens even with brctl

# brctl addbr foo
# brctl stp foo on

# dmesg  | tail -1
foo: starting userspace STP failed, starting kernel STP

The kernel appears to print this message everytime, not matter what you do. IMHO this message should be removed from the kernel, unless there's actually a clear explanation of why this is a real error.

--- Additional comment from nhorman on 2010-03-02 14:21:19 EST ---

It shouldn't be removed from the kernel, its an accurate message in response to a legitimate failure.  The kernel is trying to fork a user space to exec /sbin/bridge-stp, which is built (normally) from these sources:
http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary

But fedora hasn't packaged it, or any other rstp userspace implementation yet, so the exec fails, and the kernel backs off to the in-kernel implementation

--- Additional comment from berrange on 2010-03-03 04:09:21 EST ---

So is there any benefit to the userspace STP helper, and if so, shouldn't it be included by the bridge-utils package so its available ?  If we don't plan to include the userspace helper in Fedora, then I still think this error message should be hidden/downgraded to look less like a problem, since this bug keeps getting re-reported by people who think something is broken with libvirt+STP.

--- Additional comment from nhorman on 2010-03-03 07:26:34 EST ---

yes, theres an advantage in that STP is really an approrpiate task for userspace, and things that are can be done in user space, generally should be.

As such, yes, we should likely package it, but no one has yet

As for the warning, I don't see how it could be softened any, nor really why it should be (setting aside the odd complaints.  Its an accurate message detailing exactly what happened, and its reported at KERN_INFO level.

The right solution is to either do nothing (understand that the message is informative, but not dangerous), or package the rstp daemon.  I definately think the latter is the wisest choice.  I can try find some time to package it shortly.

--- Additional comment from berrange on 2010-03-03 07:35:38 EST ---

Ok, that plan sounds fine to me.

--- Additional comment from nhorman on 2010-03-03 09:18:40 EST ---

I'lve opened up a review request to package rstp.  I'll close this once its in, as installing the rstp package will make this warning go away.

--- Additional comment from nhorman on 2010-04-09 13:02:45 EDT ---

so, I've pushed an rstp daemon to rawhide and F-13, so we should be good to go here.


================================================================================

Seeing the same Error when booting RHEL-6.1 on a Dell M4500 laptop with libvirt installed and VMs present on the machine.

Comment 2 RHEL Program Management 2011-10-07 15:53:20 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 3 Neil Horman 2012-02-17 16:37:56 UTC
This isn't a bug, its just an informative message indicating that no user space stp daemon was found, so the kernel is using its internal stp mechanism (which is the default).  The only way to suppress the message is to:

1) Remove the warning entirely
2) Change the message to something more detailed
3) Install a user space stp daemon, that the kernel can start.

In fedora the request was resolved by packaging and installing rstp.  We can make this an RFE to package the same daemon for RHEL if you like, but theres really no advantage to running stp in user space over kernel space

Comment 4 Johnny Hughes 2012-03-08 21:34:03 UTC
It is just confusing to see, not a real problem.  Now that I know it does not matter, I am fine with it as it is.


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