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 be.
-s
--
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
efe0be279901006f939cd35
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 around through scratch
space
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 reprod
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 extracting
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 contribution
> > and I may not have fu
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)
PSEU
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 w
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 tzdata/2018c-r0/ps
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 log.do_i
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 is getting made
mistakenly. I'll stu
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 b6a015aa91d7ab84c
> 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 ch
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 lock
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 experience is again radically
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
--
___
Openembedded-cor
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 in
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 until disk space run out.
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 update-rc.d/0.7-r5/pseudo/pseudo
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.0Kupdate-rc.d/0.7-r5/pseudo/pseudo.
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
efe0be279901006f939cd35
21 matches
Mail list logo
