Runit with KDE Plasma: krunner current working directory /

Martin Steigerwald martin at lichtvoll.de
Tue Feb 14 15:22:50 GMT 2023


Lorenzo - 14.02.23, 14:31:43 CET:
> On Fri, 10 Feb 2023 14:39:58 +0100
> 
> Martin Steigerwald <martin at lichtvoll.de> wrote:
> > Hi!
> > 
> > This puzzled me for a long time and I have no idea where to report
> > this:
> > 
> > …proc# ls -ld $(pidof krunner)/cwd
> > lrwxrwxrwx 1 USER USER 0 10. Feb 14:26 15116/cwd -> /
> > …proc# ls -ld $(pidof plasmashell)/cwd
> > lrwxrwxrwx 1 USER USER 0 10. Feb 14:27 9191/cwd -> /home/USER
> > 
> > [...]
> > 
> > Is this a bug with runit? Is this an upstream bug?
> 
> I can reproduce this with my system (runit), however I just switched
> and rebooted into sysvinit and it's the same, so this is more likely
> a bug that happens with any init != systemd

I see. I thought to try it with sysvinit as well, but did not yet do it.

> > Any idea how to find the root cause for this and determine what
> > needs
> > to be fixed?
> 
> Are you running Xorg as USER or root? (not sure it's relevant)

Is running as root here. 

> I pinned ('keep open') krunner and then added it to the kde autostart;
> this way is always open (you probably don't want that) but it also
> starts in /HOME/USER.

krunner is also running when it is not shown, so that could be a work 
around.

> My guess is that the keyboard is somehow not linked to the graphic
> session (plasma session) so by starting program with keyboard combo
> it's parented directly to init.

The keyboard? Well krunner has runit as parent process. But does that 
have to do with a keyboard? You mean it could be an issue with elogind?

> Not sure if this is a bug in KDE, elogind or we are missing some
> systemd features (user-session, cgroups?).

What would you suggest to find out?

Another thing that comes to my mind is: Plasma a systemd startup method 
meanwhile, but can also work without systemd¹. Maybe the issue is 
related to using a different code path in Plasma for non-system startup? 
Ah, why didn't I think of this earlier. I just searched KDE bugzilla and 
got this:

krunner starts applications with cwd "/" with init system other than 
systemd (openrc, runit, ...)

https://bugs.kde.org/432975

So it appears to be upstream breakage?

[1] https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/

> > I tried to work around this by doing "cd $HOME" in my zshrc. However
> > this makes open new tabs in Konsole always start at $HOME even when
> > I
> > open them with a tab active which has a different cwd. Yeah, I got
> > only do "cd $HOME" if current working directory is /, but I'd rather
> > see this fixed. However, I do not even know where to report this
> > issue.

> Your practical issue is that, for example, by typing 'konsole' in
> krunner you get a console in / instead of /home/USER ( I don't have
> that) or is something else?

Indeed. Also the file dialog for example in kwrite / kate or okular would 
start out in "/" in that case.

Thanks,
-- 
Martin





More information about the Debian-init-diversity mailing list