Hi all,

I'm running the new Ubuntu 10.04 on a Linode, and noticed theis message in the logs (kern.log and syslog):

kernel: imklog: Cannot read proc file system, 1.

Anyone has any idea if that's harmless, or if it may indicate some incompatibility between Ubuntu 10.04 and the Linode Paravirt kernel?

It seems to happen only a few times a day, I think it's when rsyslog restarts. Here's some more context:

May  2 17:54:27 app3 kernel: imklog: Cannot read proc file system, 1.
May  2 17:54:27 app3 rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="2020" x-info="http://www.rsyslog.com"] (re)start
May  2 17:54:27 app3 rsyslogd: rsyslogd's groupid changed to 103
May  2 17:54:27 app3 rsyslogd: rsyslogd's userid changed to 101
May  2 17:54:27 app3 rsyslogd-2039: Could no open output file '/dev/xconsole' [try http://www.rsyslog.com/e/2039 ]

Thanks

Mirko

Running the Ubuntu 10.04 linux-image-server with pv-grub instead of the Linode Paravirt kernel, the same line now looks healthier:

May  2 18:42:26 app3 kernel: imklog 4.2.0, log source = /proc/kmsg started.
May  2 18:42:26 app3 rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="392" x-info="http://www.rsyslog.com"] (r
e)start
May  2 18:42:26 app3 rsyslogd: rsyslogd's groupid changed to 103
May  2 18:42:26 app3 rsyslogd: rsyslogd's userid changed to 101
May  2 18:42:26 app3 rsyslogd-2039: Could no open output file '/dev/xconsole' [try http://www.rsyslog.com/e/2039 ]

As for the missing /dev/xconsole line that's Ubuntu bug #459730 apparently.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573980




Not specific to our latest paravirt, it would appear -- it happens to anybody running a non-Ubuntu-specific kernel (which latest paravirt is). They've apparently patched the kernel to work around the "dd running as root" problem.

Under Karmic, I remember a dd with root privileges running at all times. I do not see the same under Lucid.

If I read between the lines of the bug report, it sounds like there might be a knob to twiddle in the init scripts, and you can put their workaround back -- fire off a dd from /proc/kmsg to /var/run/rsyslog/kmsg as root, then point rsyslog at /var/run/rsyslog/kmsg using the twiddling knob. Or, give rsyslog root (might not be the most ideal solution).

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Aha, bullseye: https://bugs.launchpad.net/ubuntu/lucid ... bug/523610

and: https://bugs.launchpad.net/ubuntu/+sour ... bug/565288

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Yep that's the one. Fairly annoying because logs don't include kernel messages. Makes things difficult to debug if something goes wrong.

Maybe I'm missing something but I don't see a flag that puts the "dd proxy" back in place. I think the workaround is to run rsyslogd as root (not ideal).

Having this broken is a little frustrating because it's not very clear what's going on - I was installing a new Linode and iptables logging just wasn't working.

Can you guys consider putting the patch in the default Linode paravirt kernel? Or perhaps include the "dd proxy" in the default image?

--John

You know... people have been running syslogds as root for decades... this wole deal seems to me like yet another case of "fixing what's not broken", introducing a ton of unnecessary complication by that.
<rant> Seriously... udev, X11R7, all the WhateverKit things, KDE4... this system is becoming more and more like Windows. That is, full of hard to understand, heavyweight, and downright annoying junk. </rant>

I'm looking for this KDE4 stuff using:

dpkg -l | grep kde

and don't get any results. Is this the correct command to find it on an Ubuntu Server install? How can I remove it from my Linode if I can't find it - is it hidden somehow? You would think Canonical would let you know about these things.

James

Perhaps, but I can understand reducing the risk. Just because it's always run as root doesn't mean that's the best security posture.



Yeah. Every time I install a new release there's something new that I have to learn. Maybe I'm just getting old.

--John

If you never installed KDE, then you're not going to have any KDE packages installed...

/me beats Guspaz with the satire wand

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

/me defends with his bacon shield

Anyway, returning to the topic, I came across this error trying to figure out why my psad is not doing anything. It's because rsyslog is not logging any message from iptables. I tried sending the log to a new location based on the log-prefix but it's not working. The only way I managed to make rsyslog listen to iptables was by installing a debian newer version 4.6.2 (http://ftp.us.debian.org/debian/pool/ma ... 1_i386.deb). But this is not the elegant way of doing this. I was wondering how can I install the newer version of rsyslog from sources (5.4 stable) from rsyslog.com and removing the original way from Ubuntu Lucid.

To avoid the problem, you can use the linux-image-ec2 kernel (which really means "Xen domU") kernel that Lucid ships, and boot it with PV-Grub instead of using one of our kernels. Danny Ariti, a fine specimen of an individual, has written a guide about exactly that.

Be advised that once you go that route, kernel maintenance is up to you (and not us); however, if you're using Lucid's kernel in the repositories, then you just follow them as if you were using a computer you had installed Lucid on yourself.

I'd be hesitant to merge a distribution-specific patch into a kernel that we try to divulge from vanilla as little as possible. We have to support more than just Ubuntu, remember.

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.