Live data from Hacker News

Excellent succinct breakdown of the xz mess, from an OpenBSD developer

marc.info

51–54 of 54 posts

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#51

> It does not plausibly pass for a typo because no typical editing glitch will leave a '.' character there. I would certainly attribute that to a typo if I was reviewing the code.

"." repeats the last command in vim, so I'd consider it quite plausible as a typo, if we didn't know about the rest of the stuff.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#52
post #33
post #21

Earlier quoted context omitted.

> even though there are at least two other libraries that implement just the communication functionality and are actually designed for non-systemd programs to use. The important question is: if one of those libraries is used, and then something else pulls in `libsystemd`, will they conflict?

Why would they? There isn't any magic in libsystemd, its just a normal c lib

A lot of systemd-replacement shims try to be transparent, which means exporting the same symbols as the real systemd libs and thus causing weird conflicts if you link to the real systemd libs too.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#53
post #37
post #29

Earlier quoted context omitted.

This seems like a clear case of premature optimization. During the three decades sshd has existed I have never seen a real world situation where the equivalent of Type=exec was not enough. The time window where sshd is started and not yet ready to receive connections is short, and clients will have a connection timeout orders of magnitude larger. The notify functionality is more relevant for things like Java middlewa…

> The readiness is sent too early What makes you say that? The readiness notification is sent after the sshd has opened the listen socket, it literally is accepting connections at that point.

Accepting connections, yes, but for a client that is dependent on being able to establish ssh connections that is not enough. They would want to be notified on the ability to make successful connections.

Keep in mind that this is only a problem in special situations, almost no regular Linux servers carry any services that care about being able to establish ssh connections, that cannot reconnect and use appropriate socket options. For other services than ssh, such as databases, this is much more common. And for those, it is not enough that the server has opened a listening socket.

When building distributed systems, this is something you need to think about. Not so such with local systems. But the same principles apply. And the only robust way is to poll for readiness. Signalling readiness is both complex, when the dependency chains are non-trivial, and prone to error, when readiness signals arrive out of order or are dropped or fail for some reason. This could be because of operations failure but make for hard to debug cases. Dependency chains that mysteriously stop because of permission problems with out of band traffic is both classic and unnecessary problem.

All of this complexity go away when polling. This is why you should adopt this design in the somewhat unlikely case you have clients that depend on being able to make ssh connections.

Post reply on HN