rsyslogd gives 100%CPU

the problem is your custom kernel, which does not work with the updated rsyslogd yet. see https://bugs.edge.launchpad.net/ubuntu/+source/rsyslog/+bug/517773

Confirming, after an upgrade of rsyslogd from 4.2.0-2ubuntu5.1 to 4.2.0-2ubuntu7, rsyslog is consuming a lot of CPU cycles on my machine. See also the attached image of htop running. CPU use is more than 80%.

I suggest downgrading to 4.2.0-2ubuntu5.1 until the bug is fixed

BTW, I'm running a 2.6.31-14 kernel, which is supposedly supported. Will downgrade for the moment though.

I have Ubuntu Studio and my kernel's going absolutely crazy. Can I uninstall rsyslog.

Regression from bug 517773, which was not completely implemented.

rsyslog needs to check if it can read from /proc/kmsg as non-root, and not drop privileges if not. In other works, seteuid(), read() -> on fail, seteuid(0) and keep it that way, on success -> setuid() -> permanently drop privs.

I have observed the problem on the standard armel imx51 kernel.

linux-image-2.6.31-604-imx51 2.6.31.604.5
rsyslogd 4.2.0-2ubuntu7

rsyslogd seems to be spinning forever around select(), but I hit debugger issues and was unable to diagnose it further.

You mention select(), could it be that userspace expects pselect support but the imx51 kernel doesn't have it? For instance, under qemu-arm we were getting a lot of "unsupported syscall" for pselect, and I think this appeared recently. I suspect eglibc got rebuilt against kernel headers with pselect() support (2.6.32). If this is really related to select, it might be interesting to try with a pselect() backport in the imx51 kernel.

Actually, select() may be a misdiagnosis---

I may have been looking at the wrong thread. There seem to be two threads spinning, but the thread in select appears to be blocked and not consuming CPU.

The spinning threads both intermittently call pthread_yield(), which may could indicate some kind of livelock situation... but I really haven't gone into this in detail.