Le Fri, Jun 02, 2023 at 10:59:04PM +0200, Rhialto a écrit :
> On Wed 31 May 2023 at 00:18:26 +0700, Robert Elz wrote:
> > Date:Tue, 30 May 2023 16:11:55 +0200
> > From:tlaro...@polynum.com
> > Message-ID:
> >
> >
> > | -c check a config file (and does not exec
On Wed 31 May 2023 at 00:18:26 +0700, Robert Elz wrote:
> Date:Tue, 30 May 2023 16:11:55 +0200
> From:tlaro...@polynum.com
> Message-ID:
>
>
> | -ccheck a config file (and does not execute). Returns 0 on
> success and
> | ENOENT or EINVAL on error.
>
Le Fri, Jun 02, 2023 at 07:35:54AM +0930, Brett Lymn a écrit :
> On Thu, Jun 01, 2023 at 09:08:52AM +0200, tlaro...@polynum.com wrote:
> >
> > But for now, it will be far simpler to only modify the NetBSD source
> > without trying to merge something external.
> >
>
> It isn't external - the mods
On Thu, Jun 01, 2023 at 09:08:52AM +0200, tlaro...@polynum.com wrote:
>
> But for now, it will be far simpler to only modify the NetBSD source
> without trying to merge something external.
>
It isn't external - the mods were made to the NetBSD source code.
--
Brett Lymn
--
Sent from my NetBSD
Le Thu, Jun 01, 2023 at 12:50:30PM +0930, Brett Lymn a écrit :
> On Wed, May 31, 2023 at 12:43:40PM +0200, tlaro...@polynum.com wrote:
> >
> > And I think you're right: the info will go in a 0400 file in /tmp, and
> > will be a way to obtain various running infos---but for now, just the
> > runnin
On Wed, May 31, 2023 at 12:43:40PM +0200, tlaro...@polynum.com wrote:
>
> And I think you're right: the info will go in a 0400 file in /tmp, and
> will be a way to obtain various running infos---but for now, just the
> running config (it could perhaps be extended, but not now, to add
> stats, what
Le Wed, May 31, 2023 at 09:57:00PM +1000, Luke Mewburn a écrit :
> This isn't a NetBSD convention per se, although I could write up in
> more detail the conventions we do use and pass them around separately
> for consideration/refinement for NetBSD services/daemons.
Yes, please. It would be worth
So I added a new file descriptor type (well, semi-new; they're
DTYPE_MISC) and a new syscall (pidconn) [...]
>>> In this area (as others, in fact), the Plan9 solution is
>>> [/proc/$PID/ctl]
>> That is unidirectional communication. pidconn is bidirectional.
>> Aside from that, how does t
Le Wed, May 31, 2023 at 08:16:52AM -0400, Mouse a écrit :
> > The inclusion directive is a dot i.e. a here script:
>
> Well, as I think someone else pointed out, I wokuldn't call that a here
> script. sh spells it ".", csh spells it "source", but here script is
> more often used for "<<" style in
Le Wed, May 31, 2023 at 07:50:03AM -0400, Mouse a écrit :
> >> So I added a new file descriptor type (well, semi-new; they're
> >> DTYPE_MISC) and a new syscall (pidconn) [...]
>
> > In this area (as others, in fact), the Plan9 solution is quite
> > elegant (and consistent with the whole design):
Le Wed, May 31, 2023 at 09:57:00PM +1000, Luke Mewburn a écrit :
> On 23-05-31 13:12, tlaro...@polynum.com wrote:
> | > Also, on 23-05-30 21:03, tlaro...@polynum.com wrote:
> | > | (When checking, so even with -C, nothing is written via
> | > | syslog since, then, inetd is not a daemon bu
> The inclusion directive is a dot i.e. a here script:
Well, as I think someone else pointed out, I wokuldn't call that a here
script. sh spells it ".", csh spells it "source", but here script is
more often used for "<<" style input, input that's inline, which an
included file by definition is no
>> So I think when using inetd in check mode, it is an utility and the
>> config will go to stdout, and the errors about the parsing to stderr
>> [...]
> IMHO, if check + -f foreground; errors to stdout/stderr,
> and if check + (background default); output to syslog.
I see no particular use for d
On 23-05-31 13:12, tlaro...@polynum.com wrote:
| > Also, on 23-05-30 21:03, tlaro...@polynum.com wrote:
| > | (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 st
On 23-05-31 12:43, tlaro...@polynum.com wrote:
| And I think you're right: the info will go in a 0400 file in /tmp, and
| will be a way to obtain various running infos---but for now, just the
| running config (it could perhaps be extended, but not now, to add
| stats, what is masked by a se
>> So I added a new file descriptor type (well, semi-new; they're
>> DTYPE_MISC) and a new syscall (pidconn) [...]
> 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/
Le Wed, May 31, 2023 at 01:12:12PM +0200, tlaro...@polynum.com a écrit :
>
> But inetd used in check mode is probably to try to validate a candidate
> config in the current process to be written.
My english is definitively not very good: inetd in check mode is
probably used to try a config that i
Le Wed, May 31, 2023 at 08:42:11PM +1000, Luke Mewburn a écrit :
> On 23-05-31 03:54, Robert Elz wrote:
> | Date:Tue, 30 May 2023 21:03:21 +0200
> | From:tlaro...@polynum.com
> | Message-ID:
> |
> | | Do you think that SIGINFO is sound as the signal to obt
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
Le Wed, May 31, 2023 at 03:54:12AM +0700, Robert Elz a écrit :
> Date:Tue, 30 May 2023 21:03:21 +0200
> From:tlaro...@polynum.com
> Message-ID:
>
> | Do you think that SIGINFO is sound as the signal to obtain a config DUMP
> in
> | the syslog?
>
> First, dumping
On 23-05-31 03:54, Robert Elz wrote:
| Date:Tue, 30 May 2023 21:03:21 +0200
| From:tlaro...@polynum.com
| Message-ID:
|
| | Do you think that SIGINFO is sound as the signal to obtain a config
DUMP in
| | the syslog?
|
| First, dumping config to s
> 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 proce
Date:Tue, 30 May 2023 21:03:21 +0200
From:tlaro...@polynum.com
Message-ID:
| Do you think that SIGINFO is sound as the signal to obtain a config DUMP in
| the syslog?
First, dumping config to syslog seems like an odd thing to do at all, I'd
normally expect it to
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:
>
> | The inclusion directive is a dot i.e. a here script:
>
> Definitely should not be called that, a "here xxx" is an x
Date:Tue, 30 May 2023 16:11:55 +0200
From:tlaro...@polynum.com
Message-ID:
| 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 in
After a little reflection, here are the proposed changes to inetd(8):
THE CONFIGURATION
There is only one configuration file given by a path---whether on the
command line or defaulting to "/etc/inetd.conf".
The inclusion directive is a dot i.e. a here script: there are n
26 matches
Mail list logo
