Hacker News Reader

Comment by cft | Hacker News Reader

>Patch ASAP

What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..

View on HN

Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it.

This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

That isn't it, see siblings here. You have to restart all processes that load glibc and interact with the affected services.

Debian does this automatically and alerts the user what services are being restarted.

I updated this morning and nothing got restarted. Shouldn't pretty much every network service I have gotten a restart? sshd, postfix, apache, icecast2, dovecot

None of them restarted. So I restarted them all myself...

It doesnt't. There's the needsrestart package that does this though.

Go?

Well, now, a lot of people are making containers, which are static linking turned up to 11.

I bet this bug will live on forever in people's Docker stacks.

Does libc even support static linking?

glibc is generally not statically linked. MUSL libc generaly is.

You _can_ statically link glibc, but then you lose some stuff. https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

Nope, the pendulum is at it's other extreme. Go is going all in on static builds, docker containers freeze ALL THE THINGS \@/ and "immutable" package managers like Nix which in effect is like static linking without the speed benefits.

The past four years of modern development practices have run screaming from the concept. Learning why the systems used to work they way they did was, like, super hard, so they reinvented the wheel and are running into the same problems that caused us to make shared libraries/COW/etc in the first place.

You've pretty fundamentally misunderstood them if you think immutable practices in anyway damage the ability to deploy fixes. Years of shared library hell is what causes things like this to go unfixed.

Immutability in software development & deployment is, for the vast majority of use cases, completely unnecessary. The only reason people talk about it now is everyone has a fetish over using simple software rather than designing software that works well.

And 'immutable practices' don't damage anything - they simply make things take longer, duplicate effort, make inefficient use of resources, and make everything generally more inflexible. The only benefit seems to be high level abstraction at the cost of everything else.

For Go, depending on your compile settings, you don't need to recompile. Go 1.5+ uses a pure Go DNS resolver [1], you have to force Go to use glibc. And even if you use glibc, it is not statically linked.

[0] https://golang.org/pkg/net/ (see "netdns" setting)

[1] https://go-review.googlesource.com/#/c/11584/

If you have dynamically linked libc (which you should), you only need to upgrade libc and restart all network processes. [Does anyone know if systemd in pid1 calls getaddrinfo? If so, this is another good reason for a minimal pid1, as you will need to reboot]

you need to restart all processes that might do a network address lookup. That's pretty much every daemon.

You don't need to reboot to restart systemd, you can run systemctl daemon-reexec

No reboot needed:

man systemctl

       daemon-reexec
           Reexecute the systemd manager. This will serialize the manager
           state, reexecute the process and deserialize the state again. This
           command is of little use except for debugging and package upgrades.
           Sometimes, it might be helpful as a heavy-weight daemon-reload.
           While the daemon is being reexecuted, all sockets systemd listening
           on behalf of user configuration will stay accessible.

Here's how to find packages on your system with statically linked applications (that probably use glibc):

  [root@server ~]# find /bin/ /sbin/ /usr/bin/ /usr/sbin/ /usr/lib* /usr/local/bin/ /usr/local/sbin/ /usr/local/lib* -type f -perm /u+x -exec file {} \; | grep statically | cut -d : -f 1 | xargs rpm -qf | sort -u
  busybox-1.2.0-7.el5.x86_64
  cryptsetup-luks-1.0.3-5.el5.i386
  cryptsetup-luks-1.0.3-5.el5.x86_64
  device-mapper-1.02.39-1.el5.i386
  device-mapper-1.02.39-1.el5.x86_64
  device-mapper-multipath-0.4.7-34.el5_5.1.x86_64
  dmraid-1.0.0.rc13-63.el5.x86_64
  dump-0.4b41-4.el5.x86_64
  e2fsprogs-1.39-23.el5.x86_64
  glibc-2.5-123.el5_11.1.i686
  glibc-2.5-123.el5_11.1.x86_64
  glibc-common-2.5-123.el5_11.1.x86_64
  grub-0.97-13.5.x86_64

... etc. And yes, it can be a lot of work. It's easier to only use your distro's official packages and update the patched ones they release. Luckily most software devs are smart and compile dynamically.

You patch glibc. Everything else is dynamically linking it.

I think it's possible to statically link glibc in Go, but I don't recall the particular compiler incantations offhand.

But go dynamically links against libc by default

Unless you statically link glibc, updating glibc is enough.

Reply on news.ycombinator.com