releng

#10285 Stuck rubygem-excon builds
Closed: Fixed by kevin. Opened by vondruch.

Closed: Fixed
Reopen Issue
  • Describe the issue

According to Koschei [1], it seems that somewhere around beginning of August, rubygem-excon test suite gets stuck in infinite loop and therefore there are hanging around several builds executed by Koschei before they timeouts:

https://koji.fedoraproject.org/koji/taskinfo?taskID=74537456
https://koji.fedoraproject.org/koji/taskinfo?taskID=74525835

That is one thing. However, digging into the issue, it seems that this is caused by some infrastructure change (because the lockup happens on all versions of Fedora) and this seems to be the real issue causing the lockup:

      /usr/share/gems/gems/eventmachine-1.2.7/lib/eventmachine.rb:531:in `start_tcp_server': no acceptor (port is in use or requires root privileges) (RuntimeError)
    from /usr/share/gems/gems/eventmachine-1.2.7/lib/eventmachine.rb:531:in `start_server'
    from /builddir/build/BUILD/excon-0.85.0/usr/share/gems/gems/excon-0.85.0/tests/servers/good_ipv6.rb:6:in `block in <main>'
    from /usr/share/gems/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run_machine'
    from /usr/share/gems/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run'
    from /builddir/build/BUILD/excon-0.85.0/usr/share/gems/gems/excon-0.85.0/tests/servers/good_ipv6.rb:5:in `<main>'

So this is probably related to some IPv6 stack related change.

@kevin any idea please?

  • When do you need this? (YYYY/MM/DD)

  • When is this no longer needed or useful? (YYYY/MM/DD)

  • If we cannot complete your request, what is the impact?

Also note that the builds gets mostly stuck, while they sometimes passes:

https://koji.fedoraproject.org/koji/taskinfo?taskID=74570935

Also note that the builds gets mostly stuck, while they sometimes passes:

Checking the successful build, it seems that s390x might be the only arch which works. Not sure what is the difference there.

For testing, I suggest Excon revision 6665c178, which prevents the deadlock and provides error message instead. I have disabled the test case in more recent commit.

We do not use or configure ipv6 anywhere currently in the buildsystem. :(
Nothing should have changed with the networking stack. ;(

We applied all pending updates on Aug 11th...

It seems that the first failures happened on August 2nd (although there was also F33 successful build on August 4th) and last successful build on Jul 25th. I wish we had more logs ...

Metadata Update from @humaton:
- Issue tagged with: medium-gain, medium-trouble, ops

This is still reproducible.

So, I'm a bit confused, which is the version that shows the looping problem?

There is still this test case commented out:

https://src.fedoraproject.org/rpms/rubygem-excon/blob/rawhide/f/rubygem-excon.spec#_86

I am quite sure I tested it when I made the last comment while doing update of the package, otherwise I would not leave it disabled. However, enabling the test case, I cannot reproduce ATM.

¯\_(ツ)_/¯
Edited by vondruch

:(

ok... It must have been some artifact of what OS the builders were running? Or something in the toolchain at that time?

Anyhow, if you see it again, let us know.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None

medium-gain medium-trouble ops

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.