Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail

[Santiago Vila]

On Sat, 14 May 2016, Luca BRUNO wrote:

> I just reproduced it via `systemd-run --scope -p TasksMax=512
> ./tcp-stress`.  Part of it is due to the tcp-stress test not
> checking for spawned thread, I've just submitted a PR to make that
> failure explicit: https://github.com/rust-lang/rust/pull/33640

Thanks a lot! Even if this is officially more a bug in systemd than a
bug in rustc, it's always a good thing that error messages are helpful
and explain what's the problem.

> If your sbuild is running as a daemon or in any other dedicated way, I think 
> you should ask for its TasksMax setting to be increased.

Yes, or just wait for syetemd 229-6 to enter testing.

The old default for TasksMax was not good for everybody (this FTBFS
problem is an example) so they have set it to infinity in systemd.

So I did the same in my hand-made autobuilder (which is triggered by
cron) to avoid this happening again.

Thanks.

Bug#822325: [Pkg-rust-maintainers] Bug#822325: rustc: FTBFS in testing: test fail

[Luca BRUNO]

forwarded 822325 https://github.com/rust-lang/rust/pull/33640
thanks

On Saturday, May 14, 2016 02:52:55 PM Santiago Vila wrote:
> 
> In both cases the problem went away by setting
> DefaultTasksMax=infinity in /etc/systemd/system.conf.

Good catch! I was aware of it, but didn't come to my mind in this context. 
 
> So I tried doing that with rustc and the problem went away as well.
> 
> For reference, this was the setting in systemd which most likely was
> to blame for this:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530
> 
> This setting has been changed in systemd yesterday and it will reach
> testing in four days, so if you still want to reproduce this in rustc
> in testing (using the kernel in testing), maybe you could.

I was not able to reproduce it as I was building from a user session,
while you are probably outside of it (system service or a naked shell).

I just reproduced it via `systemd-run --scope -p TasksMax=512 ./tcp-stress`.
Part of it is due to the tcp-stress test not checking for spawned thread, I've 
just submitted a PR to make that failure explicit:
https://github.com/rust-lang/rust/pull/33640

If your sbuild is running as a daemon or in any other dedicated way, I think 
you should ask for its TasksMax setting to be increased.

Ciao, Luca


signature.asc
Description: This is a digitally signed message part.