Le Tue, May 30, 2023 at 07:34:55PM -0400, Mouse a écrit :
> > But that's independent of the signal used to make it happen, [...]
>
> > Personally I'd probably pick a different signal for that, but I am
> > not sure which.
>
> I have long felt that having only two uncommitted signals (SIGUSR1 and
> SIGUSR2) is way too few.
>
> I've also long wanted a way to contact processes by PID. Something
> like sockets where addresses are process IDs.
>
> A while ago, I finally sat down to do something about that. I
> eventually came to the conclusion that sockets would not do, not
> because of any conceptual problem but simply because the internal
> infrastructure involved was incompatible with the design goals I had.
> (It's possible the socket API design _is_ incompatible with my design
> goals, but I found the internal issues before I became convinced of
> that.) So I added a new file descriptor type (well, semi-new; they're
> DTYPE_MISC) and a new syscall (pidconn) to do the analogs of
> socket+listen and socket+connect and a few other relevant things.
>
> The relevance to this thread is that the way I'd handle this is to give
> inetd a(n optional) pidconn listener via which it could be told to dump
> its config, either to the pidconn connection or to a file whose name is
> specified in the command.
>
> Assuming NetBSD isn't interested in going that far, perhaps it would be
> reasonable to have a config-file syntax which specifies a listening
> point (AF_LOCAL, AF_INET, AF_INET6, whatever) via which it could be
> similarly commanded?
In this area (as others, in fact), the Plan9 solution is quite elegant
(and consistent with the whole design): in the /proc/ directory, the
process has its directory /proc/$pid/, under which there is "ctl" file
to which one can write textual messages to control the process:
echo $cmd >/proc/$pid/ctl
For inetd(8), I will exhaust the spares (SIGUSR1 and SIGUSR2) and
instead of writing (for the dumping of the current config file) via
syslog, it will write to a file in /tmp (the config chunk being guarded
by comment sentries: "##CONFIG_BEGIN" and "##CONFIG_END") and the scheme
could be extended (not now) to write other infos as well (stats and so
on).
--
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
