udevd taking 100% CPU

[WarheadsSE]

Well, unless you need ALSA, the OSS modules shouldn't be required. As for sockets, they're in the kernel, but I bet that it's something else a little deeper. I'll check for the status of the package in our repos and upstream.

nope, we're up to speed on the upstream.

[slycat]

Ran the update on my pro, no issues. However I boot with nothing plugged in and have disabled the udev automount rules. Once booted up i then plug in my printer and HDD (plug won't boot if HDD plugged in at boot/reads HDD before USB(rootfs) drive) and no udevd power load.
Without udev-compat

Dunno what to tell ya devr. Maybe check your configuration or your fstab?

EDIT: just ran udev-compat, udevd now runs ~7%. I don't remember what the norm was prior to these issues but this beats 100%. If you reboot, check daemons.log to see if continuous printing of udev errors occur (or if syslog-ng is running hard it's probably due to udev errors as WHSE pointed out on the Pro forums).

My pro runs normal now, connectable and avg cpu load of 8.9% will all apps running.

[devr]

More info, not sure if it is helpful. Did some digging and saw the following udev commands in /etc/rc.sysinit

$this->bbcode_second_pass_code('', 'udevd --daemon
udevadm trigger --action=add --type=subsystems
udevadm trigger --action=add --type=devices
/sbin/udevadm settle --quiet --timeout=${UDEV_TIMEOUT:-30}')

Doing these commands manually. It isn't until I run, "/sbin/udevadm settle --quiet". that udevd starts logging like crazy.

[pepedog]

I read this http://old.nabble.com/-signoff--udev-168-2-td31639556.html
$this->bbcode_second_pass_quote('', 'T')here was a regression in udev-168 where "udevadm settle" would
sometimes return too early. This lead to some (apparently rare)
systems being unable to boot, especially people booting from usb
drives or not having devtmpfs support in their kernels were affected

[tux]

This thread has gone quiet for a few days.

Having successfully upgraded my Pogo B03 using WarheadsSE's instructions and script I too notice on reboot that udevd takes around 80% and syslog-ng takes around 20% of CPU. Interestingly webmin reports a total of 40% or less. I am at work and not at the Pogo to check the exact figures.

The process id of udevd is 359 everytime I boot so killing it then restarting syslog-ng drops the CPU down again checking via SSH. I actually have a bash script to automate this. I am guessing that USB devices are no longer automounted. Any other effects?

So I thought I would add my own experiences to try to get this going forward. Not a Linux expert but happy to bug test for anyone if they can find possible solutions.

[tux]

Forgot to mention that I am booting from an 8GB mini sd card plugged into a USB adapter formatted as ext2.

Any suggestions or things to try are most welcome.

[WarheadsSE]

For the moment, stop syslog-ng. It udevd logging like hell will eat your 8GB sd for lunch.

[tux]

$this->bbcode_second_pass_quote('WarheadsSE', 'F')or the moment, stop syslog-ng. It udevd logging like hell will eat your 8GB sd for lunch.

[WarheadsSE]

What I have noticed at this point:
udev tends to end up as pid 361 every time I boot.

kill -15 361
udevd &

nice behavior.

[DavidYon]

Am also seeing this on a B03 (black) oxnas plug. I don't get the syslog-ng going wild or log files eating up the entire partition, but udevd chews along at 99-100% CPU. After boot, if I manually do the following then udevd calms down:

$this->bbcode_second_pass_code('', '
killall udevd
/sbin/udevd --daemon
/sbin/udevadm trigger --action=add --type=subsystems
/sbin/udevadm trigger --action=add --type=devices
')

From my Googling of the problem it appears that there is a combination of a newer kernel and udevd which fixes this. But the Arch Linux ARM repository doesn't seem to have them.

But thanks thanks thanks for getting the V3/OXNAS script done and documented! For now I might put the above in rc.local, but it would be nice for the repo to get updated with binaries that don't have this bug.