Thanks for the checks, so we narrowed down the problem to subscription-manager uncaught exception when running with LC_ALL but on a system with Japanese environment.

I reassigned the BZ to the proper component.

Does subscription-manager behave correctly if you run it in the UTF-8 C locale? I.e.:

# LC_ALL=C.UTF-8 subscription-manager identify

https://peps.python.org/pep-0538/

> [root@localhost ~]# LC_ALL=C.UTF-8 subscription-manager identity
> システム ID: c56ddf6e-458b-4e5c-a324-ba9f29f6a1a1

Thank you for testing that: this confirms that using the C.UTF-8 locale is a viable workaround for this, either for sos or users running the command manually who need to override the locale.

I raised https://github.com/sosreport/sos/issues/2946 to discuss if sos shall move from LC_ALL=C to LC_ALL=C.UTF-8 .

(In reply to mhorky from comment #11)
> Setting non-UTF-8 encodings is not supported (with the exception of Latin1):
> https://access.redhat.com/solutions/38948, so I think we can consider the
> Japanese example unsupported.
> 
> As sosreport changed the encoding to C.UTF-8, this situation should not
> happen again. Workaround for subscription-manager as-is is to add LANG=
> and/or LC_ALL= prefix with UTF-8 language encoding before running the
> command.
> 
> We'll further investigate ways to prevent these issues in the future.

As stated above, sos did a change preventing this issue (regardless if we support it or not). Since we plan to release the fix in sos soon, I would say doing so sufficiently resolves this bugzilla. So I am reassigning it back to sos.

Closing the bugzilla as the fix has been delivered in sos-4.5.0-1.el8 released via https://access.redhat.com/errata/RHBA-2023:1300 errata.