SUMMARY: Seems to be no way of disabling kdeconnect (so that the kdeconnectd process is not running) STEPS TO REPRODUCE: 1. Look in "System Settings", "KDE Connect" for an option to disable the service. 2. ... then try "System Settings", "Startup and Shutdown", "Background Services" EXPECTED RESULTS: A "Enable KDE Connect" option that can be unchecked... DESIRED RESULT: An option that is not checked until you decide to... SOFTWARE/OS VERSIONS: System Settings 5.18.0 kdeconnect 1.4 (?) from Neon Testing KDE Plasma 5.18.0 KDE Frameworks 5.68.0 Qt 5.13.2 ADDITIONAL INFORMATION: There's an option in System Settings "File Search" to enable or disable search. Looking for an equivalent option for kdeconnect Request triggered by a discussion that the "slow start for gwenview" might be related to running kdeconnect (Bug 411196) Looks like not all distributions have KDEconnect installed by default, seemingly Fedora does not, Neon does. In the case that it is installed, there should be an easily discoverable way of controlling it and maybe it should not be active by default. There's the principle that if a service is not needed it should not be running by default (all the more so when it has an open port)
You can just uninstall it, if it's not needed. Otherwise, I _think_ you can disable it by removing the plasmoid, and overriding the XDG autostart (see https://wiki.archlinux.org/index.php/XDG_Autostart). I am going to leave this bug open though, since having such an option could be useful in some cases (e.g. multi-user systems).
Tried creating a .config/autostart/org.kde.kdeconnect.daemon.desktop file (0744), containing [Desktop Entry] Hidden=True The kdeconnectd process was still here. More magic seemily required. Uninstall works (without taking out other apps/libraries). "Wishlist" is fine; heads up though that there a process with an open port (seemingly just IPv6...)
For what it's worth, the "IPv6 only" comment above came from a misunderstanding of the netstat output. If it lists a service listening on "tcp6", it is _also_ listening on IPv4. Confirmation by: root@testbox:~# nc -v 127.0.0.1 1716 Connection to 127.0.0.1 1716 port [tcp/*] succeeded! ^C root@testbox:~# pkill kdeconnectd root@testbox:~# nc -v 127.0.0.1 1716 nc: connect to 127.0.0.1 port 1716 (tcp) failed: Connection refused So, the KDE Connect has an open port on both IPv4 and IPv6
What is so special about KDEConnect, that it can run each time I boot my computer and not show itself (officially) here: Settings > Startup and Shutdown > Background Services > Startup Services? This may be a great application, but it should hide itself as a preference; there needs to be a way to toggle it on and off without uninstalling it. I submitted a downstream bug report regarding this matter here: https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1871030
Not listed: https://i.stack.imgur.com/FtRl2.jpg
KDE Connect is a regular autostart applications. It is marked as "NoDisplay", though. I was wondering if the Autostart KCM should display such services, perhaps marked as essential system service. But I can already see users shooting themselves in the foot by disabling autostart of plasmashell or power management service :)
Other than listing all Running Processes, is there a way to see an unabridged (and exclusive) list of all auto-start applications that are running as "NoDisplay"? Your point of preventing users from "shooting themselves in the foot" makes sense, but on the other hand, transparency is also important. I like your idea of labeling important things as essential services. But in my case, KDEConnect is not an essential service. I think it is ok to warn people before allowing them to toggle something important off, but "hiding it completely" seems less than forthcoming. The policy I'd advocate, is that if a program or service is important enough to auto-start, it is important enough to be listed in an unabridged list where all other auto-start programs and service are listed. Such lists should be unabridged in my opinion. If it auto-starts, list it.
Yes, KDEConnect in no way counts as essential. Can the 'No Display' aspect be removed? An option to disable it is even more essential in light of this recent issue: https://kde.org/info/security/advisory-20201002-1.txt
The open port is indeed an attack surface, there should be an option to run kdeconnect only when needed. Kdeconnect should be visible among the auto-run services so that it could be disabled (without uninstalling). Additionally it would be nice to have an option to disable just the listening socket from the system tray menu.
+1 for adding the option on a per-user basis. It's not just a matter of convenience; the lack of this option breaks KDE Connect on my multiuser system: As soon as a second desktop session is started, the new kdeconnectd instance seems to steal the Android app's attention, leaving it unable to communicate with the first paired instance. I tried copying /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop to the second user's ~/.config/autostart/ and adding Hidden=true, as specified in the freedesktop spec. It didn't help. I tried renaming /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop. It didn't help. I searched for a systemd --user unit that I could disable. I didn't find one. This really should be a per-user option, listed in Background Services along with all the others. In the meantime, I would appreciate a workaround, if somebody knows of one.
> unable to communicate with the first paired instance The word "paired" should have been in parentheses. I don't know what ate them. To be clear, only one user has paired KDE Connect with the Android app, yet the second user's kdeconnectd instance makes the first instance stop working. Unless there's another way to fix this, I think I need a way to disable kdeconnectd for the second user.
I found some (ugly) workarounds for the unwanted kdeconnectd autostart. The process seems to be launched at session startup time from two distinct places: 1. /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop This can be disabled for individual users by copying the file to each user's ~/.config/autostart/ directory and adding Hidden=true to the [Desktop Entry] section of the copies. Alternatively, it can be disabled by default by adding a line like this to the file's [Desktop Entry] section: X-KDE-autostart-condition=kdeconnectd-autostartrc:General:Autostart:false Then, to re-enable it for a particular user, create a ~/.config/kdeconnectd-autostartrc file with Autostart=true in its [General] section. (The file name "kdeconnectd-autostartrc" is arbitrary; I chose it in hopes of avoiding conflicts with any standard files.) 2. /usr/share/dbus-1/services/org.kde.kdeconnect.service According to KDE docs*, this file tells every user's dbus session to launch kdeconnectd if something tries to contact it over d-bus. With this file in place, kdeconnectd is launched by systemd at session start even if a user disables the autostart .desktop file. The file can be moved to a backup directory to avoid this. However, I think a better fix would be to identify whatever is making org.kde.kdeconnect d-bus requests at session startup, and prevent that instead. * https://develop.kde.org/docs/use/d-bus/dbus_autostart_services/ Of course, these workarounds are hackish, and will probably revert to the normal (unwanted) behavior whenever KDE Connect package updates are installed. What we really need is for it to be configurable in the first place. Seems like a good fit for the Background Services panel.
Alternative workaround step 2, leaving system config files untouched: Copy /usr/share/dbus-1/services/org.kde.kdeconnect.service to ~/.local/share/dbus-1/services/ and change the Exec= line of the copy to Exec=/usr/bin/false When combined with step 1 of my workaround, this prevents kdeconnectd from launching in that user's sessions. It adds some clutter to the session log, as dbus-daemon complains that the executable is failing, but it gives up after several tries and seems to remain quiet after that.
(In reply to Forest from comment #12) > However, I think a better fix would be to identify > whatever is making org.kde.kdeconnect d-bus requests at session startup, and > prevent that instead. I'd say the better fix would be to remove the xdg autostart variant and instead provide a systemd user unit that starts kdeconnect. Since Plasma is started by systemd units nowadays, this step seems to be the logical solution, I'd say. That way, the user can enable/disable it like other user services. I'll try to implement and test that during the holidays. It should also be possible to actually only start kdeconnect if there is a request on the appropriate port. e.g. some distributions start sshd only if there is a request on the port. (via the sshd.socket unit)
(In reply to Bernd Steinhauser from comment #14) > I'd say the better fix would be to [...] > instead provide a systemd user unit that starts kdeconnect. Not everyone uses, or even wants, systemd. (Or linux, for that matter.) Please don't add dependencies on it. KDE already has way to manage things like this, with the Background Services and Autostart control panels.
(In reply to Forest from comment #15) > (In reply to Bernd Steinhauser from comment #14) > > > I'd say the better fix would be to [...] > > instead provide a systemd user unit that starts kdeconnect. > > Not everyone uses, or even wants, systemd. (Or linux, for that matter.) > Please don't add dependencies on it. > Ah, not this again … But ok, let's skip the useless discussion. 1. Plasma is moving towards systemd user units already, as I wrote above. It's the default method to startup Plasma these days. So it kind of makes sense to go a similar path with kdeconnect. (Yes, you can use kdeconnect outside of Plasma, but just about every other DE is also moving towards systemd support/integration) 2. A systemd service unit does *not* introduce a dependency on systemd. It's merely an instruction for systemd to tell it what to do when this service is enabled and/or started. If you don't use systemd, it's just a small text file that will sit on your computer unused. You can of course also choose not to install it. I guess though that any sensible distribution would install it. 3. Just like with Plasma, you can still use the old, flawed, method to start it up. XDG autostart will not go anywhere. If you're unhappy with the old method, feel free to create an alternative approach that does not use systemd. Nothing holding you back there. Just don't expect somebody else to drop a better solution just because you don't like it. systemd is the current standard for Linux and for that reason alone it makes sense to support it. Especially, since this support comes at advantages, which is why everybody is using it. > KDE already has way to manage things like this, with the Background Services > and Autostart control panels. > I'd expect this to move to systemd as well. There is no reason to maintain a second, system to manage background services and autostart functionality, when you're already using a better one that even can be used across DEs. Likely, it will remain though for quite some time, for compatibility reasons and because it takes will and time to do the changes. Thus, in the future (+5 years?) it might go the way of the dodo, we'll see.
Created attachment 155243 [details] KDE Connect systemd user unit Sorry, somehow I totally forgot about this. Anyway, here is a proposal for a systemd user unit. First, move /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop out of that autostart dir and make sure KDE Connect is not started (possibly kill it). Keep in mind that this file will come back if you reinstall or upgrade the package. Then copy the file to ~/.config/systemd/user and do # One time so systemd picks up the new file: systemctl --user daemon-reload # to start/stop: systemctl --user start kdeconnect.service systemctl --user stop kdeconnect.service # to enable, which means it is started automatically when you login (and killed when you logout. The --now part also starts/stops it right away systemctl --user enable --now kdeconnect.service # and disable systemctl --user disable --now kdeconnect.service # output status and log (add e.g. -n 30, if you want to have more log lines) systemctl --user status kdeconnect.service The restart part isn't really necessary, it's merely a precaution to avoid spamming with restarts, should kdeconnect continue to crash for whatever reason. From what I can tell, it works normally. I'm not sure about one thing though. The xdg autostart file mentions "X-KDE-Wayland-Interfaces=org_kde_kwin_fake_input". I'm not sure what this does and if this means that it should be started after kwin? We can't add a dependency on kwin, since 1. it's unclear whether the user actually uses the systemd units to start KDE (even though it's the default now) and 2. there is no kde.service, but two seperate service files plasma-kde_x11.service and plasma-kde_wayland.service. I could maybe add something like After=plasma-kcminit.service, if that would make sense. Someone knowing the internals of kdeconnect better might help here. There might be another way and that would be Type=dbus. Here we can actually let the service wait for the appearance of a certain service on dbus, e.g. org_kde_kwin_fake_input. However, I don't have any experience with this type of service yet, so I'd first would like some input on what org_kde_kwin_fake_input actually does and whether it's be necessary to add a dependency here before making the whole thing more complex. ;) If you want a GUI to manage the systemd units, there is systemdgenie, which should be available via the typical package ressources. Unfortunately, I don't think it's shipped with the default KDE installation, but I'm not sure. Could also depend on the distribution.
Ah, I forgot one thing. You might need to adapt the Exec part, because it might be different on my distribution. So replace ExecStart=/usr/x86_64-pc-linux-gnu/libexec/kdeconnectd with the path that is given in the file org.kde.kdeconnect.daemon.desktop you pulled out of autostart. If the file would be distributed via the package manager, the correct path would be entered when building the package. e.g. it would look something like this: ExecStart=@CMAKE_INSTALL_FULL_LIBEXECDIR@/kdeconnectd
I consider anything I can't turn off, that I don't need, I violation of my freedom. On top of this, KDE tries to hide kdeconnect as an auto-start service. I consider that deceptive and dishonest. I don't need kdeconnect, and I didn't ask for it. Its an unnecessarily-mandatory communication service that screams either anterior motives or foolishness. Either the North Korean government is requiring KDE to run this as spyware, or the developers were just foolish enough to design an unnecessary auto-start service that's hidden, and cannot be turned off. On non-KDE distributions, I can't even install KATE (an otherwise excellent text editor) without this stupid package being a dependency. That's ridiculous! This "bug" has been reported a very long time now without resolution. KDE has too much unnecessary interdependence between applications, breaking Unix philosophies that are praised in the Linux community. Its lazy development to have such tight coupling of modules (that should be optional). If something within an application doesn't have a module it needs, you gray that out instead of making it a mandatory dependency. You can even make it to where, when they click it, it asks the useer if they want to go ahead and install the needed package that would make that feature work. Here's the thing: I don't mind having a few packages on my system that I don't use, but when one of those packages is an unnecessarily-mandatory (hidden from auto-start) *running service*, that I cannot turn off, that's where I draw the line. Until more effort is made to bust up this monolith, I bid you farewell KDE.
Raising the priority now that "just uninstall it" isn't a simple option anymore for users of immutable distros like Kinoite and SteamOS.
kdeconnect is automatically installed in Debian KDE (using kde-plasma-desktop package) and kdeconnectd opens a listening port 1716 for discovering devices, but sometimes I don't want that service to be running and also don't want the port to be open and only want the service be running when I explicitly start the service, but it looks like kdeconnectd is not like other normal service which can be enabled/started/disabled/stopped using systemctl command or similar way. So to disable/stop the service I have to remove kdeconnect package or use the other workarounds mentioned here. Also i don't want to use ufw or any other firewall to disable the port, I want to be able to control the services running on my PC as any other standard service or at least a way to disable it in the System Settings like for KDE Wallet, Firewall, etc.). It is NOT an essential service and should not be hidden in autostart list (It feels very shady). For the essential services, there should be a way to still view list of essential services (with a warning and a short description of the essential service) and modify them after authenticating using a polkit (Should I report this as a feature request in system settings?). If possible, please change the priority/importance of this bug as many people want this option. Not just me, many others trying to find the same option unix.stackexchange.com/questions/482942/how-to-prevent-kdeconnectd-from-starting-automatically?noredirect=1&lq=1 https://unix.stackexchange.com/questions/384306/why-does-kdeconnect-listen-on-port-1716-tcp-all-the-time-how-to-close-the-port?noredirect=1&lq=1 https://askubuntu.com/questions/829628/how-to-disable-kdeconnectd-autostart many more on other forums
I'm also in favor of an option to disable KDEConnect. It could be a simple toggle or button on the KDEConnect setting page like with Bluetooth and the like. This has many benefits, including working with multi-user and immutable systems, and preventing other annoyances (Ex. friend takes your phone from the kitchen and starts doing things on your desktop). While some of these can be worked around by unpairing and/or uninstalling KDEConnect, these have setup and maintenance burdens that in my opinion shouldn't be necessary for connectivity software like this. As an example, Syncthing is a piece of software that someone might want running all the time, but it can still be shutdown when needed.