> 1) This method of handling recursive nodump is far superior to any actual
>inheritence of the flag as part of file system operations, as currently
>no other file flags are inherited from the parent directory -- the only
>property that is inherited is the group. With ACLs, the parent
Chris Shenton wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
>
> > We have several NIC's around here (the New Internet Computer, see
> > http://www.thinknic.com/ for details) and will be adding a couple of these
> > so we can boot FreeBSD or NetBSD on them in the next little while.
On 26 Feb 2001 18:56:18 +0100, Matt Dillon <[EMAIL PROTECTED]> wrote:
> Ha. Right. Go through any piece of significant code and just see how
> much goes flying out the window because the code wants to simply assume
> things work. Then try coding conditionals all the way through to f
Dan Phoenix wrote:
>
> httpd in free(): warning: recursive call.
What FreeBSD/apache versions is this with? I've seen the same on
FreeBSD-3.4 and an older apache build from ports. Haven't (yet) seen it
under 4.2 and the latest apache from ports.
--
Lars Eggert <[EMAIL PROTECTED]>
If the first program calls open(2) before the second one calls
close(2) the former will not block because there's already a writer on
the pipe. A possible workaround would be to unlink and recreate the
fifo in program one, like so:
for (;;)
{
int fifo;
I did not specify a lock directive in httpd.conf.
Default my httpd is in /usr/local/apache
i would assume lock file is going there which is an ide drive.
> Date: Mon, 26 Feb 2001 17:57:03 -0800 (PST)
> From: Doug White <[EMAIL PROTECTED]>
> To: Dan Phoenix <[EMAIL PROTECTED]>
> Cc: [EMAIL PR
In message <[EMAIL PROTECTED]>, Tony Finch writes:
>fork() with big data segments that cause swap to be reserved in case
>of a copy-on-write. The 2GB of swap is never actually used, but you
>still have to have it.
That's a good point. So, we should warn people that asking for memory
committments
On Mon, 26 Feb 2001, Dan Phoenix wrote:
>
>
>
> [Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by
> peer: getsockname
> [Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file
> descriptor: flock: LOCK_EX: Error getting accept lock. Exiting!
> [Mon Feb 26 13:04:39 2001] [alert] Child 777 retur
hello!
I'm running into a problem with some threading using pthreads in an
application i'm writing for FreeBSD.
The application basically
1. initializes some UI goo (but doesn't start any of it UP) using a
GUI framework (Qt)
2. creates a FIFO, and then spawns a thread
3
Exact same config on other webservers wtih really low cpu.
Memory checks out fine. Mysql connection to db checks out fine.
IO is fine...running out of ideas.
tcpdump returns alot of these
15:19:53.383597 elrond.sf.bravenet.com.shivahose >
drago.sf.bravenet.com.telnet: . ack 6212 win 17
Soren Schmidt <[EMAIL PROTECTED]>, said on Mon Feb 26, 2001 [09:10:43 PM]:
} It seems Stephen Rose wrote:
} > A couple of us on the questions list have asked for a way to spin down ide
} > disks when idle. Is there any chance that this utility could lead to
} > something useful there?
}
} Well,
:
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive call.
:httpd in free(): warning: recursive c
No, there isn't. They have a CVS to Perforce script, not Perforce to CVS
(please don't ask who in their right mind would want to go from Perforce to
CVS :)
Well, if Anton doesn't respond, I guess I'll just have to write one
myself...
John
On Sun, 25 Feb 2001 22:00:31 -0600, Michael C . Wu wr
(owner-freebsd-hackers removed from list)
:You're implying that you are making two calls to create the same
:directory. Am I correct?
:
:The answer is 'maybe'? Depends on the remote NFS server. Matt or one
:of the other NFS gurus may know more, but I wouldn't count on *anything*
:over NFS
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>Rationale:
>SIGSEGV for _user_ mistakes (process accesses wrong stuff)
>SIGBUS for _system_ errors (ECC error, kernel messes up, ...)
Actually, this is not canonically the distinction made. On a Unix PC,
{
int *a, c[
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>I don't think a failed kernel-level allocation after overcommit
>should generate a segfault.
>IMHO it should send a bus error (or a sigkill if the process
>doesn't exit after the SIGBUS).
Same difference, so far as the language is concerned.
On Mon, 26 Feb 2001, Peter Seebach wrote:
> In message <[EMAIL PROTECTED]>,
> >And maybe, just maybe, they'll succeed in getting their
> >idea of non-overcommit working with a patch which doesn't
> >change dozens of places in the kernel and doesn't add
> >any measurable overhead.
>
> If it adds ov
> "Peter" == Peter Seebach <[EMAIL PROTECTED]> writes:
Peter> Well, imagine a hypothetical broken system in which two
Peter> simultaneous calls to mkdir, on some hypothetical broken
Peter> filesystem, can each think that it "succeeded". After all,
Peter> at the end of the ope
> In message <[EMAIL PROTECTED]>, Mike Smith writes:
> >How would it *not* be atomic?
>
> Well, imagine a hypothetical broken system in which two simultaneous calls
> to mkdir, on some hypothetical broken filesystem, can each think that it
> "succeeded". After all, at the end of the operation, t
> "Daniel" == Daniel C Sobral <[EMAIL PROTECTED]> writes:
Daniel> Dag-Erling Smorgrav wrote:
>> > > None of these solutions are portable, however; > Well, no, but
>> the sole available definition of "portable" says that it is >
>> "portable" to assume that all the memory malloc can return is
Well, for me it's the noise and heat that I'm trying to minimize. That
and we're out of power here in California. :-)
Steve Rose
On Mon, 26 Feb 2001, Soren Schmidt wrote:
> It seems Stephen Rose wrote:
> > A couple of us on the questions list have asked for a way to spin down ide
> > disks w
> > > I can handle it if there is a case where both fail, but is
> there a
> > > case where both can SUCCEED ??
> >
> > What do you mean 'both succeed'?
>
> My understanding is that, on non-broken filesystems, calls to
> mkdir(2) either succeed by creating a new directory, or fail and r
> >
> > I can handle it if there is a case where both fail, but is
there a
> > case where both can SUCCEED ??
>
> What do you mean 'both succeed'?
My understanding is that, on non-broken filesystems, calls to
mkdir(2) either succeed by creating a new directory, or fail and return
EEX
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>How would it *not* be atomic?
Well, imagine a hypothetical broken system in which two simultaneous calls
to mkdir, on some hypothetical broken filesystem, can each think that it
"succeeded". After all, at the end of the operation, the directory
> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
> :
> >is mkdir(3) guaranteed to be atomic?
>
> Yes.
Um. mkdir(2) is atomic. Note that mkdir(1) with the -p argument is
*not* atomic.
> >Are there filesystem type cases where this might not be the case
> >(NFS being my main co
> > > >Are there filesystem type cases where this might not be the case
> > > >(NFS being my main concern )
> > >
> > > No.
> >
> > Yes. NFS doesn't guarantee atomicity, because it can't. If the
> mkdir
> > call returns, you have no guarantee that the remote directory has
> been
> > creat
> -
> From: Nate Williams <[EMAIL PROTECTED]>
> > >Are there filesystem type cases where this might not be the case
> > >(NFS being my main concern )
> >
> > No.
>
> Yes. NFS doesn't guarantee atomicity, because it can't. If the
mkdir
> call returns, you hav
> >is mkdir(3) guaranteed to be atomic?
>
> Yes.
>
> >Are there filesystem type cases where this might not be the case
> >(NFS being my main concern )
>
> No.
Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir
call returns, you have no guarantee that the remote d
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
:
>is mkdir(3) guaranteed to be atomic?
Yes.
>Are there filesystem type cases where this might not be the case
>(NFS being my main concern )
No.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers
> "Matt" == Matt Dillon <[EMAIL PROTECTED]> writes:
[... my newfw bomb deleted ...]
Matt> Heh heh. Yes, newfs has some overflows inside it when you
Matt> get that big. Also, you'll probably run out of swap just
Matt> newfs'ing the metadata, you need to use a larger block size,
Matt> la
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
httpd in free(): warning: recursive call.
[Mon Feb 26 13:04:34 2001] [error] (54)Connection reset by
peer: getsockname
[Mon Feb 26 13:04:39 2001] [emerg] (9)Bad file
descriptor: flock: LOCK_EX: Error getting accept lock. Exiting!
[Mon Feb 26 13:04:39 2001] [alert] Child 777 returned a Fatal error...
Apache is exiting!
httpd in free():
hello!
I've got a program that creates a named pipe, and then spawns a
thread
which sits in a loop:
// error checking snipped.
//
while (1) {
int fifo = open(fifoPath, O_RDONLY); // this blocks
fprintf(stderr, "somebody opened the other end!\n");
read(fi
hi!
i can never really tell if this alias is for discussions concerning
development OF the FreeBSD OS or development ON the FreeBSD OS (or
both), but I figure i'll risk the wrath of the anti-social and ask a
coupla programming questions :-)
is mkdir(3) guaranteed to be atomic? Thus,
Does anyone have any real world experience with the upper performance end
of freebsd based routers?
Specifically, I'm wondering if the Znyx ZX374 card with its 66MHz bus is
really worth twice the money of the adaptec Quartet64 board with a 33 MHz
64 bit bus. The intended mobo for it would be a t
It seems Stephen Rose wrote:
> A couple of us on the questions list have asked for a way to spin down ide
> disks when idle. Is there any chance that this utility could lead to
> something useful there?
Well, of cause it could, but I'm not sure I see the usefullness of
the spindown at all, a spi
In message <[EMAIL PROTECTED]>,
>And maybe, just maybe, they'll succeed in getting their
>idea of non-overcommit working with a patch which doesn't
>change dozens of places in the kernel and doesn't add
>any measurable overhead.
If it adds overhead, fine, make it a kernel option. :)
Anyway, no
On Tue, 27 Feb 2001, Daniel C. Sobral wrote:
> Matt Dillon wrote:
> > :Matt Dillon wrote:
> > :>
> > :..
> > :> the system runs out of memory, even *with* overcommit protection.
> > :> In fact, all sorts of side effects occur even when the system
> > :...
> > :
> > :That's an assumption.
>
Greetings,
I'm interested in using mmap() with MAP_STACK. After writing a couple of
test programs and looking at vm_map_insert() and vm_map_stack(), it
appears that vm_map_stack() behaves as if MAP_FIXED were set.
Why is this? I would like to allocate stack space without having to
search for a
On Sun, 25 Feb 2001, Matt Dillon wrote:
> The problem is a whole lot more complex then you think. Dealing with
> overcommit is not simply counting mapped pages, there are all sorts
> of issues involved. But the biggest gotcha is that putting in
> overcommit protection will not a
In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes:
>Anyway, these are two very different situations, and comparing them is
>silly.
They are situations in which an application can be killed and has no way
to detect that it is about to do something wrong, and in which there *was*
a correct
:> :...
:> :
:> :That's an assumption.
:>
:> Ha. Right. Go through any piece of significant code and just see how
:> much goes flying out the window because the code wants to simply assume
:> things work. Then try coding conditionals all the way through to fix
:> it... and don
Matt Dillon wrote:
>
> :Matt Dillon wrote:
> :>
> :..
> :> the system runs out of memory, even *with* overcommit protection.
> :> In fact, all sorts of side effects occur even when the system
> :...
> :
> :That's an assumption.
>
> Ha. Right. Go through any piece of significant cod
Peter Seebach wrote:
>
> It's odd that I see lots of people arguing for segfaults killing the process
> accessing memory that has been "successfully" allocated, but no one arguing
> for the process getting killed when it exceeds a disk quota.
Disk quote is an artificial limit. If you remind each
A colleague of mine has reported the necessity of adding this patch to
if_fxp.c to support 802.1q vlans. I must admit that I am not familiar
enough with the vlan code to understand what good this does. This patch
is against 4.1-RELEASE. If it is a good thing, I would like to add it to
-curren
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> This has nothing to do with overcommit in the context it is being
> discussed. In fact, this has nothing to do with OS memory management
> at all -- all garbage collected languages have their own infrastructure
> to determine when memo
>
> I still think that in such a case it should be possible to
> 'test the commitment' by touching all the allocated memory
> while trapping page faults. and fault all your memory from
> 'potential' to 'allocated'. As someone said. it is not sure which program
> when you run out of swap, but I
:Matt Dillon wrote:
:>
:..
:> the system runs out of memory, even *with* overcommit protection.
:> In fact, all sorts of side effects occur even when the system
:...
:
:That's an assumption.
Ha. Right. Go through any piece of significant code and just see how
much goes flying
In message <[EMAIL PROTECTED]>, Nate Williams writes
:
>Again, memory overcommit is only *one* class of bugs that is avoided.
>The phrase "can't see the forest for the trees" jumps to mind. :)
Sure, and likewise, bugs in libc are only one *class* of bugs we can avoid,
but that doesn't mean we don
> >Even in this case, there's no way to prove your code is not going to
> >crash.
>
> Sure. But you can at least prove that all crashes are the result of bugs,
> not merely design "features".
'Proving' something is correct is left as an excercise for the folks who
have way too much time on thei
In message <[EMAIL PROTECTED]>, Nate Williams writes
:
>Even in this case, there's no way to prove your code is not going to
>crash.
Sure. But you can at least prove that all crashes are the result of bugs,
not merely design "features". From the point of view of proving that a
system is designe
[ Memory overcommit ]
> One important way to gain confidence that you're little box won't
> silently crash at the worst possible time for the customer is to
> be able to *prove* to yourself that it can't happen, given certain
> assumptions. Those assumptions usually include things like "the
> har
A couple of us on the questions list have asked for a way to spin down ide
disks when idle. Is there any chance that this utility could lead to
something useful there?
Steve Rose
It seems Scott Renfro wrote:
> As I promised on -mobile earlier this week, I've cleaned up my patches
> to port the
In message <[EMAIL PROTECTED]>,
Rik van Riel writes:
>> No, I just disagree. It is useful for the OS to provide a hook for
>> memory which is *known to work* - and that is the environment C specifies.
>Send patches.
I may some day. It's not very high on my priority list; I'd probably try to
f
On Sat, 24 Feb 2001, Peter Seebach wrote:
> In message <9820.983050024@critter>, Poul-Henning Kamp writes:
> >I think there is a language thing you don't understand here.
>
> No, I just disagree. It is useful for the OS to provide a hook for
> memory which is *known to work* - and that is the env
I won't have a chance to look at the patch below until later this week,
but had two comments--
1) This method of handling recursive nodump is far superior to any actual
inheritence of the flag as part of file system operations, as currently
no other file flags are inherited from the parent
On Mon, Feb 26, 2001 at 08:28:56AM +0100, Soren Schmidt wrote:
>
> No its not safe at all, you risk trashing an already running command...
Thanks for the feedback; that's exactly what I was concerned about.
> Anyhow, I have an atacontrol thingy in the works for attach/detach,
> raid control etc
On Wed, Feb 21, 2001 at 10:44:42AM -0800, Peter Wemm wrote:
> >
> > There's a problem here. I tried to configure an SMP kernel but when it
> > booted the fxp0 (Compaq dual eepro100 adapter) got timeout errors and
> > wouldn't work. I went back and did the config/make on the GENERIC
> > kernel a
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>The problem is a whole lot more complex then you think. Dealing with
>overcommit is not simply counting mapped pages, there are all sorts
>of issues involved. But the biggest gotcha is that putting in
>overcommit protection wil
In message <[EMAIL PROTECTED]>, Julian Elischer writes:
>I still think that in such a case it should be possible to
>'test the commitment' by touching all the allocated memory
>while trapping page faults.
And what do you do if you get one? There's no undo button for SIGSEGV.
Traditionally, you
Hello -hackers
Some time ago, on -arch, phk proposed that the nodump flag should be
inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000).
This was generally considered a good idea, however, the patch to the
kernel he proposed was thought an ugly hack. In addition, jeroen
pointed out
61 matches
Mail list logo
