On Mon, Mar 14, 2022 at 04:24:23PM -0700, Arjun wrote:
>
> > My senior project group didn't get around to implementing
> > "pre-forking", so that should be interesting to implement! Here's what
> > Christos had
> > to say about it: "Means that once a preforked child is done you can
> > either wait
Robert Elz writes:
> So, add me to the list of people who'd like a "mount if possible"
> switch, with nothing more than a boot warning if some of them cannot
> be found at all, or have unfixable fsck issues.
Agreed - that would be great.
> I'd actually prefer even more - for most of those, if
On Mon, Mar 14, 2022 at 10:33:14PM +0700, Robert Elz wrote:
> Date:Tue, 15 Mar 2022 01:51:55 +1100
> From:Simon Burge
> Message-ID: <20220314145155.ec2bd...@thoreau.thistledown.com.au>
>
>
> | Do we have any valid need to have non-critical local filesystems?
>
> N
Brad Spencer writes:
>> But seriously, I think tsorting the filesystems is necessary, and then
>> there's putting filesystems into one of
>>
>> required
>> optional
>>
>> and then some sort of label for
>>
>> before-starting-networking
>> after-networking-before-daemons
>>
>> and so on.
>>> Here's what Christos had to say about it: "Means that once a
>>> preforked child is done you can either wait(2) for it and end it or
>>> you can put it back of the list of available processes so that it
>>> can handle more requests."
This sounds nonsensical to me.
>> Yeah, it does seem confus
I had another thought, which might very little work and make everybody
happy:
Add a variable zfs_critical, which if
yes: zfs mount -a happens in mountcritlocal
no: doesn't happen
and maybe
not set: zfs mount -a happens if root is zfs
I think I prefer the per-mou
Brad Spencer wrote:
> Simon Burge writes:
>
> > I'm using ZFS as my root filesystem, with the EFI boot loader reading
> > the kernel from the ZFS root filesystem. This is based on the the
> > FreeBSD libsa ZFS code. https://github.com/snarkophilus/src/tree/zfsboot
> > is this work, and I'm plann
On Tue, Mar 15, 2022 at 08:30:11AM -0400, Greg Troxel wrote:
> I still don't understand and object to this "zfs is special" notion.
It is special because it just does not use /etc/fstab (usually).
I don't like this part either, but we probably don't want to make our
ZFS different from others (or f
Martin Husemann writes:
> On Tue, Mar 15, 2022 at 08:30:11AM -0400, Greg Troxel wrote:
>> I still don't understand and object to this "zfs is special" notion.
>
> It is special because it just does not use /etc/fstab (usually).
> I don't like this part either, but we probably don't want to make o
> Then add an option to wait [...] to indicate that wait should complete
> if the [...] process enters stopped state
I guess "enters stopped state" includes the case where the process already was
in the stopped state when the wait command was issued?
> My inclination is to go that way, rather th
Brad Spencer writes:
> Martin Husemann writes:
>
>> On Tue, Mar 15, 2022 at 08:30:11AM -0400, Greg Troxel wrote:
>>> I still don't understand and object to this "zfs is special" notion.
>>
>> It is special because it just does not use /etc/fstab (usually).
>> I don't like this part either, but
Is it on purpose that sh's (at least, NetBSD-8's sh's) built-in printf doesn't
give a non-zero rc if the underlying write(2) fails (with EPIPE, in my case)?
It turns out that this
{ sleep 1; printf "Hallo" || echo "ERROR">&2; } | echo Foo
doesn't print "ERROR" with both sh and bash, whi
Oops, it looks like /usr/bin/printf will only exit non-zero because it receives
SIGPIPE. If called with SIGPIPE ignored, it will still exit 0.
On Tue, Mar 15, 2022 at 08:36:09AM -0400, Mouse wrote:
>
> This doesn't even make sense unless (a) you keep a separate list for
> each service, (b) the daemon is expecting this (and thus signals its
> doneness by some means other than exiting), (c) you invent some
> interface for passing each new
Date:Tue, 15 Mar 2022 16:48:09 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID:
| I guess "enters stopped state" includes the case where the process
| already was in the stopped state when the wait command was issued?
Yes, sequencing doesn't matter (though it
>>> [inetd reusing preforked processes after use]
>> This doesn't even make sense unless (a) you keep a separate list for
>> each service, (b) the daemon is expecting this (and thus signals its
>> doneness by some means other than exiting), (c) you invent some
>> interface for passing each new conn
Date:Tue, 15 Mar 2022 18:57:08 +0100
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID:
| Is it on purpose that sh's (at least, NetBSD-8's sh's)
| built-in printf doesn't give a non-zero rc if the underlying
| write(2) fails (with EPIPE, in my case)?
On purpose? N
On Wed, Mar 16, 2022 at 07:53:09AM +1030, Brett Lymn wrote:
> They wait on stdin, they don't need to signal done.
How does inetd replace their stdin once the connection is established?
Many deamons will do socket operations (e.g. querying the peer) early
on startup - that would fail (or deliver bo
18 matches
Mail list logo
