On Sat, Feb 22, 2014 at 9:28 AM, Andrew Savchenko <[email protected]> wrote: [snip] > And here we have a design issue. I already pointed this issue in this > discussion: > http://www.mail-archive.com/[email protected]/msg144144.html > Though it was completely ignored by you. I understand: it is easier > to discuss design in terms of taste than in technical merits.
I'm sorry, I was not part of that particular subthread. You are wrong anyway (see below) > Systemd assumes that time required to start service is small (at > microseconds scale). While this is true for widely used simple > setups, this is not true in general case. Service may take seconds or > even minutes to start up (good example are services depending on > enterprise SAN or large databases). Yeah; and systemd needs not to worry about that. The clients connecting have to. Set the clients to wait a reasonable time, and then everybody is happy. > And because systemd never assumes > it can take long time to start we have the following issues possible > in general case: > > 1. Client connections are lost due to timeout when service takes > long time to start. Systemd fakes service to be available while it > isn't still. Thus systemd is not an option for production grade > servers. Again, you can configure that on the clients. > 2. Even if connection timeout is not reached, requests may pale up and > be lost. Loss trigger depends on memory available, thus systemd is > not an option for both embedded setups and production server setups. You realize that if it's embedded, it makes no sense that it receives the godzillion connections necessary for the kernel queue to fill up? And on big iron, you can define the size of the queue; in the kernel, again, this has nothing to do with systemd. You don't even need to recompile your kernel. > As one can see, while systemd socket activation design will work for > many case, Glad to see you at least recognize this; but it can work for all cases. It doesn't have to, though (see below). > it will fail for corner ones and by no means can't be used > in production (where this corner cases have a high chance to rise). You evidently have no idea what are you talking about. First of all, as I said, the "problems" you mention are not problems at all, since slow starting services, by definition, have clients that need to cope with the slow starting (and if they don't, it's a bug in the clients); and because either you are embedded, and therefore you don't expect a godzillion connections, or you are medium size or big iron, and you set your queue size with a kernel knob to be as large as necessary. And secondly, even if those problems were real (which they are not), socket activation *IS OPTIONAL*. It's a feature that systemd supports, *if the admin wants to use it*. If you are in a corner case and you cannot change the timeout of your clients (because they are proprietary, for example), or you are constrained by memory (if you are embedded but anyhow want to handle gracefully a godzillion connections), THEN YOU DON'T USE SOCKET ACTIVATION. "Problem" solved. If you are *really* interested in learning about the advantages of socket activation, read [1]. However, I'm sure that you will not, as time and again in this thread you only have show that you are not even willing to do your homework before you start ranting against systemd; just like you did when you said that libsystemd.so was used in PID 1 [2] (which, of course, you conveniently ignored although I replied specifically to you). Therefore, I'm not going to waste more of my time arguing with someone who doesn't even read the proper documentation. I'm done with you in this thread. Regards. [1] http://0pointer.de/blog/projects/socket-activation.html [2] http://article.gmane.org/gmane.linux.gentoo.user/272840 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
