Le Wed, May 31, 2023 at 12:18:26AM +0700, Robert Elz a écrit :
> Date: Tue, 30 May 2023 16:11:55 +0200
> From: tlaro...@polynum.com
> Message-ID: <zhyek1xzzvzsu...@polynum.com>
>
> | The inclusion directive is a dot i.e. a here script:
>
> Definitely should not be called that, a "here xxx" is an xxx that is,
> obviously, here, not elsewhere. Something in another file is included,
> sourced, "dotted" if you like, but not "here". Of course this is just
> a minor terminology issue.
Yes, you are right: it is a slip of the keyboard.
Nonetheless this part will not go in the man page. It is simply to
answer a question I asked myself in the thread about the feature
of the "default address". I was proposing to limit the default
address to the scope of the file parsed at the moment. But this
would be inconsistent, since there is, in fact, only one file even
if bits are dotted from other files. So it will stay as it is
(but hence the necessity to validate the whole config since one error
could change the whole meaning of the config).
>
>
> | -c check a config file (and does not execute). Returns 0 on
> success and
> | ENOENT or EINVAL on error.
>
> If you mean what that seems to say, then no. The check only part is fine,
> but functions can return ENOENT or EINVAL (or can return -1, or NULL, or
> something with one of those in errno) - programs do not exit with those
> values as the status (as their values aren't specified, it is possible
> that ENOENT%256 (or ENOENT&0xFF if you prefer) == 0.
>
> You can either just exit with status 1, or exit 1 for file open failed
> (which covers a whole range of errno values, not just ENOENT), and 2
> for invalid contents if you prefer. But never use errno values as an
> exit parameter.
OK.
>
> The general outline looks OK to me, but if this happens, and is
> documented, try to be a little less long winded in the man page...
>
Don't worry: for the man page, I will limit myself to the addition
of the new options, a brief description of what they do and correcting
the descriptions of features changed (globbing now including in
lexicographical order; including the same file several times
legitimate as long as there is no loop; only regular files as
config chunks).
And a native english speaker will then have to review the result---preferably
reviewing the implementation in parallel to catch discrepancies.
> One possibility for the config files (and SIGUSR1 etc) might be to
> allow a list of config files (with a default list compiled in, possibly with
> one name as a fallback always appended to the list) and have
> SIGUSR1 move to the next on the list (in one direction) and SIGUSR2
> move to the next in the other direction (and SIGHUP just do a reload
> on whatever is being used currently, as it always has).
>
Yes this could be. But cycling through alternatives will cost more
time than to simply stop and restart with another config, or to
simply use a symbolic link for the config that can be changed (for
what it links to) at will and then asking to reload. I prefer to
keep it simple since the two main functions of this feature for me
are:
1) belt and suspenders---try to be sure to have at least some fundamental
services in case of wrong config;
2) reducing the level of service for some maintenance or due to
excessive load etc.
So I will limit myself to one defined fallback, which should provide
enough safety against a refuse to serve anything from an incorrect
config (if the administrator decides to use the feature; nothing will be
provided/served by default).
Do you think that SIGINFO is sound as the signal to obtain a config DUMP in
the syslog? (When checking, so even with -C, nothing is written via
syslog since, then, inetd is not a daemon but just an utility---a syntax
checker---printing messages on stdout or stderr and a inetd daemon could be
serving at the very same time: so don't spoil its log.)
--
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
