Nixpkgs: KDE "Switch User" menu item and lock screen button no longer present after systemd 246 update

[jerith666]

Describe the bug
In the "Leave" section of the KDE Application Launcher, the "Switch User" item is no longer present after the update to systemd 246. It is also missing from the lock screen. I bisected this down to the 40d2968ebf3 merge commit from #94354. (Which surprised me -- I was sure it was going to be the very next merge, 7cf3cd3 from #95893.)

Additional context
There are discussions of this at KDE, but nothing truly concrete as far as I can tell. The closest bug seems to be https://bugs.kde.org/show_bug.cgi?id=423526, but it seems to predate this. Other links I've found while trying to track this down:
https://bugs.kde.org/show_bug.cgi?id=423477
https://phabricator.kde.org/D20237
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/137
https://bugs.kde.org/show_bug.cgi?id=425792
https://bugs.archlinux.org/task/67623
https://github.com/sddm/sddm/issues/1293

Notify maintainers
@ttuegel @andir @edolstra @flokli

Metadata

• system: "x86_64-linux"
• host os: Linux 5.4.59, NixOS, 20.09.git.77a22713e5 (Nightingale)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.7
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[worldofpeace]

Is this also present in 20.09? Because it would be a blocker.

[jerith666]

I think it probably will be, but I can test for sure this evening:

$ git grep version.*= channels/nixos-20.09 -- pkgs/os-specific/linux/systemd
channels/nixos-20.09:pkgs/os-specific/linux/systemd/default.nix:  version = "246";

[jerith666]

