Bug 1213156

Same/simliar problem here - system is Tumbleweed with latest snapshots installed. The problem first appeared with one of the latest snapshots.
Reason here is, that during editing a desktop shortcut apostrophes are added around the command, which leads to error messages like 

plasmashell[6767]: kf.kio.gui: "Could not find the program '$HOME/entw/perl/autostart'"

obviously because $HOME can't be resolved then.
Editing the desktop file in an editor and removing the apostrophes solves the problem for this shortcut.

Well backporting new features should be done in last resort and I'm not sure we want to backport the new ExitType= setting at that point.

Did I get right that it's now needed in leap 15.5 because KDE, after being upgraded, relies on features that are actually not supported by the version of systemd used by Leap ?

(In reply to Michael Hirmke from comment #1)
> Same/simliar problem here - system is Tumbleweed with latest snapshots
> installed. The problem first appeared with one of the latest snapshots.

This sounds unrelated. Plasma in TW has been using systemd boot for several months now.

(In reply to Franck Bui from comment #2)
> Did I get right that it's now needed in leap 15.5 because KDE, after being
> upgraded, relies on features that are actually not supported by the version
> of systemd used by Leap ?

Not features, only bugfixes. Apparently one of the bugfixes needs a new feature though?

It is a design-level bug. So they could not fix it without introducing ExitType=cgroup.

My patch for [4] have been merged by the upstream:
[4] https://github.com/systemd/systemd/issues/27919

It seems systemd with those patches working well on my environment.
https://github.com/openSUSE/systemd/pull/79

(In reply to Fuminobu Takeyama from comment #4)
> It is a design-level bug. So they could not fix it without introducing
> ExitType=cgroup.

Well this should have been discussed *before* upgrading KDE (or whatever) in Leap 15.5.

> It seems systemd with those patches working well on my environment.
> https://github.com/openSUSE/systemd/pull/79

Thanks for preparing this PR.

However backporting new features to SLE/Leap (ExitType= setting in this case) is not something we should take for granted or lightly. The risk of regressions is quite limited I have to admit but you're introducing extra stuff that will need to be fully supported in existing (server) distros...

*** Bug 1211336 has been marked as a duplicate of this bug. ***

> Well this should have been discussed *before* upgrading KDE (or whatever) in Leap 15.5.

Indeed. I never thought xdg-autostart-generator is introduced for Leap 15.5 since I opened related tickets for Tumbleweed last year and those problems has not been resolved completely.


> The risk of regressions is quite limited I have to admit but you're introducing extra stuff that will need to be fully supported in existing

The ExitType is a "feature" only for xdg-autostart-generator for now. As far as I read the code, the added logic is well from the other part, so I personally thought there might be a chance to back port those changed as a security patch.



If it is difficult to fix this issue in systemd side, the next approach would be  reverting the related changes in KDE side.
https://github.com/KDE/plasma-workspace/commit/cb0d2459f5a7fab075ded1488ae4a570b9e3178e


It seems that Cinnamon in Leap 15.5 is old and does not use xdg-autostart-generator apparently. I hope there is no other DEs using it.

I also applied a patch to plasma5-workspace to revert systemdBoot.
https://build.opensuse.org/package/show/home:ftake:branches:openSUSE:Backports:SLE-15-SP5:Update/plasma5-workspace.openSUSE_Backports_SLE-15-SP5_Update

(In reply to Fuminobu Takeyama from comment #10)
> The ExitType is a "feature" only for xdg-autostart-generator for now. As far
> as I read the code, the added logic is well from the other part, so I

Sorry I don't understand this, can you please clarify ?

> If it is difficult to fix this issue in systemd side, the next approach
> would be  reverting the related changes in KDE side.
> https://github.com/KDE/plasma-workspace/commit/
> cb0d2459f5a7fab075ded1488ae4a570b9e3178e

Well the patch looks really simple and apparently would affect the support of systemd-boot in KDE only...

Is that really the case ? If so I would be tempted to go that way as systemd-boot is not really supported anyways.

(In reply to Franck Bui from comment #12)
> Well the patch looks really simple and apparently would affect the support
> of systemd-boot in KDE only...
> 
> Is that really the case ? If so I would be tempted to go that way as
> systemd-boot is not really supported anyways.

Note that systemd-boot (the bootloader) is unrelated to systemdBoot in Plasma (method of starting a Plasma session with graphical-session.target).

(In reply to Fabian Vogt from comment #13)
> Note that systemd-boot (the bootloader) is unrelated to systemdBoot in
> Plasma (method of starting a Plasma session with graphical-session.target).

ah ok the name is pretty confusing for those working on systemd ;)

So what would we loose exactly if we choose to revert https://github.com/KDE/plasma-workspace/commit/cb0d2459f5a7fab075ded1488ae4a570b9e3178e ?

(In reply to Franck Bui from comment #14)
> (In reply to Fabian Vogt from comment #13)
> > Note that systemd-boot (the bootloader) is unrelated to systemdBoot in
> > Plasma (method of starting a Plasma session with graphical-session.target).
> 
> ah ok the name is pretty confusing for those working on systemd ;)
> 
> So what would we loose exactly if we choose to revert
> https://github.com/KDE/plasma-workspace/commit/
> cb0d2459f5a7fab075ded1488ae4a570b9e3178e ?

We'd run the older and meanwhile untested code in Plasma instead and systemd .user units would change behaviour. IMO a bigger chance of causing regressions than taking the systemd backports.

(In reply to Fabian Vogt from comment #15)
> We'd run the older and meanwhile untested code in Plasma instead and systemd
> .user units would change behaviour. IMO a bigger chance of causing
> regressions than taking the systemd backports.

I'm not sure. My main concern currently is this commit: https://github.com/systemd/systemd/commit/ef4300654e70e76ed74f7d544e0f44c5d92fb698

It modifies core part of PID1, it's very recent and thus haven't been tested broadly yet.

The other backported commits are limited to the xdg-autostart-generator, so the risk of regression is pretty limited.

(In reply to Franck Bui from comment #16)
> (In reply to Fabian Vogt from comment #15)
> > We'd run the older and meanwhile untested code in Plasma instead and systemd
> > .user units would change behaviour. IMO a bigger chance of causing
> > regressions than taking the systemd backports.
> 
> I'm not sure. My main concern currently is this commit:
> https://github.com/systemd/systemd/commit/
> ef4300654e70e76ed74f7d544e0f44c5d92fb698
> 
> It modifies core part of PID1, it's very recent and thus haven't been tested
> broadly yet.
> 
> The other backported commits are limited to the xdg-autostart-generator, so
> the risk of regression is pretty limited.

s->exit_type == SERVICE_EXIT_MAIN is always true for all the existing services.




I'm wondering reverting Plasma is a better approach in terms of stability; the conventional kdeinit code has been used long years while xdg-autostart-generator seems to require more integration tests.

(In reply to Fuminobu Takeyama from comment #17)
> I'm wondering reverting Plasma is a better approach in terms of stability;
> the conventional kdeinit code has been used long years while
> xdg-autostart-generator seems to require more integration tests.

Well this contradicts what Fabian said in comment #15. It would be nice if this point could be clarified since it's the most important one.

(In reply to Fuminobu Takeyama from comment #17)
> I'm wondering reverting Plasma is a better approach in terms of stability;
> the conventional kdeinit code has been used long years while
> xdg-autostart-generator seems to require more integration tests.

Fabian, what do you think ?

(In reply to Franck Bui from comment #18)
> (In reply to Fuminobu Takeyama from comment #17)
> > I'm wondering reverting Plasma is a better approach in terms of stability;
> > the conventional kdeinit code has been used long years while
> > xdg-autostart-generator seems to require more integration tests.
> 
> Well this contradicts what Fabian said in comment #15. It would be nice if
> this point could be clarified since it's the most important one.

IMO changing the way Plasma starts to a significantly different code path is much higher risk than applying the systemd fixes.

That's not what comment #17 said:

> the conventional kdeinit code has been used long years while
> xdg-autostart-generator seems to require more integration tests.

(In reply to Franck Bui from comment #21)
> That's not what comment #17 said:
> 
> > the conventional kdeinit code has been used long years while
> > xdg-autostart-generator seems to require more integration tests.

That was the case in the past (Plasma < 5.26), but not anymore. systemdBoot=true is the upstream default and the other code path is only used on systems without systemd. We never tested it on any recent Plasma version.

We have to do test whichever we take. Who will make decision about this?
 

> We never tested it on any recent Plasma version.

At least, I am testing on one of my environment.

We can test it without recompile by creating: ~/.config/startkderc
and write the following to the file.

```
[General]
systemdBoot=false
```

(In reply to Fuminobu Takeyama from comment #23)

> We can test it without recompile by creating: ~/.config/startkderc
> and write the following to the file.
> 
> ```
> [General]
> systemdBoot=false
> ```

It works fine on all my systems.

Thanks.

greetings
Udo

(In reply to Fuminobu Takeyama from comment #23)
> We have to do test whichever we take. Who will make decision about this?
>  
> 
> > We never tested it on any recent Plasma version.
> 
> At least, I am testing on one of my environment.
> 
> We can test it without recompile by creating: ~/.config/startkderc
> and write the following to the file.
> 
> ```
> [General]
> systemdBoot=false
> ```

I can confirm that this fixes Bug 1203617 as well

Instead of manually creating the file above, you can also run the following command: 

```
kwriteconfig5 --file startkderc --group General --key systemdBoot false
```


Shell we revert the setting of Plasma to resolve this issue for 15.5? I would not keep the current situation anymore where essential features like text input are broken.

The setting is supported by the upstream for a while; it is still configurable. Furthermore some people here have tested this old style.


Again, fixed package is ready:
https://build.opensuse.org/package/show/home:ftake:branches:openSUSE:Backports:SLE-15-SP5:Update/plasma5-workspace.openSUSE_Backports_SLE-15-SP5_Update


Please note that we also have to resolve in systemd side too by the release of 15.6 or later; other desktop environments other than KDE might start to use it. Please consider update systemd in Tumbleweed to v254, which is shipped with my patch to fix this issue.

(In reply to Fuminobu Takeyama from comment #26)
> Please note that we also have to resolve in systemd side too by the release
> of 15.6 or later; other desktop environments other than KDE might start to
> use it. Please consider update systemd in Tumbleweed to v254, which is
> shipped with my patch to fix this issue.

AFAIK GNOME already uses it...

(In reply to Fabian Vogt from comment #27)
> AFAIK GNOME already uses it...

As far as I checked on Tumbleweed, it has not been enabled yet.

This is an autogenerated message for OBS integration:
This bug (1213156) was mentioned in
https://build.opensuse.org/request/show/1110022 Backports:SLE-15-SP5 / plasma5-workspace

*** Bug 1203617 has been marked as a duplicate of this bug. ***

*** Bug 1203617 has been marked as a duplicate of this bug. ***

Hi,
Same problem/issues ...
I just upgraded [ dup ] from leap 15.4 to 15.5 .
The dup went fine without any problem.  The system booted  to 15.5 ...
However I realized that ALL desktop definitios were changed  from command line to environmental variable 
   program
   arguments
   path 

An old command  sleep 20s &&  /path/bash-shell.sh 
was changed to 
    program   sleep 
    arguments  180s '&&' /path/bash/-shell.sh
    path 

Executing it fails with with Plasma workspace
                              execvp: Exec format error   

The autostart  entries complain due to syntactic errors  and some of them do not start .....
Lots of messages via journalctl .... like 
Oct 07 08:29:27 <user-domain>.dom systemd-xdg-autostart-generator[5580]: /home/<userid>/.config/autostart/ org.kde.kontact.desktop:13: Unknown key name 'SingleMainWindow' in section 'Desktop Entry', ignoring.
Oct 07 08:29:27 <user-domain>.dom systemd-xdg-autostart-generator[5580]: /home/<userid>/.config/autostart/org.kde.kontact.desktop:16: Unknown key name 'TerminalOptions' in section 'Desktop Entry', ignoring.
Oct 07 08:29:27 <user-domain>.dom systemd-xdg-autostart-generator[5580]: /home/<userid>/.config/autostart/pia-client.desktop:14: Unknown key name 'TerminalOptions' in section 'Desktop Entry', ignoring.
Oct 07 08:29:27 <user-domain>.dom systemd-xdg-a

How should be done to get the old entries like   
/abc/bash-shell.sh  argument &
path
to be converted to the new 15.5 system ?

It is any way to go back to the Good Old  desktop/autostart rules ?

Thanks,

ND

> sleep 20s &&  /path/bash-shell.sh 

That's invalid. Only a command or a path to executable is allowed in Exec
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html


The recommended way is to move that shell expression into a new shell script. But you can switch back to the old mechanism as I mentioned before by systemdBoot=false.

(In reply to Fuminobu Takeyama from comment #33)
> > sleep 20s &&  /path/bash-shell.sh 
> 
> That's invalid. Only a command or a path to executable is allowed in Exec
> https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
> 
> 
> The recommended way is to move that shell expression into a new shell
> script. But you can switch back to the old mechanism as I mentioned before
> by systemdBoot=false.
=========================================
sleep 20s &&  /path/bash-shell.sh   worked on 15.4 
it fails on 15.5 .
Why ?
It seems that the testing/QA did not include a [successful] regression phase to make sure that the existing code is not broken . 

i.e. regression testing is important because it helps reduce the risk of breaking existing functionality when making changes to the software/system.

Question : 
the upgrade 15.4 to 15.5 changed/"upgraded" a lot of existing Boot15.4 desktop / autostart settings/definitions to accommodate the new 15.5 methods. 
 
Does sysetemdBoot=false accept the new-15.5-type settings/definitions 
OR 
we have to change 15.5 settings/definitions back to 15.4  rules ?

Thanks
ND

(In reply to Nick Dordea from comment #34)
> sleep 20s &&  /path/bash-shell.sh   worked on 15.4 
> it fails on 15.5 .
> Why ?

KDE's own, traditional autostart (Leap 15.4 or sysetemdBoot=false) does run such a script against the specification of desktop files.
And the new implementation of XDG autostart provided by systemd is strict, and it does not accept invalid desktop files anymore.


> It seems that the testing/QA did not include a [successful] regression phase
> to make sure that the existing code is not broken . 
> 
> i.e. regression testing is important because it helps reduce the risk of
> breaking existing functionality when making changes to the software/system.

I think so too.
And even some valid desktop files does not work on Leap 15.5, which is the main topic of this report.

 
> Question : 
> the upgrade 15.4 to 15.5 changed/"upgraded" a lot of existing Boot15.4
> desktop / autostart settings/definitions to accommodate the new 15.5
> methods. 
>  
> Does sysetemdBoot=false accept the new-15.5-type settings/definitions 
> OR 
> we have to change 15.5 settings/definitions back to 15.4  rules ?

Sorry, I cannot catch the point.