Anybody got these working on Obarun? Installing pm-utils connects all power functions inside of KDE but SDDM is not KDE.
Whatever I put into "HaltCommand" or "RebootCommand" in /etc/sddm.conf.d/sddm.conf or the KDE generated /etc/sddm.conf or through the system settings dialog (which really just writes to /etc/sddm.conf) it will not activate any power related button (in themes we usually enable/disable these with a check on sddm.canReboot and sddm.canPowerOff respectively). So basically SDDM is telling my themes that it cannot power off...

  • [deleted]

  • Post #2
Hello marianarlt

I'm not sure to understand. Do you mean that you do not have the power and reload buttons on SDDM ?
Yes Jean-Michel, although technically not correct (because I do "have" them), you could say that.
Technically correct would be to say that the buttons do not change their Qt property responsible to take them out of a disabled state: 
powerButton {
    enabled: sddm.canPowerOff
}
But the issue is with the internals of SDDM not setting this boolean on my system and I don't know why.

As a further note: my system is based on a minimal installation. So maybe I'm missing some dbus connector? dbus-user is for users,...SDDM is a root application, so I guess I can discard that one. As mentioned I have pm-utils installed to make KDE connect the power functions that would usually be provided by systemd calls, but SDDM is a separate program. I'm on a loss.

My root tree is rather basic: 
               root           
Initialized: yes | Current: yes
Contains:       | Enabled: yes
├─(980,Enabled,longrun) dbus-log
├─(950,Enabled,classic) tty1
├─(951,Enabled,classic) wpa_supplicant-log
├─(979,Enabled,longrun) networkmanager-log
├─(952,Enabled,classic) tty2
├─(0,Enabled,classic) wpa_supplicant
├─(961,Enabled,longrun) scandir-marian
├─(984,Enabled,longrun) dbus
├─(978,Enabled,longrun) sddm-log
├─(992,Enabled,longrun) sddm
└─(993,Enabled,longrun) networkmanager

  • [deleted]

  • Post #4
Everything before was working as expected on your side ?

On my side I spent a lot of time, three month ago trying to solve problems with - power/reload/hibernation buttons - but without any success. I think it's because of ConsoleKit, and it's not the only one problem I got with it and SDDM but also with ConsoleKit and KDE with the inability to mount an external drive from the notification bar.

Finally I solved all of these problems, but the answer will not please you. ^ ^
Well, "everything before" depends, does it? ;) Everything works fine and as as expected, except SDDM and it's stupid buttons X)
I mean seriously, I can easily live without them if it was too much of a hassle ;D

I suppose you refer to your special-Obarun-spin you published here on the forums? ;) I'm ok with things how they are at the moment, but I thought I'd ask. Probably also interesting for anybody else.

If we have the same mounting issue that can be worked around by clicking on the little arrow icon in the notification pop up dialog instead of clicking on the name of the device. I for myself was missing functionality of power buttons, network management and some plugins in KDE which have been remedied by just installing pm-utils.
I assume your reboot and shutdown are reboot and poweroff, and sddm-66serv is active.
Who are the owners of /var/lib/sddm, there may be an issue with sddm:sddm as user:group

  • [deleted]

  • Post #7
I mean seriously, I can easily live without them if it was too much of a hassle ;D
Yes you can live without them, but I have some sort of disease of perfection and I could not accept that anymore.
If we have the same mounting issue ...
On KDE when I plugged in for exemple an USB pendrive, KDE Device notifier appeared but I was unable to mount the USB pendrive clicking on " Open with file manager ".

  • [deleted]

  • Post #8
I assume your reboot and shutdown are reboot and poweroff, and sddm-66serv is active.
I use "shutdown -P now" instead of "poweroff". I don't remember why I made this choice instead of poweroff ... 
             desktop          
