Re: [OE-core] [PATCH] pseudo: update to latest master

2018-03-01 Thread Seebs
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

[OE-core] [PATCH] pseudo: update to latest master

2018-03-01 Thread Alexander Kanavin
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Seebs
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Martin Jansa
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Alexander Kanavin
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Seebs
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Alexander Kanavin
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)

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-19 Thread Alexander Kanavin
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-18 Thread Martin Jansa
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-18 Thread Martin Jansa
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Seebs
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Alexander Kanavin
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 

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Martin Jansa
> 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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Martin Jansa
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-17 Thread Alexander Kanavin
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Seebs
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 --

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Martin Jansa
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Seebs
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

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Alexander Kanavin
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     

Re: [OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Martin Jansa
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

[OE-core] [PATCH] pseudo: update to latest master

2018-02-16 Thread Alexander Kanavin
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