This should be a short one, I'm not going to explain much, just report a couple of issues I've had with Fedora 16 since updating from Fedora 14, and which took me some digging to sort out.
At least I hope I've sorted them out. I have a couple of outstanding issues, which I'll amend if I fix them.
Bind DNSSEC errors in /var/log/messages
I had a lot of the following spewing forth into my system log, and I had presumed it was down to various odd sites being not configured correctly, but it got worse in F16 (near constant scribbling):
May 24 18:45:32 box named: error (insecurity proof failed) resolving 'com/NS/IN': 184.108.40.206#53 May 24 18:45:32 box named: validating @0xb3c48a98: com NS: got insecure response; parent indicates it should be secure May 24 18:45:32 box named: error (insecurity proof failed) resolving 'com/NS/IN': 220.127.116.11#53
Turns out this is bind's DNSSEC (DNS security, look it up). While I did have it configured, and seemingly correctly (correct keys, etc.), I still got these all the time.
I believe now it is down to neither my router nor my ISP supporting DNSSEC, and I have these as forwarders in my local named.conf. So I disabled it, and all my errors vanished:
// In the top level 'options' section dnssec-enable no; dnssec-validation no; // dnssec-lookaside auto
Pulseaudio authorization errors
I also had the following pooing itself into the log file every few seconds:
May 24 18:45:34 box pulseaudio: protocol-native.c: Denied access to client with invalid authorization data.
I still don't know quite what was going on here, and it was only happening to me (that number is a process ID, and it was always my pulseaudio process), even after killing it or logging out. It would stop for a while, then start up again. I didn't have any other noticeable audio problems.
Last night, I did: (663 being the process ID listed)
kill 662 && mv -f ~/.pulse ~/.pulse.old
This killed pulseaudio, and blew away its settings/sessions data so it would have to re-create everything. strace had told me that as the errors got printed, there was some activity on a couple of open file descriptors, and lsof -p 664 had said that these were file sockets in ~/.pulse/../native.
So far, no problems (although it's only been overnight, and I wasn't running Pidgin or Skype). Oddly, looking now, I haven't got the pipe back in my home directory, it's now using /tmp ...
OK, that didn't work. Now, looking at the logs, it looks like it starts occurring just as I user switch back to my login (or maybe just unlock) as there's a whole slew of gnome-session and related dbus stuff at exactly the time the pulseaudio entries start re-appearing. Can't reproduce it, though.
Another google session has taken me to this blog of someone who seems to have suffered a similar fate (thanks, Google Translate!). I have no idea how he came up with the solution, but I've tried it and now gone a day without the errors. I've edited /etc/pulse/default.pa to comment out
### Load several protocols ## .ifexists module-esound-protocol-unix.so ## load-module module-esound-protocol-unix ## .endif load-module module-native-protocol-uni
Just to further muddy the waters, my default.pa file hasn't been edited (I know I typed it, and then restarted pulseaudio, what the hell?) in the past day, so that line's not currently commented out. If I do see it again, I'll comment it out (again), but for now, all's quiet.