today's glibc update breaks DNS

English Network/Internet
#1

I accepted the recent glibc updates from the update repo and found that external hosts stopped resolving. A strace on ping example.com showed that it was not contacting nscd. It turned out nscd was dead. So I restarted it. No dice. (Anyway glibc is supposed to fall back to calling libnss_dns itself if nscd is not available.)

Anyway to cut a long story short (include some red herrings involving my DNS server), I decided to reinstall the old glibc and names started resolving again.

I had a look at the changelog of the new glibc package and it looks worrying:

  • Re-enable the DNS fixpack, add real fix for bnc#441947
  • nscd: Fix gc he_data overflow and turn of alloca usage [bnc#387202]
  • Normalize the patch queue
  • Disable the DNS fixpack from CVS, breaks nscd resolving [bnc#441947]

It feels like the nscd bug mentioned isn’t really fixed and something was broken. I’m going to have a look at those BNCs now.

Anyway just to warn people, since losing name resolution means losing further updates, you may have been painted into a corner if you experience the same bug as I did. In that case, you can get out by reinstalling the previous glibc (from DVD for example).

You might want to try the update on a non-vital machine first.

#2

WOW. Thanks for the up on this. I watch out for that.:open_mouth:

#3

glibc updates always scare the heck out of me.

I updated 3 PCs. Looks like I’ll have to dig out the DVD and roll back.

#4

I’m someone who saw the original problem fixed, but used a workround, unfortunately I wiped 11.1 on the affected box so cannot verify this update. Anyway I updated another machine and the DNS seems to resolve OK for me, even after restart.

#5

Hi
Working fine here? ncsd running, although I use the openDNS servers.

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.1 x86 Kernel 2.6.27.7-9-default
up 0:29, 2 users, load average: 0.28, 0.13, 0.17
GPU GeForce 6600 TE/6200 TE - Driver Version: 180.27

#6

Never mind, it was my own fault. >:(

In /etc/resolv.conf, I had:

127.0.0.1

instead of

nameserver 127.0.0.1

It wasn’t intentional, I forgot the nameserver qualifier. The old glibc must have let me get away with the shorter form but is strict now.

I’ve reapplied the update and it’s all fine again.

#7

At least I had to learn in hurry how to reassemble a software RAID without any config file, when I borked libc and had to reinstall the RPM from DVD.

Boot from DVD and choose Rescue System. Repair System doesn’t seem to know about software RAID.

mdadm --examine --scan --config=mdadm.conf >> mdadm.conf

This will put mdadm’s guess about your arrays into mdadm.conf. Have a look at the file. For me I continued:

mdadm --assemble /dev/md/0
mdadm --assemble /dev/md/1
fsck /dev/md0
mount /dev/md1 /mnt
umount /mnt
xfs_check /dev/md1
mount /dev/md0 /mnt

The mount and unmount are required by XFS to replay the log. For me md0 is /, md1 is /home.

Next I deleted the new RPM and restored the old one from DVD:

mount /dev/sr0 /media/cdrom
rpm -r /mnt -qi glibc glibc-32bit
rpm -r /mnt -e glibc-2.9-blahblah glibc-32bit-2.9-blahblah
cd /media/cdrom/suse/x86_64
rpm -r /mnt -i --force glibc-2.9* glibc-32bit-2.9*

Then a ldconfig, I don’t think this is needed as the boot will do it, but anyway:


chroot /mnt /bin/bash
ldconfig
exit

Unmount and reboot:


umount /mnt
shutdown -fr now

Now that it was up and running, refreshed the repo caches and accepted the updates.

#8

ken yap wrote:
> Never mind, it was my own fault. >:(
>
> In /etc/resolv.conf, I had:
>
> 127.0.0.1
>
> instead of
>
> nameserver 127.0.0.1
>
> It wasn’t intentional, I forgot the nameserver qualifier. The old glibc
> must have let me get away with the shorter form but is strict now.
>
> I’ve reapplied the update and it’s all fine again.
>
>
Ken

Your problem saved me. I was going crazy trying to figure out what
happened to my DNS service after the last YAST update. Now I know.

After reloading the old glibc from the dvd, I have name resolution again.

You mentioned that you “fixed” your problem by modifying a line in your
resolv.conf file. I don’t have a line listing my nameserver, just a
single line that reads

search xxxx.edu (our domain name)

Any ideas why that might cause a problem with the newer version of
glibc? I have a pretty standard 11.1 install with a wired internet setup.

Thanks.

#9

Well if you don’t have in /etc/resolv.conf any line like

nameserver a.b.c.d

that would cause a problem for resolving libraries. You have to figure out why your network config didn’t put such a line there.

#10

ken yap wrote:
> Well if you don’t have in /etc/resolv.conf any line like
>
> nameserver a.b.c.d
>
> that would cause a problem for resolving libraries. You have to figure
> out why your network config didn’t put such a line there.
>
>

My /etc/sysconfig/network/config file contains a line
NETCONFIG_DNS_STATIC_SERVERS a.b.c.d a2.b2.c2.d2

but this does not get reflected in the /etc/resolv.conf file.

In addition, I see that the /etc/sysconfig/network/config file has the line

NETCONFIG_DNS_FORWARDER=“bind”

while I though I was using “resolver”.

Not sure where those get set in within the maze of yast2

I have no idea how to proceed except to hand edit the files. Not sure
why the version of glib would have anything to do with the way this ends
up effecting dns.

#11

I gave up on trying to understand NETCONFIG and edited /etc/resolv.conf by hand (which was how I introduced my typo in the first place). Since I have a static address (on this LAN), I can do what I want with /etc/resolv.conf and not worry about DHCP overwriting it.