QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-aadithyasb'
Asked Answered
V

4

31

I am using WSL in Windows 10. I have this warning getting displayed when I run a python file:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-aadithyasb'

I can understand that the XDG_RUNTIME_DIR environment variable is not set and it is creating its own path /tmp/runtime-aadithyasb

I am getting this warning from the moment I installed Xserver for Windows using VcXsrv to open plots when the file is ran.

Wy question is should I add this XDG_RUNTIME_DIR environment variable in windows or is there any method to set a directory under the variable for Ubuntu used under WSL?

Vice answered 17/1, 2020 at 15:29 Comment(0)
V
35

I was able to find what the caused the terminal to issue the warning. Yet I am posting this so that it would be useful for people someday who are new to using WSL like me. This link helped me to solve it and gave me a better insight on how linux works under a WSL:

https://dev.to/winebaths/getting-up-and-running-with-the-windows-subsystem-for-linux-8oc

To solve this issue I just added the below lines to my .bashrc file:

export XDG_RUNTIME_DIR=/some/directory/you/specify 
export RUNLEVEL=3

After this just run the command

source .bashrc 

Now the warning will not keep displaying in your terminal.

Vice answered 21/1, 2020 at 14:47 Comment(4)
Thanks for the solution. Would be good to have an explanation of what those commands are doing. The linked website does not explain it either.Conquer
Hi @HomeroEsmeraldo Please refer to this link to understand about the XDG_RUNTIME_DIR environment variable askubuntu.com/questions/872792/what-is-xdg-runtime-dirVice
why do we need the RUNLEVEL? It seems to work without itConquer
What are the variables XDG_RUNTIME_DIR and RUNLEVEL used for?Solmization
N
8

TL;DR

Within WSL, append the following in your ~/.bashrc file in order to solve the issue:

export XDG_RUNTIME_DIR=/your/chosen/directory

However, I believe that further clarification is important for this question:

What Is XDG_RUNTIME_DIR?

The $XDG_RUNTIME_DIR environment variables is one of many environment variables which make up the XDG Base Directory Specification. The official specification is available from XDG's official website, and although the spec is not long, a more concise version is available on the Arch Wiki.

Why Does It Exist?

The specification came about because UNIX, and by extent Linux, made no mention of where users or programs could store their files. (Imagine if, for example, Windows had no Documents folder, or no Downloads folder. Where would a downloaded file be saved? Each application would have to make its own decision on where to save it.) Thus, in the early days of UNIX, your file system could become a disorganized mess, since every application would create its own directory SOMEWHERE in the filesystem that it would use, and you would have no clue on how to find it.

The point of the XDG Base Directory specification is to provide users and programs with consistent locations to store different types of files. This helps keep your folders much more organized, and allows you to find important config, data, and runtime files much easier.

How does the spec work?

The specification provides some defaults for where files are stored, and those defaults can be overrided by setting environment variables. For example, the spec states that configuration files should be stored in ~/.config/ by default, but by setting $XDG_CONFIG_HOME, config files instead use the path specified by the environment variable.

Why Is This a Problem on WSL?

A missing XDG environment variable usually isn't a problem, and it's also not specific to WSL. Since the application could not find the variable it was looking for, it created its own directory to store its files in. Most applications will do this and will run fine.

How Can I Fix This Warning?

You should set the environment variable for XDG_RUNTIME_DIR in WSL before running a progam which uses it. The easiest way to do this is probably by appending the following to your .bashrc file, so that the environment variable is set upon opening a shell.*

export XDG_RUNTIME_DIR=/your/chosen/directory

When choosing the directory, keep the following (taken from the specification) in mind:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

*Fun Fact: ~/.bashrc itself is a config file. Bash was written before the XDG Base Directory Spec was created, and thus placed its config files directly in the home directory. You can imagine how cluttered it would get if every program did this. This is the problem XDG tried to solve with their spec.

Natheless answered 29/5, 2023 at 21:51 Comment(0)
M
1

Last week, I had a similar error installing a Orange3's library My environment is:

  • Ubuntu 18.04
  • python3 (3.6)
  • orange3 (3.27.1)
  • pyQt5 (5.15)

The trouble was: When I tried to compile orange3 in a command line:

sudo python3 -m Orange.canvas

The system showed:

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'/home/rene/.local/lib/python3.6/site-packages/orangewidget/widget.py:287: RuntimeWarning: subclassing of widget classes is deprecated and will be disabled in the future.Extract code from OWBaseVectorizer or explicitly open it.RuntimeWarning) Fault segment

The trouble for this system error was:

Orange3 (3.27.1) is not compatible with PyQt5 (5.15). However, PyQtWebEngine will be compatible with a PyQt5 upper version to 5.12

I searched in internet the different versions of rhis library and I installed a version between 5.12 and 5.15

Thus, I did I had a downgrade of the PyQt5's library to 5.13.1:

pip3 install PyQt5 == 5.13.1 --use-feature = 2020-resolver

As result of this: Orange3 compile again

Misdo answered 27/11, 2020 at 16:7 Comment(0)
A
-2

I had this problem too just today. What I did was that I opened up PowerShell and killed Ubuntu WSL with the following command:

wsl.exe --shutdown

After that, I opened VcXsrv with its shortcut called "XLaunch" and made sure to tick off "Disable access control".

Americanize answered 9/12, 2020 at 22:56 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.