Bug 314989 - Screen locker won't unlock/deactivate using dbus
Summary: Screen locker won't unlock/deactivate using dbus
Status: RESOLVED NOT A BUG
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: locker-qml (show other bugs)
Version: 4.10.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-12 12:58 UTC by Maciej J . Woloszyk
Modified: 2020-10-21 02:59 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0


Attachments
Unlock via dbus with SetActive(false) (2.38 KB, patch)
2014-04-02 21:43 UTC, Kirill Elagin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej J . Woloszyk 2013-02-12 12:58:46 UTC
I'm using a simple script monitoring my phone's bluetooth presence to lock the computer when I'm away. It worked just fine until yesterday when I updated KDE to 4.10.0. In my script I use qdbus and I lock screen with:
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

To unlock I use:
qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive false

It worked without a problems for at least two years and a few KDE updates. In 4.10.0 however locking works but unlocking does nothing - just returns 'false'.


Reproducible: Always

Steps to Reproduce:
1. Open konsole and enter
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock ; sleep 5s ; qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive false

Actual Results:  
Screen locks, unlocker screen shows, nothing else happens - you need to unlock by hand.

Expected Results:  
Screen should lock to your screensaver then after 5 seconds it should unlock without password
Comment 1 Shane Mc Cormack 2013-03-03 23:19:48 UTC
It's not pretty, but as an interim solution until this is fixed, you can do something like this:

qdbus | grep kscreenlocker | sed 's/org.kde.//' | xargs kquitapp
Comment 2 m1st0 2013-05-16 17:35:52 UTC
From looking into the last command, the challenge is that the new screenlocker in 4.10 includes the PID for its instance.

In other words, each time it is launched it seems to me that it will be a new name to kill or call quit on using qdbus:
org.kde.kscreenlocker_greet-{some PID}

I found the following successful as well to unlock the system using blueproximity:

qdbus | grep kscreenlocker_greet | xargs -I qdbus {} /MainApplication quit

