UHD >= 4.0.0.0 crashes when neither $HOME nor $XDG_CONFIG_HOME are set

[marcusmueller]

Issue Description

https://osmocom.org/issues/6269

Basically, due to 1383fde , running an UHD-consuming application in an environment where there's no $HOME nor $XDG_CONFIG_HOME fatally errors out.

Setup Details

My repro: UHD4.4.0.0 on Fedora38;

unset XDG_RUNTIME_DIR HOME
uhd_usrp_probe

yields

> uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 13.0.1 20230127 (Red Hat 13.0.1-0); Boost_107800; UHD_4.4.0.0
[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
Error: RuntimeError: get_xdg_config_home(): Unable to find $HOME or $XDG_CONFIG_HOME.

Expected Behavior

Running; not being able to find a config file is not fatal!

Also, the actual behaviour runs afoul of documentation:

There is no error if a file does not exist, or the environment variable is not set.

Actual Behaviour

[INFO] [UHD] linux; GNU C++ version 13.0.1 20230127 (Red Hat 13.0.1-0); Boost_107800; UHD_4.4.0.0
[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
Error: RuntimeError: get_xdg_config_home(): Unable to find $HOME or $XDG_CONFIG_HOME.

Steps to reproduce the problem

unset XDG_RUNTIME_DIR HOME
uhd_usrp_probe

Additional Information

Issue arises when UHD-consuming Osmocom software is launched via systemd service.

[laf0rge]

thanks for the report!

It's maybe worth to note that this is a regression over uhd < 4.0.0.0 where the lack of said environment variables was non-fatal. So basically users of osmo-trx-uhd will upgrade their UHD version (e.g. as part of OS upgrade) and suddenly end up having non-working cellular base stations.

[mbr0wn]

Hey guys, thanks for reporting this. We have a fix rolling through CI pipelines and review etc.

As @marcusmueller writes, the intention was not to require people to specify these vars (although until our patch goes live, that's unfortunately required). The assumption that we could always find a $XDG_CONFIG_HOME by going through the list of rules was of course incorrect (as you point out, there's not always a user attached to a process). In other words, there was no intended policy change, but the introduction of the XDG standards compliance was buggy in a way that caused this to happen. And while this is clearly a standard case for you, it was obviously a niche enough case for it to be overseen all this while.

One more detail in case someone reads this at a later time (not directly related to this bug, but about finding images in general):

The Bugzilla page is closed, or I would have commented on there, but there is one thing that I would like to point out: @marcusmueller writes that specifically setting a images dir is a good idea, and I would like to add an explanation why. @laf0rge you point out that UHD should simply default to /usr/share/uhd/images, but that's actually more of a stretch than it might look. Until we have equivalent open-source FPGA tools (unfortunately, probably never) we have to do all the silly business about providing those bitstreams for download using the images downloader, or via our release binaries on GitHub (which is where some of the packaging people get them). That they then land in /usr/share/images/uhd is partly because we modify our uhd_images_downloader script based on the installation method, and partly because people are nice (see, e.g., https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/uhd/uhd-4.4.0.0.ebuild#n140). For example, if we can't find any environment vars to give us a clue, but we know that UHD is installed in /usr/lib/, then we go out on a limb and try /usr/share/uhd/images.

So, production or not, UHD will do its best to find the images (when its not stumbling over bugs introduced by the developers, ahem) but there's no guarantee it can always do that, because between OSes/distros/archs/personal preferences, they could be in all sorts of places.

Again, this is unrelated to this bug, and specifying the images dir would not have helped in this case because UHD would still have choked trying to find a HOME directory in case there's a config file. I'm just expanding on @marcusmueller's comment.

OK, I need to go back to destroying our brand name intentionally breaking people's downstream working on UHD stuff. Thanks again for the report!