I also see that systemd updates have kept coming (#97658 and #97989), so I can test with those to see if perhaps they fix the issue. (I'm guessing the fix is gonna be on the KDE side though.)

[jerith666]

Confirmed, this does affect channels/nixos-20.09 @ 3b8ddb2f1ee6f4c0794fb6dfbd273c3599492b76.

I'm using this with nixops to test, FWIW:

{

  vm = { config, pkgs, ... }:

  {
    deployment = {
      targetEnv = "virtualbox";
      virtualbox.memorySize = 1024;
    };

    services.xserver = {
      enable = true;

      desktopManager.plasma5.enable = true;

      #provide both us-qwerty and us-dvorak
      #using crufty parallel-list syntax
      layout = "us,us";
      #qwerty default, dvorak second
      xkbVariant = ",dvorak";
    };

    console = {
      keyMap = "dvorak";
    };

    time.timeZone = "America/New_York";

    users.users = {
      root = {
        initialPassword = "root";
      };

      matt = {
        initialPassword = "matt";
        isNormalUser = true;
      };

      isaac = {
        initialPassword = "isaac";
        isNormalUser = true;
      };
    };
  };
}

[jerith666]

I tried applying the patch as it currently stands from https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/137 :

https://github.com/jerith666/nixpkgs/commit/254dc4f9306320dc8dcd22f78083ae601b9a63be

However this does not fix the problem. :(

[jerith666]

A new patch was posted at invent.kde.org today. It doesn't apply cleanly, so I took a guess at how to back-port it:

https://github.com/jerith666/nixpkgs/commit/e67650f0ce0

Now plasma-shell dumps core as soon as I hover the mouse over the "Leave" menu. :-(

[jonringer]

Just as a reminder, the 20.09 release is scheduled to happen this monday, the 28th.

If this is still relevant to blocking the release, then there should be some forward movement.

A blocker meeting has still yet to be scheduled. But, if you consider this item to still warrant blocking the entirety of the nixos-20.09 release, the please do so on the Feature freeze discussion issue. A template for proposing an item can be found https://github.com/NixOS/nixpkgs/issues/95475#issuecomment-699218336

[ttuegel]

A patch was accepted upstream, but we will need to backport it (it doesn't apply cleanly). Otherwise, we might bug upstream to backport the patch because Plasma 5.18 is an LTS release.

[flokli]

We should bug upstream about backporting it into the stable release in any case - I assume other distros run into similar problems.

[ttuegel]

I assume other distros run into similar problems.

I doubt that other distros are using latest systemd with LTS Plasma, but it wouldn't hurt to remind upstream.

[ttuegel]

I was able to backport the patch in a way that plasma-workspace builds, but the patch had no effect.

EDIT: According to comments here, the patch also doesn't work with plasma-workspace-5.19, so it seems that upstream _still_ has no patch for this issue.

[jonringer]

If we were to revert the systemd bump, we would need to do it soon so that the staging cycle has enough time to propagate other failures.

Looking at the issue thread, I don't see any mention of systemd; but rather rather just discussion around deprecated api's. It could be possible that reverting systemd may not even fix the issue. And systemd might have been just updated around the same time as the qt application bumps.

[worldofpeace]

Yeah, it should probably be verified using systemd.package with a derivation before the update. And then trying to reproduce the bug.

[ttuegel]

Looking at the issue thread, I don't see any mention of systemd; but rather rather just discussion around deprecated api's. It could be possible that reverting systemd may not even fix the issue.

Digging into the code a bit, the deprecated APIs are provided by logind, so I don't think the systemd update is a coincidence. Of course, I wouldn't take any action without verifying that it fixes the problem.

[flokli]

Was the breakage of the depreciated logind API intentional? I couldn't spot it in the change log, so maybe we should also check back with upstream systemd...

[worldofpeace]

Was the breakage of the depreciated logind API intentional? I couldn't spot it in the change log, so maybe we should also check back with upstream systemd...

Yeah, and maybe just a revert of the breakage can be done instead of the entire update (I assume with deprecated API's it is always just code removed "cleanup").

[ttuegel]

it should probably be verified using systemd.package with a derivation before the update

This breaks the extra-utils derivation, probably something to do with copying libraries to the initrd. :frowning:

[ttuegel]

Was the breakage of the depreciated logind API intentional? I couldn't spot it in the change log, so maybe we should also check back with upstream systemd...

I've been poking around with qdbusviewer, and I can't even reproduce the breakage of the logind API; GetSessionByPID returns the correct session for me. :thinking:

[ttuegel]

Somebody on the Arch bug tracker isolated this change to systemd: https://github.com/systemd/systemd-stable/commit/8f8cc84ba4612e74cd1e26898c6816e6e60fc4e9

It seems that the problem is not just systemd, but the combination of systemd and SDDM.

EDIT: I dug into the systemd code some more. A significant finding is that the CanMultiSession property is _hidden_ after the commit above. I made a quick patch to un-hide the property; this is somewhat simpler than trying to revert the entire commit. Now I just have to rebuild my entire system.

[NinjaTrappeur]

I just digged into this issue. The problem is coming from the systemdentry module of plasma-workspace.

This applet was relying on the deprecated kdisplaymanager kde interface to detect the various entries (including switch user). As @ttuegel is suggesting in the previous message, kdisplaymanager is relying on the now hidden CanMultiSession property: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libkworkspace/kdisplaymanager.cpp#L622

This issue has been fixed upstream at 05414ed58d43d87d907326636faac53ae2e7bd60 which basically moves the systemdentry applet to the new sessionmanagement interface to detect the systemd entries.

The fix has been introduced to plasma-workspaces on the 17 of July. This patch is sadly absent from either plasma-workspace 5.18.5 (the one we're currently pinning) or the 5.18.6 version (the current 5.18 release). The fix is currently only available for the 5.19.90 plasma-workspace release.

To me, on the long term, it's clear we want to rely on this upstream fix to future proof the KDE<->systemd interface rather than patching our systemd derivation to force-expose a now defunct interface. However, as far as 20.09 is concerned, it's unclear to me what's the best course of action. I'm not really familiar enough with the KDE ecosystem to make a call here :/

So, as a TL;DR, 4 possible actions to fix this:

1. Apply @tteggel's patch suggestion on systemd. In that case I'd be in favor of doing that only on the stable branches and waiting to bump plasma-workspace for master. Let's not add more custom patch to our already heavily patched systemd derivation.
2. Bump plasma-workspace to 5.19.90 to benefit from the upstream fix. (Again, I'm not sure we can do that in such a short notice, it's up to the KDE maintainers to tell us whether this is realistic or not).
3. Patch our plasma-workspace derivation with 05414ed58d43d87d907326636faac53ae2e7bd60. This will require some manual intervention, the patch won't apply at all. The most relevant part to patch is the b/applets/kicker/plugin/systementry.cpp file.
4. Rollback to systemd 245.

Once we agree on the solution we want to pursue, I'm up to help on point 1 and 3. I'm sadly not familiar enough with KDE (I do not even use it) to be any help for point 2. Point 4 is my personal least favorite action here.

[ttuegel]

@NinjaTrappeur for the detailed analysis! :smiley:

To me, on the long term, it's clear we want to rely on this upstream fix to future proof the KDE<->systemd interface rather than patching our systemd derivation to force-expose a now defunct interface.

The commit to systemd says,

Backwards-compat is retained.

so it's not clear to me that the change is intentional. If my patch works for us, I would open an issue upstream, as backwards-compatibility was clearly not retained. In the long term (i.e. for the master branch) we will just update to Plasma 5.20 when that becomes available.

1. Bump plasma-workspace to 5.19.90 to benefit from the upstream fix. (Again, I'm not sure we can do that in such a short notice, it's up to the KDE maintainers to tell us whether this is realistic or not).

This is not an option, for several reasons:

1. Our stable branch version policy prohibits major version bumps.
2. Our stable branch version policy prohibits beta versions.
3. It's likely that plasma-workspace-5.19.90 can't be updated in isolation and we would probably have to bump the other Plasma packages on which it depends.

My preferences in order would be (3), (1), then (4). I should know by the end of the day if (1) is viable, and @NinjaTrappeur should know sooner if (3) is viable.

[NinjaTrappeur]

:+1: Thanks for stating the priorities, LGTM!

I think I managed to cherry pick https://invent.kde.org/plasma/plasma-workspace/-/commit/05414ed58d43d87d907326636faac53ae2e7bd60; at least the build did not fail. The option 3 is looking good so far. We now need to make sure it does fix the issue in practice :)

I'm building a virtuabox machine with this patch applied on top of the current nixpkgs master. It's taking a while. I'll let you know how it goes when it's done.

[NinjaTrappeur]

Well, the build ended just after I posted the previous message.

Good news, the option 3. is working. :tada:

I'm gonna open a PR shortly.

[NinjaTrappeur]

PRd the solution 3. there: https://github.com/NixOS/nixpkgs/pull/99582

We probably want to backport this to 20.09.

[ttuegel]

I tested #99582; it does not fix the lock screen, so I am going to resume rebuilding and testing the systemd patch.

[ttuegel]

The systemd patch fixes the lock screen and the launcher; I will open a pull request momentarily.

[worldofpeace]

yay https://github.com/NixOS/nixpkgs/pull/99629 fixed this

[jonringer]

I know that this seems to be fixed for >=5.19, but should any upstream sources be notified?

[NinjaTrappeur]

I'm not 100% sure 5.19 will fix the lockscreen issue. I think we should report that to upstream.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/marketing-team-can-we-present-nix-nixos-better/6249/106

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/what-should-stable-nixos-prioritize/9646/1