| Summary: | systemdBoot: autostart items not launched (xdg-user-dirs) | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Rex Dieter <rdieter> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | alois1, clay, kde, nate, nicolas.fella, phoenix_87_c, plasma-bugs, rikmills, wstn8 |
| Priority: | NOR | ||
| Version: | 5.21.1 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://github.com/systemd/systemd/issues/18791 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Rex Dieter
2021-02-24 16:02:00 UTC
This is due to xdg-autostart-generator not supporting startup phases yet. If the desktop file contains the X-GNOME-Autostart-Phase key, the unit will not be generated [1]. [1]: https://github.com/systemd/systemd/blob/c0267a592a2d44c89874249573d53a456ea3756b/src/xdg-autostart-generator/xdg-autostart-service.c#L558 So kde/plasma is just going to leave that broken? Wasn't a problem when plasma implemented the xdg autostart internally (of course), may have to leave at least part of that enabled for items like this? Filed this with systemd, https://github.com/systemd/systemd/issues/18791 The weird thing is that systemd apparently has no problems silently ignoring X-KDE-autostart-phase and just proceeding as if it were not there (at least, I do not see it being processed anywhere in that source file), but it reacts to X-GNOME-Autostart-Phase by ignoring the whole service entirely. I have the same issue and it does not seem to be related to not generated units. Actually, the units *are* generated (I can see them in "generated.late"), but for some reasons the corresponding applications are not started. This happens specifically with Dropbox and Insync (other applications like Thunderbird work fine). If I set systemdBoot to false, these applications run on startup just fine. Here are their .desktop files as a reference: --- Dropbox --- [Desktop Entry] Name=Dropbox GenericName=File Synchronizer Comment=Sync your files across computers and to the web Exec=dropbox start -i Terminal=false Type=Application Icon=dropbox Categories=Network;FileTransfer; Keywords=file;synchronization;sharing;collaboration;cloud;storage;backup; StartupNotify=false X-GNOME-Autostart-Delay=10 --- Insync --- [Desktop Entry] Categories=Network; Comment=Launch Insync Exec=insync start GenericName=Insync Icon=insync Name=Insync Terminal=false TryExec=insync Type=Application Version=1.0 Sounds like a different bug: Do you know if "dropbox start -i" forks into the background? same for "insync start" If so that's a known other bug. They do start, but then the main process quits so we kill the whole service (also now fixed upstream) (In reply to David Edmundson from comment #6) > Sounds like a different bug: > > Do you know if "dropbox start -i" forks into the background? I can confirm that it does. What's the upstream bug? https://github.com/systemd/systemd/issues/18791? Actually that may be a dirty lie. It does not. What I see is that the `dropbox` process is in fact autostarted and seems to be working, but it has no item in the system tray when using systemd startup. If I kill the autostarted process and run it manually, I see the tray item. In my case, I do not even have the dropbox process running (neither for insync). and, after running dropbox start -i, or insync start, I get back my console, so they seem to fork in the background. Can anyone point me to the bug that has been fixed upstream? (the one related to Dropbox and other apps forking in the background not working) *** Bug 460841 has been marked as a duplicate of this bug. *** *** Bug 461128 has been marked as a duplicate of this bug. *** |