Initialized: yes | Current: no
Contains:       | Enabled: yes
├─(765,Enabled,classic) networkmanager-log
├─(766,Enabled,classic) networkmanager
├─(785,Enabled,longrun) dbus-log
├─(789,Enabled,longrun) dbus
├─(767,Enabled,classic) sddm-log
├─(770,Enabled,classic) sddm
├─(768,Enabled,classic) .......-log
└─(825,Enabled,classic) .......
Who are the owners of /var/lib/sddm
sddm:sddm
/var/lib/sddm is naturally owned by sddm:sddm
That's default isn't it? The 66 sddm service is indeed enabled and initialized as mentioned above. reboot and shutdown are by default symlinked to /etc/66/* 
marian@ obarun ~ % ls -la /usr/bin
lrwxrwxrwx 1 root root 16 May 15 05:18 /usr/bin/poweroff -> /etc/66/poweroff*
lrwxrwxrwx 1 root root 14 May 15 05:18 /usr/bin/reboot -> /etc/66/reboot*
lrwxrwxrwx 1 root root  16 May 15 05:18 /usr/bin/shutdown -> /etc/66/shutdown*
marian@ obarun ~ % ls -la /etc/66
-rwxr-xr-x  1 root root  452 May 15 05:18 poweroff*
-rwxr-xr-x  1 root root  451 May 15 05:18 reboot*
-rwxr-xr-x  1 root root  809 May 15 05:18 shutdown*
See anything weird here?

Haha Jean, I get you, that's exactly why I'm asking anyways :P
As mentioned, the mounting issue can simply be avoided by NOT clicking "Open with file manager" but INSTEAD clicking the little mounting icon on the right hand side in the popup. (weirdly enough...)

  • [deleted]

  • Post #10
Mmm, that really weird. For my sddm and networkmanager, @ type is defined as longrun but 66-info -T as you can see, show them as classic service! Something wrong

EDIT: Everything is fine with my VM, a clone of my main system. Well, I will have to do some research on the cause of this problem.
As mentioned, the mounting issue can simply be avoided by NOT clicking "Open with file manager" but INSTEAD clicking the little mounting icon on the right hand side in the popup. (weirdly enough...)
Ho ! That something I didn't know and did not try. It's crazy , lol
Woah didn't even notice that. Indeed weird. But actually not true on my system either: 
               root           
Initialized: yes | Current: yes
Contains:       | Enabled: yes
├─(895,Enabled,longrun) dbus-log
├─(865,Enabled,classic) tty1
├─(867,Enabled,classic) wpa_supplicant-log
├─(893,Enabled,longrun) networkmanager-log
├─(866,Enabled,classic) tty2
├─(0,Enabled,classic) wpa_supplicant
├─(876,Enabled,longrun) scandir-marian
├─(899,Enabled,longrun) dbus
├─(891,Enabled,longrun) sddm-log
├─(907,Enabled,longrun) sddm
└─(908,Enabled,longrun) networkmanager
I had a bad service earlier which I just deleted. I guess that made some things appear wrong.

Behavior is the same though.

  • [deleted]

  • Post #12
Symlinks are the same on my side

Well, everything is back to the normal with my sddm and networkmanager. 66-tools are really awesome. Can disable and enable the services without disturbing the network or sddm. Awesome.
             desktop          
Initialized: yes | Current: no
Contains:       | Enabled: yes
├─(785,Enabled,longrun) dbus-log
├─(789,Enabled,longrun) dbus
├─(0,Enabled,longrun) networkmanager-log
├─(0,Enabled,longrun) networkmanager
├─(0,Enabled,longrun) sddm-log
├─(0,Enabled,longrun) sddm
├─(768,Enabled,classic) .......-log
└─(825,Enabled,classic) .......
Mhmmm congratulations ^^; I'm still fighting.
SDDM source file PowerManager.cpp: 
    /**********************************************/
    /* LOGIN1 && ConsoleKit2 BACKEND              */
    /**********************************************/

const QString LOGIN1_SERVICE = QStringLiteral("org.freedesktop.login1");
const QString LOGIN1_PATH = QStringLiteral("/org/freedesktop/login1");
const QString LOGIN1_OBJECT = QStringLiteral("org.freedesktop.login1.Manager");

