I have an 82GB UFS image file (ufs-snapshot) mounted on some directory
ufs-snapshot.mount. (mount /dev/`mdconfig -a -t vnode -f ufs-snapshot`
ufs-snapshot.mount)
Command 'cp -R ufs-snapshot.mount/usr other-dir/' hanged in the middle
with DL+ status:
$ ps ax | grep cp
73635 10 DL+ 0:12.1
Hi,
I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and
working around it by claiming that our pthread library isn't "normal"
which uses standard signals rather then a signal thread.
My limited understanding of these facilities is however not enough to
see the actual problem
On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
> Hi,
>
> I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and
> working around it by claiming that our pthread library isn't "normal"
> which uses standard signals rather then a signal thread.
>
> My limited understanding of
On 4/11/2012 16:26, Ian Lepore wrote:
> On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
>> What happens is that SIGCHLD is never received by the signal thread and
>> the child processes turn to zombies. Signal counters never go up, not
>> even for SIGINFO, which I added specifically to see if
On Wed, Apr 11, 2012 at 08:26:13AM -0600, Ian Lepore wrote:
> On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
> > Hi,
> >
> > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and
> > working around it by claiming that our pthread library isn't "normal"
> > which uses standa
On Wed, 2012-04-11 at 17:47 +0300, Konstantin Belousov wrote:
> On Wed, Apr 11, 2012 at 08:26:13AM -0600, Ian Lepore wrote:
> > On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
> > > Hi,
> > >
> > > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and
> > > working around it
On 4/11/2012 16:47, Konstantin Belousov wrote:
> What happens, as I guess it, the SIGINFO and SIGCHLD are ignored, so
> kernel do not even bother to queue the signals to the master process.
> Register a dummy signal handler for your signals with sigaction
> before creating 'signal_handler' thread.
On Tue, 3 Apr 2012 14:27:43 -0700
Jerry Toung wrote:
> On 4/3/12, Gary Jennejohn wrote:
>
> > It would be interesting to see your patch. I always run HEAD but maybe
> > I could use it as a base for my own mods/tests.
> >
>
> Here is the patch
>
[patch removed]
Just for the archive my bad d
I created a PR for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=166851
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
The problem, IMHO, is none of this is in any way:
* documented;
* modellable by a user;
* explorable by a user (eg by an easy version of schedgraph to explore
things in a useful way.
Arnaud raises a valid point - he's given a synthetic benchmark whose
numbers are unpredictable. He's asking why. T
10 matches
Mail list logo
