Re: inetd(8): cmdif as builtin

[tlaronde%polynum.com@localhost]

Le Fri, Jun 09, 2023 at 03:48:38PM -0400, Mouse a écrit :
> > Le Fri, Jun 09, 2023 at 08:47:10AM -0400, Mouse a écrit :
> 
> I find it amusing that it's "Fri, Jun 09, 2023 at 08:47:10AM -0400"
> rather than something like "ven, 09 jui 2023, a 08:47:10 -0400", when
> the surrounding text _is_ en français.

It's because my system is configured, mostly to run with the native
language: 'C'---that is not english... ;-)

> 
> >>> BTW; just an idea: in the case of inetd(8), wouldn't it be more
> >>> simple and logical, in this very case, to add a "cmdif" (cmd
> >>> interface) builtin?
> >> Simpler and more logical than what?
> > Emphasis: in the inetd(8) context.  [...]
> 
> Sure.  But what is it you're comparing a cmdif builtin to, what is it
> that it's simpler and more logical than?  Signals? My (hypothetical as
> far as inetd is concerned) pidconn?  Something else?
> 

Say it seems logical to me. I like the (almost defunct, it seems) idea
of a bootstrapping compiler: a rudimentary version easy to compile, but
that can then compiles itself with all the bells and whistles.

Here, inetd in fact using what it has to do to provide its own
interface.

> 
> >> The biggest difference I see between this and using signals to
> >> provoke these actions is the target namespace: filesystem names for
> >> AF_LOCAL or process IDs for signals.
> > More than this: you can pass parameters with signals.
> 
> I assume there's a negation missing there.

Yes: signals have no parameters. And there are few free, so they do the
job for what they were designed for, but they can not be extended.

>  Yes, this is part of the
> reason I built pidconn: signals use PIDs for their destination
> namespace, but are an extremely restricted communication channel,
> suitable for little more than a very few seldom-used commands.  I've
> got at least two programs that already use both SIGUSR1 and SIGUSR2
> (designed before I had pidconn).
> 
> > I'm still thinking (background process) about the subject you have
> > started in another thread (about a way to pass commands to a process
> > in a more broad way than what is allowed by signals).
> 
> I'd be interested in hearing any thoughts you may come up with.  I'm
> hardly wedded to pidconn; it's just the best alternative I came up with
> that looked sanely implementable.
> 
> In the particular case of inetd, I agree: its raison d'être is, as you
> say, to listen for network connections and do things in response to
> them, so, if a network connection is suitable for the purpose, an
> internal service is a good model.

For the moment, I always fall back to the basis: stdin, stdout and
stderr are linked, by default to the controling terminal and have
conventional numbers. Why no three other conventional numbers, that a
program could listen or write too and that could be connected via an
user level program, given only the pid of the process to contact.

The advantage of the Plan9 approach is that "anything is a file". So
such an interface appears as a file in the name space (say like
/proc/pid/ctl). That's simple.

> 
> > All in all, why daemon(3) or a variation of daemon(3) would not
> > change stdin and stdout to not be linked to the controlling terminal
> > but precisely to another interface that allows sending commands and
> > receiving results, and deferring error or logs via stderr?
> 
> That would certainly be possible.  But:
> 
> (1) I would not want this to be restricted to daemonized processes.
> 

No, not restricted to daemons (but I thought of daemons because it could
seem logical not to close the connections, but to redirect them; that
stdin, stdout and stderr be "plumbed" with something else than the
controling terminal (the "controling interface").

> I have at least two programs which export pidconn interfaces which have
> proven useful even when the processes are not daemonized (and neither
> of them is anything for which daemon() would even be appropriate,
> though one of has an option to auto-background itself by forking and
> the parent exiting).
> 
> In the particular case of inetd, I would want the management interface
> to be available even when running non-daemonized, such as for
> debugging.

Agreed.

> 
> (2) You'd still have to design the rendezvous mechanism, the thing you
> describe as just "another interface".

Whether a well defined name appearing in the name space (like the
/proc/pid/ctl) or an user level program "knowing" how to connect to
these channels based on the target pid?
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C