const QString CK2_SERVICE = QStringLiteral("org.freedesktop.ConsoleKit");
const QString CK2_PATH = QStringLiteral("/org/freedesktop/ConsoleKit/Manager");
const QString CK2_OBJECT = QStringLiteral("org.freedesktop.ConsoleKit.Manager");

    class SeatManagerBackend : public PowerManagerBackend {
    public:
        SeatManagerBackend(const QString & service, const QString & path, const QString & interface) {
            m_interface = new QDBusInterface(service, path, interface, QDBusConnection::systemBus());
        }

        ~SeatManagerBackend() {
            delete m_interface;
        }

        Capabilities capabilities() const {
            Capabilities caps = Capability::None;

            QDBusReply<QString> reply;

            // power off
            reply = m_interface->call(QStringLiteral("CanPowerOff"));
            if (reply.isValid() && (reply.value() == QLatin1String("yes")))
                caps |= Capability::PowerOff;

            // reboot
            reply = m_interface->call(QStringLiteral("CanReboot"));
            if (reply.isValid() && (reply.value() == QLatin1String("yes")))
                caps |= Capability::Reboot;
Anyone? ^_^;;;
There's actually a upower backend block above this one, which by default comes installed with Obarun.
Also I read this comment on Reddit:
The goal of elogind is to provide a D-Bus api compatible with org.freedesktop.login1. So I would personally go that way to avoid the need of recompiling everything. You could have a look at the elogind package created by devuan and install it on debian
I cannot make any sense of all this >_>"
Also there's apparently interest in SDDM with consolekit but I guess I'm out of luck with this one.

Also I'm reading here in a discussion on slackware from October 2018:
bassmadrigal wrote ConsoleKit2's implementation of logind doesn't provide a login1 D-Bus service,
So after all SDDM couldn't even be blamed really as back in 2014 they were all like "we go systemd onry now" and ConsoleKit2 support has been implemented still.

  • [deleted]

  • Post #14
This is now about 2 years there is no activity on ConsoleKit2 and it seems that no one want to continue to maintain it. It's certainly a shame, but elogind (which is not systemd init ) is doing very well the job now and personally it saved me more than two times ( eloginctl ) after an update of Qt/KDE when I was unable to use the KDE reboot/logout icons.
By the way, I do not find it normal that an update can breaks things like that ...
Tough decision. I also had no KDE power functions I'm telling you, but that was because KDE dropped upower dropped support. So just for fun I installed pm-utils (even more outdated and not being worked on for yeeears) and all of a sudden everything popped up. It even fixed networkmanager...

What do you mean by update?

  • [deleted]

  • Post #16
What do you mean by update?
pacman -Syu from KDE.

and some updated Qt/KDE packages that break the possibility to use logout/reboot icons from KDE.
Yeah well it's a difficult situation with KDE. No doubts about that. Actually I'm looking at ConsoleKit2 right now and the last merged pull request is from October 2017 O_O" That's not good news either ;_;

  • [deleted]

  • Post #18
Actually I'm looking at ConsoleKit2 right now and the last merged pull request is from October 2017 O_O" That's not good news either ;_;
Yes, I know that, I spent a long long time, to find some good news about Consolekit2 and trying to adapt it for our use case. But also trying to find if someone had forked the project to improve it for today's use in 2019, nothing ...
Really, the choice I made has been carefully considered.
poweroff -p or shutdown -p asks the user to verify before executing.
sudo poweroff would ask for password but no verification.
If you add sddm to wheel, then on sudoers enable run root commands without password then either
sudo reboot / sudo poweroff on sddm.conf would execute, or make /usr/local/bin new commands to use in sddm

That would work but it is a dirty insecure solution.
That's indeed a workaround fungal. But to be honest I'd rather miss out on being able to reboot from a DM :D
(They're hardly ever used by anybody anyways)
And I understand your point Jean-Michel.

Powered by Obarun