Ruby, Yast problem. What could be the causes and possible solutions?

I have since some time ago a problem with Yast: the main menu starts ok but not the specific applications. When calling from the command line I can see there is apparently an error related to Ruby and libjemalloc. For example:

# yast2 users 
<internal:/usr/lib64/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': /lib64/ cannot allocate memory in static TLS block - /usr/lib64/ruby/gems/3.1.0/gems/io-wait-0.2.3/lib/io/ (LoadError)
    from &lt;internal:/usr/lib64/ruby/3.1.0/rubygems/core_ext/kernel_require.rb&gt;:85:in `require'
    from /usr/lib64/ruby/3.1.0/socket.rb:4:in `&lt;top (required)&gt;'
    from &lt;internal:/usr/lib64/ruby/3.1.0/rubygems/core_ext/kernel_require.rb&gt;:85:in `require'
    from <internal:/usr/lib64/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
    from /usr/lib/YaST2/bin/y2start:9:in `<main>'

This same thing occurs with other yast subcommands.

I see this is mentioned in at least one issue in bugzilla (see here) but in relation to vim, not yast. I can’t see or understand if the problem has been solved or how.

What is going on here? How can I sort this out?

Using Tumbleweed on a 64 bit machine.

More info that can be useful:

# zypper if libjemalloc2 
Loading repository data...
Reading installed packages...

Information for package libjemalloc2:
Repository     : Main Repository (OSS)
Name           : libjemalloc2
Version        : 5.3.0-1.2
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 894.8 KiB
Installed      : Yes
Status         : up-to-date
Source package : jemalloc-5.3.0-1.2.src
Upstream URL   :
Summary        : General-purpose scalable concurrent malloc implementation
Description    : 
    General-purpose scalable concurrent malloc(3) implementation.
    This distribution is the stand-alone "portable" version of jemalloc.
# zypper if ruby
Loading repository data...
Reading installed packages...

Information for package ruby:
Repository     : Main Repository (OSS)
Name           : ruby
Version        : 3.1-1.4
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 84 B
Installed      : Yes (automatically)
Status         : up-to-date
Source package : ruby-3.1-1.4.src
Upstream URL   :
Summary        : An Interpreted Object-Oriented Scripting Language
Description    : 
    Ruby is an interpreted scripting language for quick and easy
    object-oriented programming.  It has many features for processing text
    files and performing system management tasks (as in Perl).  It is
    simple, straight-forward, and extensible.

    * Ruby features:

    - Simple Syntax

    - *Normal* Object-Oriented features (class, method calls, for

    - *Advanced* Object-Oriented features(Mix-in, Singleton-method, for

    - Operator Overloading

    - Exception Handling

    - Iterators and Closures

    - Garbage Collection

    - Dynamic Loading of Object Files (on some architectures)

    - Highly Portable (works on many UNIX machines; DOS, Windows, Mac,
    BeOS, and more)

Thank you. But that thread suggests the problem is libruby and that the solutions is just uninstalling it. Unfortunately this is apparently not the case. Uninstalling libruby uninstalls yast, which if reinstalled will reinstall libruby as a dependency that cannot be gone around.

Just a note. Found another related issue in bugzilla that is apparently standing:

Bug 1197120]( - [Build 20220314] remote installation (vnc): failed to launch yast (error loading plugin module)

If I understand correctly this problem hast not yet been solved. I will keep watching.

In case this is of interest. It seems that I had at some point messed with rubygems and there where some conflicts. I solved this by first removing Ruby and Yast using zypper, then eliminating /usr/lib64/ruby and its subfolders, and finally reinstalling patterns-yast-yast2_desktop. Yast2 now works as expected.

There a ruby updates in the next snapshot 20220807, so zypper dup and see if that resolves the issue…

I cannot reproduce it in 20220805.

Thank you, but I am confident that it was me who messed up Ruby by running experiments with rubygems. I just applied the same solution on another computer with the same issue. I should have setup a different Ruby environment and not mess with the one in the system. In fact I do that with Perl to avoid issues so I should have known better. Lesson learned twice anyway :slight_smile: