Re: [hackers] [quark] Rectify error-handling || FRIGN

From: FRIGN <>
Date: Mon, 11 Aug 2014 17:20:31 +0200

On Mon, 11 Aug 2014 16:54:40 +0200
"Roberto E. Vargas Caballero" <> 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:

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.



Received on Mon Aug 11 2014 - 17:20:31 CEST

This archive was generated by hypermail 2.3.0 : Mon Aug 11 2014 - 17:24:09 CEST