Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kdeconnect: [WIP/RFC] let dbus activate via systemd #19622

Closed
wants to merge 1 commit into from
Closed

kdeconnect: [WIP/RFC] let dbus activate via systemd #19622

wants to merge 1 commit into from

Conversation

peterhoeg
Copy link
Member

Motivation for this change

This is proof of concept and VERY much open to comments.

The next version of systemd will give us the standard targets for launching the entire graphical session using systemd, but we can (and I have here) been taking advantage of having dbus launch dbus activated services via systemd instead of doing it directly.

It will give us 3 immediate benefits:

  1. A dead dbus daemon no longer means a messed up desktop. Since it triggers systemd to spawn the service, they are not direct children of dbus and thus survive the dbus process dying.
  2. Auto-spawn if they get killed - I used this a lot when xembedsniproxy was in early stages and quite crashy.
  3. Resource management for something like "baloo" where it is very nice to be able to down prioritize both CPU and IO.

In order to have dbus spawn the processes via systemd, we need to make the following changes:

  1. the dbus service file for each service needs to be augmented with "systemdservice=name-of-service.service"
  2. create a service file each service
  3. create an alias for the dbus activatable service

Item 3 is technically not necessary, but simply to play nice with how other distributions are doing it.

This PR implements items 1 to 3 for kdeconnect in a very non-reusable and naive way, but as mentioned this is simply proof of concept.

I have used kdeconnect for this experiment as there is nothing else that depends on this, but I have tried with both kwallet and baloo here using the same approach and they work fine. They just require a rebuild of the entire KDE environment.

cc: @ttuegel @FRidh @groxxda

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@peterhoeg, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FRidh, @cillianderoiste and @ttuegel to be potential reviewers.

@peterhoeg
Copy link
Member Author

I forgot to add, that in order to actually activate the configuration on nixos, you need the following:

{
services.dbus.packages = with pkgs; [ kdeconnect ];
systemd.packages = with pkgs; [ kdeconnect ];
}

@groxxda
Copy link
Contributor

groxxda commented Oct 17, 2016

I don't know kdeconnect, so pardon my ignorance: Is it really meant as system wide service? I thought the work on systemd to enable graphical-session is merely about user sessions.

Thanks for your work on dbus activation and this poc 👍.
What are the next steps?

  • Create a module for kdeconnect and move the systemd and dbus units there (would be even better if upstream shipped those files and we could just pick them up. The aliasing still needs to be done manually though.

@peterhoeg
Copy link
Member Author

peterhoeg commented Oct 17, 2016 •
edited

kdeconnectd is a user session service - this PR only deals with user sessions services.

But you are absolutely right, upstream should be shipping all of this (they are shipping the dbus files but without the crucial SystemdService part).

The way I understand it is where KDE wants to go, but haven't yet (gnome has afaik already started).

We can however start slowly now. What I propose to do:

  1. abstract my ugly hard-coded "solution" unto a proper derivation under build-support
  2. use the abstracted function in the postInstall phase for kdeconnectd
  3. if that works properly, convert other non-critical user services to this one at a time

Of course, one can also argue that this is not worth the effect as we simply need to wait for upstream but as I see this as a nix learning experience, I don't mind doing the work.

update: before I throw a lot of time after this, I would however like to get @ttuegel's input as the kde maintainer.

@ttuegel
Copy link
Member

ttuegel commented Oct 17, 2016

This sounds good to me! It would be a nice abstraction to have.

@nbp nbp mentioned this pull request Feb 26, 2017
Merged
4 tasks
@Mic92
Copy link
Member

Mic92 commented Jun 10, 2017

we also now better integration of systemd user applications requiring x11: #26094

@mmahut
Copy link
Member

mmahut commented Aug 3, 2019

What is the status of this pull request?

@peterhoeg
Copy link
Member Author

This needs to either:

  1. Be generalized so we can easily the same patches to others, or
  2. We simply wait for upstream

In the mean time, this is working fine.

@stale
Copy link

stale bot commented Jun 1, 2020

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

  1. Search for maintainers and people that previously touched the
    related code and @ mention them in a comment.
  2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
    irc.freenode.net.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020
@peterhoeg
Copy link
Member Author

So yeah, 4 years later - I'll get to this any time now....

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 8, 2020
@peterhoeg
Copy link
Member Author

I'm going to close this and just wait for upstream to get proper support. It's otherwise a lot of work on our side.

@peterhoeg peterhoeg closed this Aug 4, 2020
@peterhoeg peterhoeg deleted the dbusact branch April 4, 2024 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
2.status: work-in-progress 6.topic: qt/kde
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
8 participants
@peterhoeg @mention-bot @groxxda @ttuegel @Mic92 @mmahut @matthewbauer @FRidh