upstart-udev-bridge eats 100% cpu calling dbus_message_iter_append_basic()

StacktraceTop:
 __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:51
 ?? () from /tmp/tmp0yDejf/lib/x86_64-linux-gnu/libdbus-1.so.3
 ?? () from /tmp/tmp0yDejf/lib/x86_64-linux-gnu/libdbus-1.so.3
 dbus_message_iter_append_basic () from /tmp/tmp0yDejf/lib/x86_64-linux-gnu/libdbus-1.so.3
 upstart_emit_event (proxy=0x7f7a0e58b2f0, name=0x7f7a0e58efb0 "power_supply-device-added", env=<optimized out>, wait=0, handler=0, error_handler=0x7f7a0d53cd7c <emit_event_error>, data=0x0, timeout=2147483647) at com.ubuntu.Upstart.c:1018

Status changed to 'Confirmed' because the bug affects multiple users.

This is looking like a bug with udev / the kernel relating to an udev event for the laptops battery. See bug 850935.

Status changed to 'Confirmed' because the bug affects multiple users.

The attached test job config file logs the first 10 "power_supply-device-added" events emitted to /run/initramfs/bug-829980.log. To use it:

1) sudo stop upstart-udev-bridge
2) Plonk the attached bug-829980.conf into /etc/init/.
3) Reboot with the battery attached.

If /run/initramfs/bug-829980.log contains >1 entry, the bug is with udev or the kernel. If the file is not generated, please look at /var/log/udev to see if the udev "power_supply" event was emitted:

awk 'BEGIN{RS="";ORS="\n\n"}; /ACTION=add/ && /SUBSYSTEM=power_supply/ { print; }' /var/log/udev

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Using the instructions in comment #8, I get a single entry:

steve@steve-laptop:~$ cat /run/initramfs/bug-829980.log
Mon Sep 26 11:42:46 2011 220376316
steve@steve-laptop:~$

I've also attached the output of the awk command,

This is still reproducible on 3.0.0-12:
Linux steve-laptop 3.0.0-12-generic #19-Ubuntu SMP Fri Sep 23 21:23:39 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I believe I now understand the problem. This has nothing to do with Upstart - it's a kernel issue. Well, to be more precise, it's a problem with the firmware on your batteries coupled with the kernel not sanity checking device property values before handing them to userspace.

The file below in the kernel emits udev events on behalf of power supplies and batteries:

    drivers/power/power_supply_sysfs.c

The expectation is that a "struct power_supply"'s 'properties' are encoded in ASCII. But let's look at @smagoun's log...

$ grep "[^[:print:]]" udev_power_supply.txt|od -xc
0000000 4f50 4557 5f52 5553 5050 594c 4d5f 444f
          P O W E R _ S U P P L Y _ M O D
0000020 4c45 4e5f 4d41 3d45 5341 424d 3130 6332
          E L _ N A M E = A S M B 0 1 2 c
0000040 1468 f401 0ae0 4f50 4557 5f52 5553 5050
          h 024 001 364 340 \n P O W E R _ S U P P
0000060 594c 4d5f 4e41 4655 4341 5554 4552 3d52
          L Y _ M A N U F A C T U R E R =
0000100 654e 6577 5472 6365 1468 f401 0ae0 4f50
          N e w e r T e c h 024 001 364 340 \n P O
0000120 4557 5f52 5553 5050 594c 4d5f 444f 4c45
          W E R _ S U P P L Y _ M O D E L
0000140 4e5f 4d41 3d45 5341 424d 3130 6332 1468
          _ N A M E = A S M B 0 1 2 c h 024
0000160 f401 0ae0 4f50 4557 5f52 5553 5050 594c
        001 364 340 \n P O W E R _ S U P P L Y
0000200 4d5f 4e41 4655 4341 5554 4552 3d52 654e
          _ M A N U F A C T U R E R = N e
0000220 6577 5472 6365 1468 f401 0ae0
          w e r T e c h 024 001 364 340 \n
0000234
$

