On Mon, 11 Aug 2014 16:54:40 +0200
"Roberto E. Vargas Caballero" <k0ga_AT_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 <dev_AT_frign.de>
Received on Mon Aug 11 2014 - 17:20:31 CEST