undefined | Better HN

0 pointscbsmith11y ago0 comments

> The original question I replied to was about why pipes (or any OS-level IPC) shouldn't try to solve application-level problems.

That maybe what you read, but the context of drdaemon's statement was specifically in response to a question about communications with the init daemon, and of course everything I said after was as well... Glad we got that settled.

> Not the IPC system's responsibility.

Hmm... IPC systems need to have ways of matching up the parties in a conversation, and having one where you don't have to enforce who calls whom first and parties don't have to mutually agree upon the specific endpoints in advance sure seems like something an IPC system might want to have... particularly one employed in an init system...

As discussed here: http://0pointer.de/blog/projects/systemd.html

There absolutely is a ton of overlap between what systemd does with socket activation and what Xinetd has evolved to... but as with evenone else doing OS design, there comes a point where you leave Xinetd behind and let the full potential of that trick work in your favour.

> Now you're just being daft :)

Me and the folks at Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_data_serializatio...

Don't get me wrong, I think a lot of the Wikipedians are pretty daft, but they are as reasonable a judge of human readability as I can imagine, given what they do.

> CORBA is the old shiny ;)

CORBA is the old shiny-my-god-we-dont-need-nearly-all-of-that-and-it-really-benefits-a-bootstrapped-systems-so-there-is-a-chicken-and-egg-prolem-here. But yeah, close. I don't think anyone has seriously considered that since the OS/2 & Workplace OS days... and even then.

That said, I would say that THESE DAYS (unlike in its heyday), CORBA is a pretty awesome robust, feature rich _general purpose_ distributed IPC system.

> Of course--you use a library and an RPC stub generator for this.

Ah, so it is much more modularized if it runs as an executable piece of code in process than a piece of executable code out of process. Got it. ;-)

> Not really part of the "design principles of IPC" discussion we've got going, though.

Well, that's the discussion you're having. I'm trying to talk about the design constraints and appropriate solutions for the problem domain...

0 comments

2 comments · 1 top-level

jude-11y ago· 1 in thread

> As discussed here: http://0pointer.de/blog/projects/systemd.html

Lennart Poetterring claims that you should use his software instead of someone else's software! I'm SHOCKED! Full story at 11.

Seriously now, did you honestly think that he would say to use xinetd over systemd? Do you honestly believe a developer will advocate the use of a competing piece of software over something (s)he produced?

> There absolutely is a ton of overlap between what systemd does with socket activation and what Xinetd has evolved to... but as with evenone else doing OS design, there comes a point where you leave Xinetd behind and let the full potential of that trick work in your favour.

Unless you don't feel like replacing small, simple, easy-to-use, well-tested xinetd with the 200K-line pile of C code that is systemd.

Besides, I've got your socket activation right here: Start the daemon, have the daemon open a port, and let the kernel swap it to disk. The kernel will swap it back in when it receives a connection for it.

Benefits:

* the daemon preserves state between "activations" for free

* the kernel gives you this feature for free

Security:

* the daemon doesn't have to trust another userspace program with anything

* the daemon can use mlock() to prevent sensitive pages from getting swapped

* if this isn't enough, you can encrypt the swap partition to resist offline attacks

Resources:

* If disk is too expensive, disk is read-only, you have no swap, you have no CAP_IPC_LOCK, the daemon would need to mlock() too much RAM, and you can't encrypt your swap, there's xinetd.

* Need to apply filters or QoS controls on connections before waking up the daemon? That's what the firewall is for.

Trivia:

* You can have xinetd trigger whatever event you want, since all it does is fire up a program and run it. This includes alerting other programs, like a service manager, that it got a connection, and maybe even sending along the message (or the file descriptor) if you want. There is no need for systemd to subsume this responsibility.

As you can see, "socket activation" is by and large a marketing gimmick.

> Me and the folks at Wikipedia:...

You think an article that compares data serialization protocols somehow proves your ludicrous claim that human readable text is less readable than marked-up text? Maybe daft was too nice a word...

> Ah, so it is much more modularized if it runs as an executable piece of code in process than a piece of executable code out of process. Got it. ;-)

Sir/madam, have you ever written an Internet-facing daemon? Obviously the bulk of the RPC logic lives in a shared library. You know, a logically distinct module that can be independently installed, loaded once, and independently maintained.

Besides, procedurally-generated RPC-handling code adds no technical debt to your project, anymore than the compiler's generated assembler output does.

You seem to want to replace the RPC shared library with a separate process. Not only will this make create a performance bottleneck, but also it makes it a single point of failure. If it crashes, all your daemons lose their connections. This is obviously highly undesirable, especially on servers.

> Well, that's the discussion you're having. I'm trying to talk about the design constraints and appropriate solutions for the problem domain...

I think I'm done with you. You deserve everything systemd will ever do for you.

cbsmithOP11y ago

> Seriously now, did you honestly think that he would say to use xinetd over systemd?

No... but I thought he might be able to pretty adequately explain how systemd exploits socket activation and contrast it with xientd....

> Do you honestly believe a developer will advocate the use of a competing piece of software over something (s)he produced?

Well, I've certainly done it, so it is possible, but I wasn't referencing him as a persuasive voice... Even if I was, that'd be such a flawed and pathetic argument...

> Unless you don't feel like replacing small, simple, easy-to-use, well-tested xinetd with the 200K-line pile of C code that is systemd.

You might want to look at the code. The socket activation logic is a pretty clean & tight ~90K chunk of code in a handful of files... and for the record, xinetd isn't that slim, with nearly 25K lines of code spead over well over a hundred files, and that's if you only count the C source files.

> As you can see, "socket activation" is by and large a marketing gimmick.

Sigh... I can see you didn't read the article. The implementation differences aren't terribly different, and Lennart already made your points for you... Systemd does have some little tweaks that open up a bunch of different worlds of advantages.

> Sir/madam, have you ever written an Internet-facing daemon?

Yes, but of course, in this context we're primarily focused on AF_UNIX sockets...

> Obviously the bulk of the RPC logic lives in a shared library. You know, a logically distinct module that can be independently installed, loaded once, and independently maintained.

it's very common, for example, for web apps to have a separate process that parses and validates inbound HTTP requests RESTful requests before passing them on to the main application process. You can and do run web apps that are directly exposed to the Internet, but nobody suggests this is to make the request processing logic more modular...

> You seem to want to replace the RPC shared library with a separate process. Not only will this make create a performance bottleneck, but also it makes it a single point of failure. If it crashes, all your daemons lose their connections. This is obviously highly undesirable, especially on servers.

I see you are familiar with Erlang. ;-)

You raise a good point. Often to reduce failure rates people employ load balancer that work with various HA protocols to avoid losing connetions. What do load balancers do again? Oh yeah, they are separate processes receive in bound RPC requests, parse and validate them, attempt to mitigate any in bound attacks before routing and forwarding them to the application itself...

And of course, a lot of web applications are largely front ends to a database, which means they themselves are processing RPC requests, formatting, validating and transforming them before forwarding them to a database for execution...

..and let's not get started about middleware... ;-)

> You seem to want to replace the RPC shared library with a separate process.

No. I really don't. I'm just pointing out that if you are looking for small, modular and loosely coupled components that are fairly resilient, it's not like someone is going to say that moving a component form a shared library to a separate process is going to get critiqued on the basis that it intrinsically makes for more tightly coupled code.

Or wait, are you suggesting that systems where all these libraries are rolled up in to one process would be more modular? [looks at critique of how systemd puts too much stuff in to one process...]

j / k navigate · click thread line to collapse