Hi Martin!

I have a different system: Debian SID/Testing with usrmerge, systemd
and bash, and I see the expected behavior: cwd linked to /home/USER.
So I suspect, that it is not caused by KDE/QT.

Reinhard

Am Freitag, 10. Februar 2023, 14:39 schrieb Martin Steigerwald:

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

This is with /bin/sh pointing to Dash, the user shell is Z-Shell, but I
have also seen this on systems where the user shell is Bash. No
usrmerge. (I hope to avoid it as long as possible.)

According to pstree krunner's parent process is runit which of course
has current working directory pointing to /.

Plasmashell instead is going like this

├─runsv(2066)─┬─sddm(2116)─┬

─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬

I bet through SDDM its working directory is set to the actual home
directory of the user.

Is this a bug with runit? Is this an upstream bug?

Any idea how to find the root cause for this and determine what needs to
be fixed?

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.

Any insight greatly appreciated.

Best,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Reinhard Karcher - 10.02.23, 15:20:49 CET:

I have a different system: Debian SID/Testing with usrmerge, systemd
and bash, and I see the expected behavior: cwd linked to /home/USER.
So I suspect, that it is not caused by KDE/QT.

Just for the record:

Sometimes the truth is not that digital.

It appears to be that there is a relation with an upstream change that
affects anything except Systemd.

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

https://bugs.kde.org/432975

Plasma appears to use different code paths for systemd and non systemd startup:

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

Will be looking with upstream and/or Debian's other init team whether a solution can be found or… apply a work-around.

Best,
Martin

Am Freitag, 10. Februar 2023, 14:39 schrieb Martin Steigerwald:

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

This is with /bin/sh pointing to Dash, the user shell is Z-Shell,
but I have also seen this on systems where the user shell is Bash.
No usrmerge. (I hope to avoid it as long as possible.)

According to pstree krunner's parent process is runit which of
course
has current working directory pointing to /.

Plasmashell instead is going like this

├─runsv(2066)─┬─sddm(2116)─┬

─sddm-helper(8989)───startplasma-x11(8994)─┬─plasma_session(9056)─┬

I bet through SDDM its working directory is set to the actual home directory of the user.

Is this a bug with runit? Is this an upstream bug?

Any idea how to find the root cause for this and determine what
needs to be fixed?

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.

Any insight greatly appreciated.

--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)