Re: inetd(8): cmdif as builtin

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.

>>> 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?

Not that I disagree.  If you want to build a command line into inetd,
you'll need _some_ way to access it; short of an auxiliary tool that
plays games with ptrace() or its ilk, or pidconn, something like what
you suggest would be not only sensible but pretty close to necessary.
It doesn't _have_ to be an entry in the config file, but that is the
sanest way to design it I can think of offhand.

>> 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, 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.

> 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.

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.

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

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B