On Thu, 1 Mar 2018 15:53:46 +0200
Alexander Kanavin wrote:
> toomanyfiles.patch rebased
Do we still have a reason for that, if we're using epoll to address
that?
That said, with the new fastop sanity-fix, that is probably much less
dangerous than it used to
Dropped patches:
0001-Use-epoll-API-on-Linux.patch replaced by
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/commit/?id=0a3e435085046f535074f498a3de75a7704fb14c
(also add --enable-epoll to configure options)
b6b68db896f9963558334aff7fca61adde4ec10f.patch merged upstream
On Mon, 19 Feb 2018 20:01:31 +0100
Martin Jansa wrote:
> I did quick check for UID/GID issue:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
Hmm. glibc-locale, in particular, is a really weird case; does it still
do the strange thing with copying the files
I've bumped SRCREV to include your latest fix and re-enabled epoll and now
it doesn't get stuck for me, thanks!
I did quick check for UID/GID issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
without epoll disabled and SRCREV "b6a015a Handle O_TMPFILE more better" it
was still
On 02/19/2018 07:55 PM, Seebs wrote:
This gets back to "and one of the problems with testing is that
if I don't actually check the logs, I often don't see problems",
because pseudo does enough internal disaster recovery that things can
explode horribly without observable failures.
Now
On Mon, 19 Feb 2018 11:27:56 +0200
Alexander Kanavin wrote:
> > Huh. It's possible that the initial "don't try to close fd 0" was
> > correct, and the real problem is that the attempt is getting made
> > mistakenly. I'll study that more; the epoll code was a
On 02/18/2018 10:23 PM, Martin Jansa wrote:
==> update-rc.d/0.7-r5/pseudo/pseudo.log <==
debug_logfile: fd 2
pid 8488 [parent 8481], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 8481.
tried to close client 0 (highest is 1)
tried to close client 0 (highest is 1)
On 02/17/2018 10:17 PM, Seebs wrote:
For me, with epoll enabled:
b6a015a works
23f089f and 26e30fa both lock up
Huh. It's possible that the initial "don't try to close fd 0" was
correct, and the real problem is that the attempt is getting made
mistakenly. I'll study that more; the epoll code
I've tried again with the change from Alex (without additional SRCREV bump)
on ubuntu-14.04
To make it simple I've triggered the build of just to recipes (which caused
"tried to close client 0 (highest is 1)" before:
$ bitbake tzdata update-rc.d
and again I quickly got:
23G
The do_install tasks failing with exit code '134'/SIGABRT were caused by
left over pseudo processes from previous builds still holding the
pseudo.lock.
Manually killing those (still spinning at around 90% CPU for last 2 days)
resolved the do_install failures.
It also explains the lack of
On Sat, 17 Feb 2018 15:28:55 +0200
Alexander Kanavin wrote:
> For me, with epoll enabled:
>
> b6a015a works
> 23f089f and 26e30fa both lock up
Huh. It's possible that the initial "don't try to close fd 0" was
correct, and the real problem is that the attempt
On 02/17/2018 02:03 PM, Martin Jansa wrote:
> Without this change (pseudo at 'Handle O_TMPFILE more better') things
work flawlessly, with epoll enabled.
Your
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/pseudo-1.9.0
is using this change with SRCREV
> Without this change (pseudo at 'Handle O_TMPFILE more better') things
work flawlessly, with epoll enabled.
Your
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/pseudo-1.9.0
is using this change with SRCREV b6a015aa91d7ab84c2f5466f3b5704f501129cbc.
Does it mean that the
On ubuntu-14.04 I'm seeing SIGABRT in couple do_install tasks even after
reverting both pseudo changes (the upgrade from Alex as well as SRCREV bump
to latest commit from Seebs).
So there might be different root cause for SIGABRT unrelated to pseudo
which I haven't seen before, because pseudo
On 02/16/2018 09:25 PM, Seebs wrote:
On Fri, 16 Feb 2018 20:11:48 +0100
Martin Jansa wrote:
I didn't get to the logs yet, but with this change added I see many
do_install tasks failing with exit code '134'.
Huh, that's SIGABRT. I'll see if I can reproduce.
My
On Fri, 16 Feb 2018 20:11:48 +0100
Martin Jansa wrote:
> I didn't get to the logs yet, but with this change added I see many
> do_install tasks failing with exit code '134'.
Huh, that's SIGABRT. I'll see if I can reproduce.
-s
--
I didn't get to the logs yet, but with this change added I see many
do_install tasks failing with exit code '134'.
It might have different cause, but I wasn't seeing this after last oe-core
upgrade before this last pseudo SRCREV bump.
There isn't temp/log.do_install* (for whatever reason) and
On Fri, 16 Feb 2018 17:55:54 +0100
Martin Jansa wrote:
> $ grep -c "tried to close client 0 (highest is 1)"
> update-rc.d/0.7-r5/pseudo/pseudo.log
> 579655922
>
> All pseudo processes I've seen on various servers which were building
> with this change included got stuck
On 02/16/2018 06:55 PM, Martin Jansa wrote:
Something is a bit wrong with this version:
$ du -hs update-rc.d/0.7-r5/pseudo/*
72K update-rc.d/0.7-r5/pseudo/files.db
16K update-rc.d/0.7-r5/pseudo/logs.db
0 update-rc.d/0.7-r5/pseudo/pseudo.lock
31G
Something is a bit wrong with this version:
$ du -hs update-rc.d/0.7-r5/pseudo/*
72K update-rc.d/0.7-r5/pseudo/files.db
16K update-rc.d/0.7-r5/pseudo/logs.db
0 update-rc.d/0.7-r5/pseudo/pseudo.lock
31G update-rc.d/0.7-r5/pseudo/pseudo.log
4.0K
Dropped patches:
0001-Use-epoll-API-on-Linux.patch replaced by
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/commit/?id=0a3e435085046f535074f498a3de75a7704fb14c
(also add --enable-epoll to configure options)
b6b68db896f9963558334aff7fca61adde4ec10f.patch merged upstream
21 matches
Mail list logo