As i understand from reading the forums the process for adding environment variables systemwide is a bit different in openSUSE.
So I created a file “/etc/profile.local” but I am unsure what exactly to add here… (I want applications to find files in /opt/rocm/*)
Trying to install ROCm to use opencl with my ATI RX 6600 I jumped to a few hoops to install ROCm on Tumbleweed and now it loads successfully also “rosm-smi” shows me it’s activated and working.
Is this even necessary? Shouldn’t Tumbleweed access libaries and executable files in subfolders of “/opt” by default?
Also I am not sure how exactly to add to “/etc/profile.local”…
Do I need the “export” command like in “.bashrc”?
or just the “PATH=xyz” designation?
As it is now the application I try to install (invokeai) doesn’t seem to find the ROCm libs and “code objects”… - but this might have other reasons - I am in the process of troubleshooting here at the moment…
(I am well aware that ROCm will be hit and miss in it’s current state!
But here that’s not my point - here I try to learn about the recommended way to configure basic stuff in Tumbleweed…)
@jhhh Hi, nope it needs to be added, for the libraries etc the install should put a conf file in /etc/ld.so.conf.d/ for the system to know where external libraries are and run ldconfig to update the cache.
Probably not – the Linux File Hierarchy Standard only mentions that, /opt is a system directory for –
the installation of add-on application software packages
On the other hand, /usr/local is a system directory for use as follows –
for use by the system administrator when installing software locally
One of the main differences is, ‘/usr/local/bin’ is included by default in PATH but, /opt isn’t.
Therefore, packages installed under /opt have to take care that, the directory where the application’s executable file is located, is included in the PATH variable …
I wasn’t aware of that applications put their profiles into “/etc/ld.so.conf” - I always assumed that these applications find the path because is “/opt” is in the path anyway - and I never checked…
For the local .profile I ahve been successful, always added a lot there…
So what about system wide use of the variables - is “/etc/profile.local” the correct file to add them to? So that paths are exported during system boot?
Or should systemd be used?
Well, at least for my user ROCm binaries are now found and used!
Unrelated question as I see you use CUDA:
Do you know if the GPU memory reserved by openCL is locked even if not used by any application (so not available as “normal” graphics memory)?
Or is it only ready to be used by openCL but can be freed temporarily by other applications which do not need it?
@jhhh I have a separate gpu (Tesla P4) that is used via switcherooctl but either card (primary is a Quadro T400) it’s used on the fly by the application(s) in use…
nvidia-smi
Mon Mar 13 12:34:09 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 530.30.02 Driver Version: 530.30.02 CUDA Version: 12.1 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA T400 Off| 00000000:02:00.0 Off | N/A |
| 38% 41C P8 N/A / 31W| 530MiB / 2048MiB | 12% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
| 1 Tesla P4 Off| 00000000:03:00.0 Off | 0 |
| N/A 31C P8 6W / 75W| 46MiB / 7680MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 1828 G /usr/bin/Xorg.bin 215MiB |
| 0 N/A N/A 2046 G /usr/bin/gnome-shell 67MiB |
| 0 N/A N/A 3748 G ...,WinRetrieveSuggestionsOnlyOnDemand 69MiB |
| 0 N/A N/A 10490 G ...40434222,8245604340082411919,131072 102MiB |
| 1 N/A N/A 1828 G /usr/bin/Xorg.bin 46MiB |
+---------------------------------------------------------------------------------------+
Yes, ‘/etc/profile.local’ is the correct place but, the only documentation is in the openSUSE ‘/etc/profile’ file itself –
# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...
Yet another reason for not editing system configuration files placed in ‘/etc’ by the distribution …
Please be aware of the related Bash man page entries –
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it
first reads and executes commands from the file /etc/profile, if that file exists. After reading that file,
it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands
from the first one that exists and is readable. The --noprofile option may be used when the shell is started
to inhibit this behavior. Please note that the file /etc/profile includes an autodetection shell code wether
it has to source /etc/bash.bashrc as well as ~/.bashrc.
Your question related to paths being exported at system boot time is possibly answered as follows:
Paths defined by entries in “Profile” files are not exported at boot time.
The file is called at user login and, the Path is exported at that point in time to the user’s session.
Yes, there is a systemd “paths.target” and, there are “systemd.path” units but, that’s a systemd specific issue which is only related to the boot process as such …
From “UNIX® for the Impatient” – Paul W. Abrahams and Bruce A. Larson – published by Addison-Wesley:
2.6.5 Environment Variables
Each process has a set of environment variables associated with it.
2.9.2 The PATH Environment Variable
Programs and other executable files can reside in many different directories. UNIX® therefore provides a search path for executable files so that you don’t need to remember (and type) the pathname of each command that you execute. The search path is recorded in the environment variable PATH which you can examine by typing
echo $PATH
Yes, yes, I know, there is an awful amount of material which proclaims that, there’s another explanation of what a “Path” is – in other operating systems – which are usually not related to UNIX®.
Strangely, there doesn’t seem to be a Linux Standards definition of the PATH Environment Variable – it’s possibly defined in the source code …
It is not clear what the context the quoted text from chapter 2.9.2 is (e.g. what is the subject of 2.9 where it is part from), but as it is quoted here it is a bit loose explanation IMHO.
It is not really Unix that provides the search path and the interpretation of the PATH variable. The usage of a PATH variable (like all other process environment variables) is defined in the program that interprets it. I assume that in this thread we are talking about the program called bash. And thus the documentation (man page) of bash is where to go about all details of how bash uses it and also about the mechanisms that are offered in bash to create it’s value to one’s needs.
BTW most other shells offer the same (or almost the same) about PATH. And of course other programs may do so when they want to. Problems may arise when different programs support different interpretations of an environment variable.
“libgen” defines the “basename” and “dirname” functions:
The functions dirname() and basename() break a null-terminated pathname string into directory and filename components.
Be that as it may, for most users the PATH Environment Variable is defined by the Shell they’re using – by default when they login, the 7th field of their entry in ‘/etc/passwd’:
Sorry, I fail to see the connection between the PATH environment variable and the basename and dirname functions that in fact cut of on the last / in a pathname as offered to the user in the basename and dirname tools.
henk@boven:~> basename a/b/c/d
d
henk@boven:~> dirname a/b/c/d
a/b/c
henk@boven:~>
Each user’s PATH EV defines at least the following system paths:
/usr/local/bin:/usr/bin:/bin
In other words both ‘/usr/bin’ and ‘/bin’ –
Taking the example of the “ls” CLI command –
The “ls” in ‘/bin’ is a link to the “real” copy of “ls” located in ‘/usr/bin’ …
Taking the shell as an example of a program – when a command which isn’t a “built-in” command, is given to a shell, the shell will search, in one order or another, the paths listed in the PATH EV for a program with the same name as that typed by the user.
If the shell is cautious, it’ll call “realpath” to check if the program found is really located in the indicated directory or, somewhere else …
A cautious shell will issue a warning with respect to the location of the program being called.