When I log into YaST via the associated xterm window, it prints:
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
Is this something I can correct?
I’m using TumbleWeed 20171201 / OpenBox.
I’m starting YaST via the OpenBox menu.
This doesn’t appear if I log in with ‘su’ and then run ‘yast’ (command line version (using the suckless terminal)) .
Hi
Try;
xdg-su -c /usr/sbin/yast2
I still get that message.
Hi
Possibly the fact you used su instead of su -
What is the output of;
ls -la /run/user
user 0 (root) should be root:root user 1000 should be <yourloginname>:users
total 0
drwxr-xr-x 3 root root 60 Dec 31 12:12 .
drwxr-xr-x 33 root root 860 Dec 31 16:40 …
drwx------ 7 my_username users 160 Dec 31 13:04 1000
running yast2 after “su -” gives:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-root’
Hi
On both my Tumbleweed installs I have a /run/user/0 directory owned by root:root does this directory exist?
No; only /run/user/1000
Hi
As root user create the directory and see if it makes a difference;
mkdir -p /run/user/0
No change. Do I need to manually set XDG_RUNTIME_DIR somehow?
Hi
You shouldn’t need to… sounds like a bug report is in order…
There is one open already…
https://bugzilla.opensuse.org/show_bug.cgi?id=1072025
I would add yourself to it…
That’s about YaST crashing though.
The message (“QStandardPaths: wrong ownership on runtime directory”) is just harmless debug output and can be ignored.
Maybe a quick check is to login using IceWM?
IIRC that sets up a full screen OpenBox environment.
Could be a double-check whether YaST in OpenBox functions at all on your system
If that works, then you can then perhaps return to testing running OpenBox in a windowed console (I assume that’s what you’re doing) or perhaps switch to init3 (yes I know it’s different in systemd but you get the idea) and then try to invoke OpenBox.
TSU
No, IceWM comes with its own window manager, and does not use OpenBox.
I don’t see the point anyway.
I do get the same message when running YaST in IceWM, but everything works fine.
Again, that message is harmless and can be ignored.
@ravas: do you actually have any problem? (except for that message)
If yes, we should properly investigate that, and not fixate on trying to get rid of that message.
No problem that I’m aware of.
For the record, I use Openbox without a desktop environment.
Just started seeing this on a Tumbleweed, with IceWM Window Manager (as I mentioned above, IIRC IceWM implements a full screen Openbox although wolfi may be more correct than what I’ve read).
Interestingly, this TW has been updated 3 times over the past few weeks, so was likely fully updated to the last TW build shortly before the Xmas holidays.
Just upgraded to the first TW build after the Xmas holidays, 20180106.
Now, when I launch Yast2 from an xterm console, I see the issue described earlier
# yast2
QStandardPaths: Wrong ownership on runtime directory /run/user/1000, 1000 instead of 0
Does not affect functionality, you might have to wait some extra seconds before the command succeeds in launching yast2, but everything works.
After having launched at least once, you don’t even see any latency, the command executes immediately.
TSU
Actually it has nothing to do with the “window manager”.
But xdg-su (which is used to run YaST2) tries to use a different method to switch to root depending on the desktop you run it on. In case of KDE/Plasma it uses kdesu e.g. (which “hides” this and other messages), but as fallback it opens an xterm and runs “su -” and you do of course see all output in that xterm window then.
Interestingly, this TW has been updated 3 times over the past few weeks, so was likely fully updated to the last TW build shortly before the Xmas holidays.
I see it since some time here on Leap 42.3. But it probably depends on the Qt5 version, maybe that debug output is new in 5.10.0, I don’t remember exactly when it started here.
Does not affect functionality, you might have to wait some extra seconds before the command succeeds in launching yast2, but everything works.
After having launched at least once, you don’t even see any latency, the command executes immediately.
I cannot confirm that delay here, but it’s probably unrelated to the message.
I’m currently using Qt 5.9.2
Then consider updating your system. 
5.10.0 is in Tumbleweed since 2 weeks now…
But yes, I probably noticed this with 5.9.2 already.
As I wrote, I don’t remember exactly when it started.
(and normally I use KDE/Plasma anyway, so I wouldn’t see it)