What we *expect* to see for the first entry is:

    POWER_SUPPLY_MODEL_NAME=ASMB012ch\n

What we *actually* see is

   POWER_SUPPLY_MODEL_NAME=ASMB012ch<garbage>\n

Where <garbage> in this case is "024 001 364 340" which are extended / non-printable characters. So this data gets sent across to userspace where it is picked up by udevd which then hands it on to upstart-udev-bridge. The bridge pulls apart the udev message and constructs an upstart event, adding all udev properties to that events environment. upstart_emit_event() does this by calling dbus_message_iter_append_basic(), but then that call barfs since it detects the non-printable characters. Since upstart wraps the call to upstart_emit_event() in an NIH_MUST(), upstart_emit_event() will get called forever until it succeeds (which it won't), thus maxing out your CPU.

One possible (generic) fix would be for lib/kobject_uevent.c:add_uevent_var() to remove all non-printable characters from uevent variables to avoid causing problems in userspace.

Marking kernel bug task 'Confirmed' based on comment #12. I have a (mostly-dead) battery from another manufacturer that I can try for comparison as well.

We could of course modify upstart-udev-bridge to sanitize the values, but that will patch the problem with that application.

@Sascha: Could you possibly follow the instructions in comment #8 to see if your battery is also a NewerTech model like @smagouns?

Turns out my other battery is completely dead (kernel doesn't see it), so I can't test it. Sounds like we know what's wrong w/ the NewerTech battery though.

Kay has intimated that the sanitizing of udev messages is a userspace concern (the kernel just passes the data from the device to userspace):

  http://marc.info/?l=linux-hotplug&m=131737595918135&w=2

This implies that maybe we should fix the upstart-udev-bridge to perform sanitization, but how this should be done is unclear. The batteries @smagoun and @Sascha have -- as far as I know -- are the only devices we've ever seen that have caused this problem, but we *could* modify upstart-udev-bridge to add a new switch "--sanitise" that would do the following:

- if non-printables are found in either the udev event name or the udev event environment, replace them with spaces.
  (to handle potential utf-8 characters within strings).

- if non-printables are found *at the end* of either the udev event name or the udev event environment, remove them.
  (to handle what appears to be a buggy device that that is passing junk to the kernel erroneously).

- if any non-printable characters are found, the upstart-udev-bridge will emit a warning message showing:
  - the sanitized name of the event that contained non-printables.
  - the sanitized name of the environment variable associated with the udev event that was found to contain non-printables
   (if applicable).
  - maybe a hex-encoded version of the orignal value that was found to contain non-printables.

Ubuntu would then add the "--sanitise" switch to /etc/init/upstart-udev-bridge.conf. Note that not specifying "--sanitise" would revert to performing no sanitising of any udev event names or environment variables (the current behaviour).

We could change the way the upstart-udev-bridge creates the dbus messages, but that would take time, require lots of extra tests to be written and probably isn't worth the effort as we seem to be dealing with potentially a very small set of devices sending non-printables to userspace (maybe just the device @smagoun has).

Since the upstart-udev-bridge currently does not support extended characters (as evinced by this bug), no Upstart jobs can be relying on such characters. Therefore following the precedent set by upower...

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/upower/oneiric/view/head:/src/linux/up-device-supply.c#L485

... we'll change the bridge to discard extended characters until there is a proven need to support extended (maybe utf-8?) characters.

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

Sorry for the late response. and no its not a newtech and it doesn't seem to have nonprintables in it - the model and manufacturer names look idiotic though. it is a macbook pro 8,2 (early 2011).

KERNEL[15.486517] add /devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP1
SUBSYSTEM=power_supply
POWER_SUPPLY_NAME=ADP1
POWER_SUPPLY_ONLINE=1
SEQNUM=1639

UDEV [15.499193] add /devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP1 (power_supply)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP1
SUBSYSTEM=power_supply
POWER_SUPPLY_NAME=ADP1
POWER_SUPPLY_ONLINE=1
SEQNUM=1639

KERNEL[15.518733] add /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
SUBSYSTEM=power_supply
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10950000
POWER_SUPPLY_VOLTAGE_NOW=12490000
POWER_SUPPLY_POWER_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=69000000
POWER_SUPPLY_ENERGY_FULL=68240000
POWER_SUPPLY_ENERGY_NOW=67640000
POWER_SUPPLY_MODEL_NAME=bq20z4516MWDGDLAH123456789ABCDE
POWER_SUPPLY_MANUFACTURER=SMPNz4516MWDGDLAH123456789ABCDE
SEQNUM=1725

UDEV [15.519559] add /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
SUBSYSTEM=power_supply
POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10950000
POWER_SUPPLY_VOLTAGE_NOW=12490000
POWER_SUPPLY_POWER_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=69000000
POWER_SUPPLY_ENERGY_FULL=68240000
POWER_SUPPLY_ENERGY_NOW=67640000
POWER_SUPPLY_MODEL_NAME=bq20z4516MWDGDLAH123456789ABCDE
POWER_SUPPLY_MANUFACTURER=SMPNz4516MWDGDLAH123456789ABCDE
SEQNUM=1725

Dear all,

error does also happen with Kernel 3.0.0-12.20.
I´ve got the Problem on my Dell D420 with a batterie from GRS.

Problem also here on Dell Latitude D810.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  279 root 20 0 2648 648 528 R 85.0 0.1 72:14.57 upstart-udev-br

Forgot to mention kernel: 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux,

Well, one workaround is just to "sudo stop upstart-udev-bridge", you could add that to your startup programs so it doesn't affect you again.

Never mind the comment before this (made a mistake). The steps to kill this task are: (in terminal) sudo top (this will show you what stuff is taking up CPU) then, find the PID of the upstart-udev bridge task in the table below, and hit k and enter the PID. It is now dead.

Problem also exists with a Thenkpad X201 Tablet with the 8-cell battery.

bart@cox ~$ uname -a
Linux cox 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

bart@cox ~$ cat /proc/acpi/battery/BAT0/info
<snip>
model number: 42T4658
serial number: 30991
battery type: LION
OEM info: SANYO

I have the same problem. I use a ThinkPad x201 like Bart.

I have the same problem and it prevents me from using Ubuntu for now.

Like Sasha Teske, I have a MacBook Pro 8,2 (early 2011).

I am working on the fix for this now. However, to ensure we fully understand the problem, please could those seeing this problem attach file /var/log/udev to this bug so I can see the raw data.

By the way, if you simply 'cat' the file(s), you won't necessarily see the extended characters since as they are generally not printable, the terminal driver won't display them. However, you can detect them by doing something like:

    grep "[^[:print:]]" /var/log/udev /proc/acpi/battery/BAT0/info

Or if you want to see them:

    grep "[^[:print:]]" /var/log/udev /proc/acpi/battery/BAT0/info | od -xc

Vim also highlights extended chars by default.

Attached file is from a MacBookPro 7,1

udev from my Dell D420.

Hope this helps.
Thanks a lot,
Regards Tobias

MacBook Air 3,1 (UK)

Thanks to all those who attached logs. All logs show trailing binary 0x02 (CONTROL-B) bytes at the end of the POWER_SUPPLY_MANUFACTURER value. So I think this single rogue byte, encoded in the battery meta-data, is ironically indirectly causing you high battery drain :-(

The fact that we've so far only seen this problem with power supply manufacturer strings suggests that it is *highly* unlikely there will be any adverse effects of the proposed fix since even if an Upstart job were to care about a battery device, it really shouldn't be caring about the specific manufacturer details.

Please could those affected by this issue test the fix available in the following PPA:

  https://launchpad.net/~jamesodhunt/+archive/bug-829980

To install the fix:

1) In a terminal, run:

   sudo add-apt-repository ppa:jamesodhunt/bug-829980

  This will show you some text and ask you to press return to enable this repository.

2) Run:

  sudo apt-get update && sudo apt-get upgrade

Step (2) should pull in the latest test version of Upstart (version "1.3-0ubuntu12~bug829980"). If so, reboot as normal and then update this bug with your results.

[Note: I've tested this fix, but note that I do not have access to any of these bad batteries. So, in the unlikely event you *do* experience issues with the fix, remove your battery and boot from AC power].

Thanks in advance.

... by the way, you can determine whether your system cares about battery events by running the following in a terminal:

    grep -q power_supply-device /etc/init/* && echo WARNING || echo NO PROBLEMS

@jamesodhunt -

Problem has not recurred for me since I installed your fix. Looks good from here.

Dear James,

same here, problem does not appear anymore.

Thank you so far!!
Rgds. Tobias

The patch works for me too, with no apparent side effects

I just installed the patched upstart and rebooted. The 100% cpu-usage problem is gone and in the 5-minutes or so of testing, there aren't any obvious new problems. Thanks! I'm running a late 2009 15" MBP.

I just installed the patch, but had an error message:

Loading new hid-1.1.2 DKMS files...
Error! /usr/src/hid-1.1.2.dkms.tar.gz does not exist.
dpkg : erreur de traitement de hid-dkms (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 2
Paramétrage de upstart (1.3-0ubuntu12~bug829980) ...
Des erreurs ont été rencontrées pendant l'exécution :
 hid-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

Sorry, it's in French :-), but the main error is "Error! /usr/src/hid-1.1.2.dkms.tar.gz does not exist."

Kind regards

@Benoit: The problem you are seeing is unrelated to the Upstart fix - it relates to the 'dkms' package on your system. Please could you raise a new bug against the 'dkms' package.

it`s cool - not only in the figurative sense - on my laptop too. thank you very much

Thanks James.
I just reinstalled Oneiric and I don't have the upstart bug anymore... So I couldn't try again your upstart fix.

Thank you James!

I've been running the patch for a few days now and it looks good to me.

The patch is working well for me too. I'm using a 13" macbook pro from mid 2010.

Thank you!

I had the described problem on my Lenovo Thinkpad X201 Tablet; it seems that the patch from #32 solved it.

Linux ulf-tab 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
upstart (1.3-0ubuntu12~bug829980) oneiric; urgency=low

I ran across this problem with Oneiric on my Lenovo x100e. With James' fix, the issue no longer occurs, and after several hours use, there does not appear to be any regressions caused by it.

Thanks,

Chris

Having the same problem with Lenovo Y560 running Oneric

3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Attached /var/log/udev. Will try patch, and report back.

Having the same problem with Lenovo Y560 running Oneric

3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Attached /var/log/udev. Will try patch, and report back.

The patch works on Lenovo Y560 running Oneric:
3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Patch works well on my MacBook 5,1

Thanks
Tim Allen

After updating this morning, I had this problem for the first time.

Lenovo T500, Linux photon 3.0.0-15-generic #24-Ubuntu SMP Mon Dec 12 15:23:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Udev log attached

Got the same problem on fresh installation of Ubuntu Server 11.10.

Udev log is attached, installation of a patched upstart above didn't resolve the problem.

This issue has now been fixed in Ubuntu Precise (12.04).

Running 11.10 and its getting on my nerves!

I use Y460 ,Ubuntu oneiric 11.10 and gnome 3 .
I meet the same problem after I remove alacarte (Main menu) form my system.
Then,upstart-udev-bridge eats 100% cpu. When I reinstall alacarte ,every thing goes well cpu go to normal.

Hi, I've got the same problem on a Dell 2950 server - no batteries installed save for those in the RAID cards, so it doesn't look to be isolated to laptops. The machine in question worked fine until oneiric install, and shows the problem after a variable amount of time, could be minutes possibly hours/days

Going to try James' patch

Copy of /var/log/udev attached

I just run into this issue on a Dell Inspiron 6400 with a spare battery. In /var/log/udev (attached) I see the following line:
POWER_SUPPLY_MANUFACTURER=PSÿ

I have the manufacturer correct but the line above seems 'corrupt':

POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
POWER_SUPPLY_VOLTAGE_NOW=12494000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=5800000
POWER_SUPPLY_CHARGE_FULL=5698000
POWER_SUPPLY_CHARGE_NOW=5698000
POWER_SUPPLY_MODEL_NAME=<B5>M09H56
POWER_SUPPLY_MANUFACTURER=PANASONIC
SEQNUM=1231

The <B5> seems odd.

On Fri, Mar 09, 2012 at 09:53:23PM -0000, ronny wrote:
> I just run into this issue on a Dell Inspiron 6400 with a spare battery. In /var/log/udev (attached) I see the following line:
> POWER_SUPPLY_MANUFACTURER=PSÿ
>
>
> ** Attachment added: "udev log file"
> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/829980/+attachment/2842173/+files/udev
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/829980
>
> Title:
> upstart-udev-bridge eats 100% cpu calling
> dbus_message_iter_append_basic()
>
> Status in Upstart:
> Fix Released
> Status in “linux” package in Ubuntu:
> Confirmed
> Status in “upstart” package in Ubuntu:
> Fix Released
>
> Bug description:
> the segv was created by me sending a kill -11. but the 100% cpu is
> unbarable
>
> ProblemType: Crash
> DistroRelease: Ubuntu 11.10
> Package: upstart 1.3-0ubuntu6
> ProcVersionSignature: Ubuntu 3.0.0-8.11-generic 3.0.1
> Uname: Linux 3.0.0-8-generic x86_64
> NonfreeKernelModules: fglrx
> Architecture: amd64
> Date: Sat Aug 20 11:48:34 2011
> ExecutablePath: /sbin/upstart-udev-bridge
> InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64+mac (20110803.1)
> ProcCmdline: upstart-udev-bridge --daemon
> ProcEnviron: PATH=(custom, no user)
> Signal: 11
> SourcePackage: upstart
> StacktraceTop:
> ?? () from /lib/x86_64-linux-gnu/libc.so.6
> ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
> ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
> dbus_message_iter_append_basic () from /lib/x86_64-linux-gnu/libdbus-1.so.3
> ?? ()
> Title: upstart-udev-bridge crashed with SIGSEGV in dbus_message_iter_append_basic()
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/upstart/+bug/829980/+subscriptions

My Toshiba Satellite was pretty much made useless after upgrading. I looked around and saw that the CPU was running near 100%. After the fix, it now idles around 8%. Thank-you for this fix.

I had the same problem on my HP Microserver 40L (and I'm sure it's not a laptop :-) ) and the patch fixed it!

Linux mediaserver 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012 i686 athlon i386 GNU/Linux

I noticed these log entries during the boot process after applying the fix from comment #32:

---
init: upstart-udev-bridge main process (497) killed by ABRT signal
init: upstart-udev-bridge main process ended, respawning
init: upstart-udev-bridge main process (661) killed by ABRT signal
init: upstart-udev-bridge main process ended, respawning
...
init: upstart-udev-bridge respawning too fast, stopped
---

The fix does stop the upstart-udev-bridge process running at 100%, but I'm curious about these log entries.

Just posting information on the fix. This bug affected me as well. However it was not with the POWER_SUPPLY_MODEL_NAME. Every time I would unplug and plugin my laptop I would get 100% CPU usage from upstart-udev-bridge.

The garbage characters are in the value of the model name for this Sanyo battery.

0003760 012 120 117 127 105 122 137 123 125 120 120 114 131 137 115 117
         \n P O W E R _ S U P P L Y _ M O
0004000 104 105 114 137 116 101 115 105 075 060 021 060 052 171 206 012
          D E L _ N A M E = 0 021 0 * y 206 \n

I have applied the fix and restarted upstart-udev-bridge and the issue has not appeard again, even after rapidly unpluging and pluging in the power supply. Attached is just the output for the add event for the power supply.

Thanks for the fix.

Having the same problem with Lenovo E46

Linux lo 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux

And i used "sudo service udev stop" to solve the problem.

What about a backport to 11.10? It just don't seem right to put a boot script to shut down upstart.