All of lore.kernel.org
 help / color / mirror / Atom feed
* PSA for anyone using openSUSE 42.2 (or similar)
@ 2016-12-16 15:06 Trevor Woerner
  2016-12-16 16:06 ` Alexander Kanavin
  0 siblings, 1 reply; 5+ messages in thread
From: Trevor Woerner @ 2016-12-16 15:06 UTC (permalink / raw)
  To: yocto

Lately I've been seeing very intermittent, sporadic cases where a build will
fail with something similar to:

	fork: Resource temporarily unavailable

and nothing else wrong. Simply restarting the build causes it to succeed
without incident. I had been seeing this, maybe, twice a week (on a build
machine that builds most of the day as well as overnight with Jenkins jobs).

I decided to investigate and found:

	http://unix.stackexchange.com/questions/253903/creating-threads-fails-with-resource-temporarily-unavailable-with-4-3-kernel

which suggests the issue is a combination of
	- linux >= 4.3
	- systemd >= 228

both of which are true when upgrading openSUSE from 42.1 (linux-4.1.36-41/210)
to 42.2 (linux-4.4.36-8/228).

The fix appears to be to modify the "DefaultTasksMax" systemd parameter
(uncommenting it and setting it to "infinity"). On openSUSE 42.2 this is
found in /etc/systemd/system.conf, then
	
	# systemctl daemon-reexec

or reboot.

I just made this adjustment but given it only happened once or twice a week on
a reasonably busy build machine it might be hard to confirm. I'm also not sure
if setting it to "infinity" is sensible ;-)

I'm guessing other host distros probably also fall into this category.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PSA for anyone using openSUSE 42.2 (or similar)
  2016-12-16 15:06 PSA for anyone using openSUSE 42.2 (or similar) Trevor Woerner
@ 2016-12-16 16:06 ` Alexander Kanavin
  2016-12-16 17:31   ` Alexander Kanavin
  2016-12-16 18:24   ` Trevor Woerner
  0 siblings, 2 replies; 5+ messages in thread
From: Alexander Kanavin @ 2016-12-16 16:06 UTC (permalink / raw)
  To: yocto

On 12/16/2016 05:06 PM, Trevor Woerner wrote:
> I just made this adjustment but given it only happened once or twice a week on
> a reasonably busy build machine it might be hard to confirm. I'm also not sure
> if setting it to "infinity" is sensible ;-)
>
> I'm guessing other host distros probably also fall into this category.

I've seen this on Debian Testing as well. Care to submit a documentation 
bug?

https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs

Alex




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PSA for anyone using openSUSE 42.2 (or similar)
  2016-12-16 16:06 ` Alexander Kanavin
@ 2016-12-16 17:31   ` Alexander Kanavin
  2016-12-17  3:19     ` Trevor Woerner
  2016-12-16 18:24   ` Trevor Woerner
  1 sibling, 1 reply; 5+ messages in thread
From: Alexander Kanavin @ 2016-12-16 17:31 UTC (permalink / raw)
  To: yocto

On 12/16/2016 06:06 PM, Alexander Kanavin wrote:
> On 12/16/2016 05:06 PM, Trevor Woerner wrote:
>> I just made this adjustment but given it only happened once or twice a
>> week on
>> a reasonably busy build machine it might be hard to confirm. I'm also
>> not sure
>> if setting it to "infinity" is sensible ;-)
>>
>> I'm guessing other host distros probably also fall into this category.
>
> I've seen this on Debian Testing as well. Care to submit a documentation
> bug?
>
> https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs

Actually, scratch that; if bitbake can detect that the limit is not 
optimal at runtime, then it probably should. Direct the bug accordingly.

Alex



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PSA for anyone using openSUSE 42.2 (or similar)
  2016-12-16 16:06 ` Alexander Kanavin
  2016-12-16 17:31   ` Alexander Kanavin
@ 2016-12-16 18:24   ` Trevor Woerner
  1 sibling, 0 replies; 5+ messages in thread
From: Trevor Woerner @ 2016-12-16 18:24 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: yocto

On Fri, Dec 16, 2016 at 11:06 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 12/16/2016 05:06 PM, Trevor Woerner wrote:
>>
>> I just made this adjustment but given it only happened once or twice a
>> week on
>> a reasonably busy build machine it might be hard to confirm. I'm also not
>> sure
>> if setting it to "infinity" is sensible ;-)
>>
>> I'm guessing other host distros probably also fall into this category.
>
>
> I've seen this on Debian Testing as well. Care to submit a documentation
> bug?
>
> https://bugzilla.yoctoproject.org/enter_bug.cgi?product=General%20Docs

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10818


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PSA for anyone using openSUSE 42.2 (or similar)
  2016-12-16 17:31   ` Alexander Kanavin
@ 2016-12-17  3:19     ` Trevor Woerner
  0 siblings, 0 replies; 5+ messages in thread
From: Trevor Woerner @ 2016-12-17  3:19 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: yocto

On Fri, Dec 16, 2016 at 12:31 PM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> Actually, scratch that; if bitbake can detect that the limit is not optimal
> at runtime, then it probably should. Direct the bug accordingly.


Bitbake can't possibly know how many builds you're going to spin up at
any one time, and it can't take into consideration whether of not you
set "parallel build" or "number of threads" settings on any of those
builds. So when each bitbake starts it might look at the variable and
say "that looks reasonable" but after starting the 3rd bitbake you end
up with resource issues that fail a build that might otherwise muddle
through.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-12-17  3:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-16 15:06 PSA for anyone using openSUSE 42.2 (or similar) Trevor Woerner
2016-12-16 16:06 ` Alexander Kanavin
2016-12-16 17:31   ` Alexander Kanavin
2016-12-17  3:19     ` Trevor Woerner
2016-12-16 18:24   ` Trevor Woerner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.