Similar to the old way, just having a need to find the name itself.  Shane's version just as well may work.
Comment 3 m1st0 2013-05-16 17:45:51 UTC
(In reply to comment #2)
> From looking into the last command, the challenge is that the new
> screenlocker in 4.10 includes the PID for its instance.
> 
> In other words, each time it is launched it seems to me that it will be a
> new name to kill or call quit on using qdbus:
> org.kde.kscreenlocker_greet-{some PID}
> 
> I found the following successful as well to unlock the system using
> blueproximity:
> 
> qdbus | grep kscreenlocker_greet | xargs -I qdbus {} /MainApplication quit
> 
> Similar to the old way, just having a need to find the name itself.  Shane's
> version just as well may work.

* Sorry I forgot to include the following for xargs:

qdbus | grep kscreenlocker_greet | xargs -I {} qdbus {} /MainApplication quit
Comment 4 Chazz 2013-10-02 12:03:58 UTC
I have a separate machine that I use synergy to control and was using a script to unlock the screensaver using the SetActive/SimulateUserActivity method.  This also broke for me but Shane McCormack's solution worked for me as a workaround.  I just used a different variant but same result.

    qdbus | perl -ne 'qx/kquitapp $1/ if /(kscreenlocker_greet-\d+)/'

I hope this gets fixed soon because the old method was much cleaner in my opinion.
Comment 5 Kirill Elagin 2014-03-29 09:20:13 UTC
I can also confirm this.
KDE 4.11.5.
Comment 6 Kirill Elagin 2014-03-29 09:46:36 UTC
So, seems that the commit in question is a7d599fda6c6e2798c444556f62c46f6512f79c8.

The commit message states that “Most parts are not yet implemented as it either does not make sense (e.g. setActive(false)) …”. I think, that's arguable.
Comment 7 Martin Flöser 2014-03-31 07:01:04 UTC
The correct way to implement custom unlock functionality is by providing a custom greeter theme which does that (c.f. Plasma Active lock screen). That it is possible to end kscreenlocker_greet is clearly a bug.
Comment 8 Murz 2014-04-01 05:02:45 UTC
Some apps don't need custom greeter theme, they must do unlock action on any lock screen or theme. For example, unlocking via bluetooth proximity - this app must do unlock action for any lock screen, because it not provide new greeter theme, it provide comfortable way to unlocking computer. 
How apps like this must do unlock screen action if kscreenlocker_greet is clearly a bug?
Comment 9 Martin Flöser 2014-04-01 05:41:58 UTC
> Some apps don't need custom greeter theme, they must do unlock action on any
> lock screen or theme. For example, unlocking via bluetooth proximity - this
> app must do unlock action for any lock screen, because it not provide new
> greeter theme, it provide comfortable way to unlocking computer.
> How apps like this must do unlock screen action if kscreenlocker_greet is
> clearly a bug?

What about having a PAM module? kscreenlocker_greet is not doing 
authentication, it delegates this to PAM, thus any authentication mechanism 
needs to go into PAM.
Comment 10 Murz 2014-04-01 05:45:10 UTC
Thanks for quick answer. As I understand, PAM modules do the authentication process on user login, so for example user on login can skip password entering. But I don't understand how we can via PAM module do unlock screen action.

Can you describe or provide link to some example how PAM module can do the action "Unlock KDE screen and unload screensaver"?
Comment 11 Kirill Elagin 2014-04-01 06:47:47 UTC
That's, actually, what I was suggesting on the reviewboard.

You can have a PAM module, that will accept authentication based on your bluetooth device proximity (or USB drive being plugged in, etc). So this way, when you hit Enter on your lockscreen, as currently lockscreen checks auth through PAM, if your PAM modules is installed and properly configured, it will let you in. So, you just have to hit Enter, without entering your password.

The next step is adding DBus interface to screenlocker, that will provide a method, basically, HitEnter.

So, this is how it works: then your token becomes available, someone (e.g. udev in case of usb drive, or bluetooth daemon in case of BT token) calls this method, and Enter is automatically pushed. And since the token is here, your PAM module will let you in.
Comment 12 Martin Flöser 2014-04-01 07:35:42 UTC
> So, this is how it works: then your token becomes available, someone (e.g.
> udev in case of usb drive, or bluetooth daemon in case of BT token) calls
> this method, and Enter is automatically pushed. And since the token is
> here, your PAM module will let you in.

this is something which might even be done by the greeter itself. By e.g. 
mapping a list of devices which are allowed to trigger the authentication. I'd 
prefer to have this properly integrated in the locker than exposing internal 
details through DBus.
Comment 13 Kirill Elagin 2014-04-01 08:25:54 UTC
(In reply to comment #12)
> exposing internal details through DBus.

I can't agree that asking the locker to try to check authentication is an internal detail.
In this case making the user enter his password and click “unlock” is also forcing him to use an internal detail of the locker.

I just got an even better idea. Using this, we can make sense of `SetActive(false)`. That is, we just make `SetActive(false)` “hit enter”. This way, maybe other lockers will also adopt this notion of “trying to deactivate the locker”.
Integrating this functionality into the greeter looks worse simply because it's not that flexible.
Comment 14 Martin Flöser 2014-04-01 09:57:20 UTC
> I can't agree that asking the locker to try to check authentication is an
> internal detail.

Yes it is, as the locker doesn't check the authentication, it's the greeter. 
But the greeter should not be exposed to DBus.

FYI: I have locally a variant which supports logind. This means if logind 
emits the Unlock signal, the screenlocker will unlock. That should be a 
sufficient solution for this bug report.
Comment 15 Martin Flöser 2014-04-02 09:05:47 UTC
(In reply to comment #14)
> FYI: I have locally a variant which supports logind.

Review Request for logind integration
Comment 16 Shane Mc Cormack 2014-04-02 21:17:34 UTC
Hi,

I strongly  disagree that the ability to stop the screensaver programatically should be considered to be a bug.

This functionality has existed since KDE3 days, (`dcop kdesktop KScreensaverIface quit`) then more recently as `qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive False` (http://lists.freedesktop.org/archives/xdg/2007-March/009187.html) and then in 4.10 the new screensaver/greeter was introduced which removed the nice and standard way of doing it (Other screensavers for example gnome-screensaver still allow SetActive false on org.freedesktop.ScreenSaver last time I checked) but at least still allowed unlocked with a bit of fiddling.

My current use for this functionality is a script that is activated by udev when my phone is connected to the computer (via a desktop dock). Udev fires the event based on the usb parameters, and then my script validates that it is actually *my* phone that is connected and not a similar model, and then unlocks the screen.

Similarilly the reverse happens when the phone is undocked, the screen locks.

This is nice and straight forward to implement, can be done in any language of choice and work{s,ed} with Gnome, KDE, or anything else which implements the freedesktop api properly 

> What about having a PAM module?
Needing to write a custom PAM module is not as straight forward and simple or as flexible, and would instead of just checking the one device that was plugged in, would require enumerating all the devices and checking if they are valid. (Using something like https://github.com/jeroennijhof/pam_script would get rid of the first problem, but still not the second)

> The correct way to implement custom unlock functionality is by providing a custom greeter theme
Writing a custom greeter is an even less desireable approach as it becomes very specific to KDE >4.10.

> mapping a list of devices which are allowed to trigger the authentication.
Having support for this in the locker is great, but still removes the ability to have a nice generic solution that works regardless of which desktop environment is currently in use.


- Shane
Comment 17 Kirill Elagin 2014-04-02 21:43:14 UTC
Created attachment 85920 [details]
Unlock via dbus with SetActive(false)

I'll just leave the patch here for those who might need it.

BTW, this logind thing seems somewhat reasonable. Here is how I see it:
One's custom daemon watches for specific event (phone attached, USB drive plugged-in, etc.), checks the contents of the drive, and determines its owner, checks owner's config and, if it decides that this kind of authentication is valid, enumerates all the sessions of this user and tells logind to Unlock them. This is proper multi-seat (multi-session, etc.)
One issue here is that the `Session.Unlock` method is annotated with `@org.freedesktop.systemd1.Privileged("true")`, i.e. only root processes are allowed to call it.
Comment 18 m1st0 2014-04-02 21:52:42 UTC
This may not be useful since this is marked as for 4.10.  I am on 4.12.3.  Running the following command has errors alongside logging me out of my system if I run it in a terminal, but running it with BlueProximity ( http://blueproximity.sourceforge.net/ ) I have found success with unlocking when I am close with my bluetooth device, locking when I walk far enough away, and keeping my system from locking out otherwise.  The options I use for it to run are:

Locking command:  qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
Unlocking command:  qdbus | grep kscreenlocker_greet | xargs -I {} qdbus {} /MainApplication quit
Proximity command:  qdbus org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity

The only issue that brought me here was that "qdbus" run on a terminal session resulted in a incorrectly set Qt5 version that broke everything.  Once I set it to the right Qt version that matched my KDE install, it worked out again.

On my system, qdbus was symlinked to "/usr/bin/qdbus -> qtchooser" .  I ran "qtchooser" to fix my issues with the wrong Qt version.  This may be of no help to you, but it worked for me in getting some way to write up scripts and rules using qdbus to lock/unlock the system.  I would be interested in adding the "udev" device connect triggers with "@Shane Mc Cormack" 's examples.
Comment 19 Kirill Elagin 2014-04-02 22:07:12 UTC
FYI (offtopic)
You are always free to ude `dbus-send` instead of `qdbus` or whatever. Like this:

$ dbus-send --session --type=method_call --dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.Lock
$ dbus-send --session --type=method_call --dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.SetActive boolean:false
Comment 20 Martin Flöser 2014-04-03 05:24:52 UTC
> This functionality has existed since KDE3 days, (`dcop kdesktop
> KScreensaverIface quit`) then more recently as `qdbus
> org.freedesktop.ScreenSaver /ScreenSaver SetActive False`
> (http://lists.freedesktop.org/archives/xdg/2007-March/009187.html) and then
> in 4.10 the new screensaver/greeter was introduced which removed the nice
> and standard way of doing it (Other screensavers for example
> gnome-screensaver still allow SetActive false on
> org.freedesktop.ScreenSaver last time I checked) but at least still allowed
> unlocked with a bit of fiddling.

Please note that this is not a screensaver, but a screen locker. The 
screensaver mixed up visuals and authentication bits. We cleaned that up and 
made the new locker only about security. Pieces belonging to the saver were 
removed. Our interpretation was that setActive is about the screen saver and 
not the locker. That is the false is for ending the saver but not the locker. 
In the old world the saver was about two things:
* protecting the CRT screen
* locking the screen

These things were not bound together. Thus one could have saving the screen 
(after idle) without locking the screen. In this case the setActive(false) 
makes sense.

The new implementation only cares about locking the screen. Thus the 
setActive(false) does not make sense. In that regard it is irrelevant that 
older versions supported it (as they were screen savers) and also that other 
screen saver implementations support it is irrelevant.

I'm sorry that this broke your workflow.

> 
> My current use for this functionality is a script that is activated by udev
> when my phone is connected to the computer (via a desktop dock). Udev fires
> the event based on the usb parameters, and then my script validates that it
> is actually *my* phone that is connected and not a similar model, and then
> unlocks the screen.
> 
> Similarilly the reverse happens when the phone is undocked, the screen
> locks.
> 
> This is nice and straight forward to implement, can be done in any language
> of choice and work{s,ed} with Gnome, KDE, or anything else which implements
> the freedesktop api properly

And thus logind support will be even better for you.
Comment 21 Martin Flöser 2014-04-07 05:32:52 UTC
Git commit 447703ee86fa5f4751e7089cb9ab3976ede952a8 by Martin Gräßlin.
Committed on 02/04/2014 at 08:55.
Pushed by graesslin into branch 'master'.

Add logind integration to screenlocker

A new class LogindIntegration is added to the screenlocker. This class
listens to the Lock and Unlock signals emitted by the session object on
the logind service.

This is integrated with the screenlocker application to start or quit the
lock when the signals are emitted. This means a locked screen is unlocked
when the Unlock signal is received from logind. Logind is a higher
authority for the screenlocker and thus follows the requests from logind.
REVIEW: 117355

M  +5    -1    ksmserver/screenlocker/CMakeLists.txt
A  +15   -0    ksmserver/screenlocker/autotests/CMakeLists.txt
A  +72   -0    ksmserver/screenlocker/autotests/fakelogind.cpp     [License: GPL (v2)]
A  +72   -0    ksmserver/screenlocker/autotests/fakelogind.h     [License: GPL (v2)]
A  +99   -0    ksmserver/screenlocker/autotests/logindtest.cpp     [License: GPL (v2)]
M  +18   -1    ksmserver/screenlocker/ksldapp.cpp
A  +121  -0    ksmserver/screenlocker/logind.cpp     [License: GPL (v2)]
A  +59   -0    ksmserver/screenlocker/logind.h     [License: GPL (v2)]

http://commits.kde.org/plasma-workspace/447703ee86fa5f4751e7089cb9ab3976ede952a8
Comment 22 Murz 2014-04-07 07:05:45 UTC
 Martin Gräßlin, thanks for fixing this issue! But can you describe here (for me and other subscribers and visitors) some example how we can now send via cli unlock signal to screen locker?
Comment 23 Martin Flöser 2014-04-07 07:17:01 UTC
> But can you describe here
> (for me and other subscribers and visitors) some example how we can now
> send via cli unlock signal to screen locker?

please see: 
man loginctl

which explains it much better than I could
Comment 24 Kirill Elagin 2014-04-07 07:26:42 UTC
Murz, let me do this.

First you have to find your current session. There is a number of ways to do this, but probably the easiest one is to query logind by your pid. You do this by calling `org.freedesktop.login1.Manager.GetSessionByPID`:

# qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 GetSessionByPID "$$" | cut -d ' ' -f 2 | head -c '-2'
/org/freedesktop/login1/session/c3

logind gives you an object path and now you call `org.freedesktop.login1.Session.Lock` on this object:

> qdbus --system org.freedesktop.login1 /org/freedesktop/login1/session/c3 Lock

And that's it. The only drawback is that you have to do this as root.
Comment 25 Murz 2014-04-07 07:46:05 UTC
Kirill Elagin, thanks for the examples! I will wait this updates in next KDE release and check this.
Comment 26 Christoph Feck 2014-04-20 19:09:23 UTC
Martin, can/should this be backported to 4.11? Please set the "Version-Fixed-In" field.
Comment 27 Martin Flöser 2014-04-21 17:44:16 UTC
(In reply to comment #26)
> Martin, can/should this be backported to 4.11?

The code uses new Qt 5 features (e.g. lambda slots) and thus I think it's not justified to backport to 4.11.
Comment 28 Emre 2014-09-22 21:36:24 UTC
Hi,

I found this bug report when I was trying to get the unlock part work with blueproximity. I'm on Kubuntu 14.04, KDE 4.13.3. 

The command:
sudo qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 GetSessionByPID "$$" | cut -d ' ' -f 2 | head -c '-2'
returns the output: 
/org/freedesktop/login1/session/c8

But when I enter it into the next command:
emre@emre-nb:~$ sudo qdbus --system org.freedesktop.login1 /org/freedesktop/login1/session/c8 Lock

emre@emre-nb:~$ 

Nothing happens, no locking. If I try without sudo, I get Error: org.freedesktop.DBus.Error.AccessDenied

If I try by being root (su), and then put the command, same result as sudo.

What's wrong?
Comment 29 Martin Flöser 2014-09-23 05:26:52 UTC
logind integration is only available in 5.x
Comment 30 Luke-Jr 2016-10-02 04:30:38 UTC
How do I unlock my screen in KDE 5 without systemd/logind ugliness?
Comment 31 Martin Flöser 2016-10-04 05:32:57 UTC
(In reply to Luke-Jr from comment #30)
> How do I unlock my screen in KDE 5 without systemd/logind ugliness?

There is also support for consolekit2, though I don't know how to use that.
Comment 32 Luke-Jr 2016-10-04 05:39:20 UTC
Could we just add a dbus Unlock method?
Comment 33 Martin Flöser 2016-10-04 06:14:00 UTC
(In reply to Luke-Jr from comment #32)
> Could we just add a dbus Unlock method?

No! That would allow any unprivileged application to unlock the lock screen. The lock screen is there to prevent that. Only a privileged action is allowed to unlock it. This are entering the password or using logind/consolekit as an external (higher privileged) authority.
Comment 34 Luke-Jr 2016-10-04 06:25:18 UTC
Don't applications need user privileges to call dbus commands in the first place? If they have dbus access, they can access anything else already, or even ptrace ksmserver to shut it off the hard way. No?
Comment 35 Martin Flöser 2016-10-04 06:56:29 UTC
(In reply to Luke-Jr from comment #34)
> Don't applications need user privileges to call dbus commands in the first
> place? If they have dbus access, they can access anything else already,

so what? What does an insecurity in another area say that we should make the lock screen insecure?

> or
> even ptrace ksmserver to shut it off the hard way. No?

Good point: ksmserver needs ptrace protection like it's already the case in kwin_wayland (which holds the lockscreen in the Wayland session). But again: a vulnerability in another area is not an argument to add a vulnerability in another area. We want to fix that mess.
Comment 36 Luke-Jr 2016-10-04 13:43:07 UTC
An application executing with user privileges is considered equivalent to the user. That's the way *nix security is designed, and while I agree it could probably use some improvement, the GUI shouldn't be the part trying to change the system's security model, but simply respect it.
Comment 37 Martin Flöser 2016-10-04 14:22:25 UTC
Can we please stop that? We won't do the change you want. There is a good enough replacement with logind and consolekit.
Comment 38 Luke-Jr 2016-10-04 14:38:37 UTC
Stop what, exactly? Reporting regressions in KDE? Commenting on desirable behaviour? Using KDE at all? (I'm sure if enough users get told off, eventually there will be enough interest in a fork and/or alternative Qt desktop environment...)
Comment 39 Martin Flöser 2016-10-04 15:15:00 UTC
Stop the useless discussion. There is a way to unlock the lockscreen through dbus. There won't be another one added.
Comment 40 Luke-Jr 2016-10-04 15:23:49 UTC
> There is a way to unlock the lockscreen through dbus.

Ok, I missed this point entirely. Sorry for the useless discussion. What is the current way to do this?
Comment 41 Martin Flöser 2016-10-05 05:27:41 UTC
(In reply to Luke-Jr from comment #40)
> > There is a way to unlock the lockscreen through dbus.
> 
> Ok, I missed this point entirely. Sorry for the useless discussion. What is
> the current way to do this?

E.g. with logind it's
qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSession <sessionId>

The sessionId can also be queried through DBus, I kindly ask to check logind documentation for it. I don't know how to do it with consolekit, though.
Comment 42 Luke-Jr 2016-10-05 05:55:49 UTC
Sigh, systemd and Consolekit are not dbus.
Comment 43 Martin Flöser 2016-10-05 07:15:32 UTC
(In reply to Luke-Jr from comment #42)
> Sigh, systemd and Consolekit are not dbus.

see and that's the stupid discussion which you should stop to do. I just gave you a dbus command which will unlock the session. That's what you asked for. It's dbus. Who implements the interface is completely irrelevant. You can even write a small tool which does nothing else than to emit the dbus signal the lockscreen listens to if you want. Can all be done without using systemd or consolekit. It's all pure dbus - check the code, it only interacts with dbus.
Comment 44 Luke-Jr 2016-10-05 07:39:03 UTC
Service 'org.freedesktop.login1' does not exist.
Comment 45 Martin Flöser 2016-10-05 07:43:00 UTC
(In reply to Luke-Jr from comment #44)
> Service 'org.freedesktop.login1' does not exist.

As I said just above: you can write your own small tool which implements it. That's what we did in the unit tests: https://quickgit.kde.org/?p=kscreenlocker.git&a=blob&h=7266d4a0ba1b7a0ff6ddba62fec55ef752a8cd37&hb=d20449d80bf5e0efc2abd232af01ed59f3723acb&f=autotests%2Ffakelogind.cpp - feel free to use that class, create your own tool out of it and start it.
Comment 46 Luke-Jr 2020-10-19 20:26:51 UTC
Okay, Gentoo is finally forcing me to install a logind. But this still doesn't work.

# sudo qdbus --literal --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.GetSessionByPID "$$"
Error: org.freedesktop.login1.NoSessionForPID
PID 59957 does not belong to any known session
# loginctl 
No sessions.
Comment 47 David Edmundson 2020-10-19 20:31:30 UTC
GetSessionByPID is known to be broken. 
That's not a KDE issue, we don't write logind. See systemd

Or just use loginctl directly.

or use /org/freedeskto/login1/session/auto
Comment 48 m1st0 2020-10-20 09:05:52 UTC
Simple enough now using loginctl as a privileged user for example:

    sudo loginctl lock-sessions; sleep 3
    sudo loginctl unlock-sessions

Therefore without specifically needing to call with sudo, you can easily write up a systemd service to lock or unlock as needed. Further logic can be added for specific sessions, conditions, etc.
Comment 49 m1st0 2020-10-20 09:16:32 UTC
Sorry, missed mentioning examples for your own session:

    loginctl lock-session; sleep 3
    loginctl unlock-session

Use as needed.
Comment 50 Luke-Jr 2020-10-20 13:21:48 UTC
$ loginctl lock-session
Failed to issue method call: Is a directory
$ loginctl unlock-session
Failed to issue method call: Is a directory
Comment 51 m1st0 2020-10-21 02:36:14 UTC
(In reply to Luke-Jr from comment #50)
> $ loginctl lock-session
> Failed to issue method call: Is a directory
> $ loginctl unlock-session
> Failed to issue method call: Is a directory

I tried to look up any obvious differences in my setup. This works on Ubuntu 20.04.1.  Depending on your setup, this seems to be a systemd setup issue.  Others show the following although not related: https://www.reddit.com/r/archlinux/comments/bl9vcf/loginctl_no_such_file_or_directory/
Comment 52 Luke-Jr 2020-10-21 02:59:09 UTC
I don't (and hope to never) use systemd... elogind is what I finally let Gentoo install.

I also don't like/use any fancy session management. Just CLI login and startx.