On Mon, 11 Aug 2014 16:54:40 +0200 "Roberto E. Vargas Caballero" <k...@shike2.com> wrote:
> Uhmmm, very stupid question ^^!!!, sorry for the noise. No problem. > Embedded devices with low memory. Instead of having all the servers running > (and almost of the time doing nothing), you can have only inetd that will > launch the server when it is needed. I know how small embedded devices can get, but ones with ethernet-controllers should at least have 8K of RAM. Quark linked against musl has the following idle-state in ps: PID USER PRI NI VIRT RES SHR S CPU% MEM% COMMAND 21500 nobody 20 0 232 104 80 S 0.0 0.0 ./quark As you can see, there's enough air to run at least a dozen quark-instances without getting any issues. On a technical note, opening and closing quark on demand can fail, given a socket stays in a TIME_WAIT-state after disconnection. So, if you restart quark, binding can fail and thus the whole inetd-idea doesn't make sense anymore. You can use the SO_REUSEADDR sock option, but that's a security issue. > I usually use inetd in my systems but for another reason, I can manage > them better (when you do a ps you see less noise), and I have all the > features of tcpd for free. I know that a lot of servers use tcpd > without be launched by inetd, but they are linked against the > library of tcpd and calls directly the code of tcpd. I think this > last way is not very Unix alike when you can use tcpd in any program > only using inetd. Both tcpd and inetd are not very UNIX-like in my eyes. If you want access-control, better look for a program which binds to a socket, does the checks and opens another socket you can bind quark to. Everything else, like including support for inetd in quark, is just an insult against the UNIX-philosophy. Cheers FRIGN -- FRIGN <d...@frign.de>
