> /usr/bin/ld.so --help

1) Is there something useful in collecting _help_ of a command? Or did you mean --list ? But that does not work without an argument..?

Also I assume the hardcoded path is essential, right?


2) Further, *when* to collect such commands output automatically / by default? sos uses "plugins" - improper term standing for a component responsible for gathering info from some area, like kernel, apache httpd or chronyd. Each plugin is enabled automatically by presence of either a package, or kernel module loaded, or a file present.

Should we collect this iin a new tiny glibc plugin? Or in "system" plugin[1] that is the only one collecting *anything* about glibc ("rpm -V glibc*")? Or in some another plugin?

[1] https://github.com/sosreport/sos/blob/main/sos/report/plugins/system.py


3) Does this require to be in 9.0 already? We are on tight schedule esp. in QE.

(In reply to Pavel Moravec from comment #1)
> > /usr/bin/ld.so --help
> 
> 1) Is there something useful in collecting _help_ of a command? Or did you
> mean --list ? But that does not work without an argument..?

--help output contains some diagnostic output, too, perhaps in a more digestable form. It shows the search paths being used.

> Also I assume the hardcoded path is essential, right?

You mean /usr/bin/ld.so? I added that to make it clear where the ld.so command comes from (because it is a recent addition), in case you look at this and it's not in your file system yet.

> 2) Further, *when* to collect such commands output automatically / by
> default? sos uses "plugins" - improper term standing for a component
> responsible for gathering info from some area, like kernel, apache httpd or
> chronyd. Each plugin is enabled automatically by presence of either a
> package, or kernel module loaded, or a file present.
> 
> Should we collect this iin a new tiny glibc plugin? Or in "system" plugin[1]
> that is the only one collecting *anything* about glibc ("rpm -V glibc*")? Or
> in some another plugin?

I don't know. There might be additional glibc-specific data to collect in the future.

> 3) Does this require to be in 9.0 already? We are on tight schedule esp. in
> QE.

It's not absolutely required. If necessary, support can ask to run the command manually.

Thanks for the feedback.

I raised https://github.com/sosreport/sos/pull/2812, by default sos will start capturing this since RHEL 9.1 .

Hello,
isn't subcommand

--list-tunables       list all tunables with minimum and maximum values

also worth to collect? If the intention of this BZ is to improve diagnosing glibc tuning decisions?

Please comment here or ideally in the upstream PR

https://github.com/sosreport/sos/pull/2812#discussion_r777801123

Thanks in advance.

Siddhesh and I commented on the upstream pull request. Thanks for the suggestion to include --list-tunables as well.

Florian,
would you be able to verify the fix once a candidate build for 9.1 is available, please?

(In reply to Pavel Moravec from comment #6)
> Florian,
> would you be able to verify the fix once a candidate build for 9.1 is
> available, please?

Either Florian or I will be able to verify the fix once a candidate build for 9.1 is ready.

Thank you!

Thanks for committing to the OtherQA.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sos bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:8275