Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-23 16:53:06 +0200, Michael Biebl wrote:
> Am 23.05.20 um 02:59 schrieb Vincent Lefevre:
> > On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
> >> This is strange. Something is triggering the start of systemd-logind
> > 
> > What do you mean by "start of systemd-logind"?
> > 
> > On my machine, systemd-logind is started early at boot time and
> > never quits.
> 
> You said:
> 
> > The running instance cannot be stopped as it is automatically
> > restarted. 
> 
> when I adviced you to stop the running systemd-logind.service and
> starting logind by hand.

OK, if I do "service systemd-logind stop", it is effectively
stopped. Then I start

  SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

from VT 1. I log in on VT 2, start the inhibitor and log out, then
I close the lid. Nothing happens. Then I switch to VT 3, and the
system suspends immediately. So, same issue. In the logs:

May 24 23:12:50 zira dhclient[2527]: DHCPREQUEST for 192.168.1.3 on eth0 to 
192.168.1.1 port 67
May 24 23:12:50 zira dhclient[2527]: DHCPACK of 192.168.1.3 from 192.168.1.1
May 24 23:12:50 zira root[568208]: 
/etc/dhcp/dhclient-enter-hooks.d/google-tcp-dns with reason=RENEW
May 24 23:12:50 zira root[568219]: 
/etc/dhcp/dhclient-exit-hooks.d/0google-tcp-dns with reason=RENEW
May 24 23:12:50 zira dhclient[2527]: bound to 192.168.1.3 -- renewal in 33912 
seconds.
May 24 23:13:09 zira login[158128]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 23:13:12 zira login[158128]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 24 23:13:12 zira login[158128]: pam_unix(login:session): session opened for 
user vinc17 by LOGIN(uid=0)
May 24 23:13:12 zira systemd[1]: Created slice User Slice of UID 1000.
May 24 23:13:12 zira systemd[1]: Starting User Runtime Directory 
/run/user/1000...
May 24 23:13:12 zira systemd[1]: Finished User Runtime Directory /run/user/1000.
May 24 23:13:12 zira systemd[1]: Starting User Manager for UID 1000...
May 24 23:13:12 zira systemd[568233]: pam_unix(systemd-user:session): session 
opened for user vinc17 by (uid=0)
May 24 23:13:12 zira systemd[568238]: gpgconf: error running 
'/usr/lib/gnupg/scdaemon': probably not installed
May 24 23:13:12 zira systemd[568233]: Reached target Paths.
May 24 23:13:12 zira systemd[568233]: Reached target Timers.
May 24 23:13:12 zira systemd[568233]: Starting D-Bus User Message Bus Socket.
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG network certificate 
management daemon.
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache (access for web browsers).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache (restricted).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
May 24 23:13:12 zira systemd[568233]: Listening on GnuPG cryptographic agent 
and passphrase cache.
May 24 23:13:12 zira systemd[568233]: Listening on Sound System.
May 24 23:13:12 zira systemd[568233]: Listening on D-Bus User Message Bus 
Socket.
May 24 23:13:12 zira systemd[568233]: Reached target Sockets.
May 24 23:13:12 zira systemd[568233]: Reached target Basic System.
May 24 23:13:12 zira systemd[1]: Started User Manager for UID 1000.
May 24 23:13:12 zira systemd[568233]: Starting Sound Service...
May 24 23:13:12 zira systemd[1]: Started Session 919 of user vinc17.
May 24 23:13:12 zira rtkit-daemon[793]: Successfully made thread 568253 of 
process 568253 owned by '1000' high priority at nice level -11.
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 1 threads of 1 processes of 
1 users.
May 24 23:13:12 zira systemd[568233]: Started D-Bus User Message Bus.
May 24 23:13:12 zira kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: invalid ELD 
data byte 57
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 1 threads of 1 processes of 
1 users.
May 24 23:13:12 zira rtkit-daemon[793]: Successfully made thread 568375 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:12 zira rtkit-daemon[793]: Supervising 2 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 2 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Successfully made thread 568376 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 3 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 3 threads of 1 processes of 
1 users.
May 24 23:13:13 zira rtkit-daemon[793]: Successfully made thread 568377 of 
process 568253 owned by '1000' RT at priority 5.
May 24 23:13:13 zira rtkit-daemon[793]: Supervising 4 threads of 1 processes of 
1 users.
May 24 23:13:13 zira systemd[568233]: Started Sound Service.
May 24 23:13:13 zira systemd[568233]: Reached target Main User Target.
May 24 23:13:13 zira systemd[568233]: Startup finished in 684ms.
May 24 23:13:13 zira bluetoothd[773]: 

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 23.05.20 um 02:59 schrieb Vincent Lefevre:
> On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
>> This is strange. Something is triggering the start of systemd-logind
> 
> What do you mean by "start of systemd-logind"?
> 
> On my machine, systemd-logind is started early at boot time and
> never quits.

You said:

> The running instance cannot be stopped as it is automatically
> restarted. 

when I adviced you to stop the running systemd-logind.service and
starting logind by hand.




signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
> This is strange. Something is triggering the start of systemd-logind

What do you mean by "start of systemd-logind"?

On my machine, systemd-logind is started early at boot time and
never quits.

> (via D-Bus most likely). My educated guess is, that it is actually this
> process, which triggers the suspend, not logind itself.

But if the lid is not closed when I change the VT, the system
is not suspended.

And if I'm on a VT that is different from the one where
systemd-inhibit has been run and I close the lid, the system
is suspended.

> Remember when I initially said, that logind provides the mechanism and
> the policy is supposed to be proved by something else (usually the
> desktop environment).

A part of the policy is in logind, isn't it? I mean that
/etc/systemd/logind.conf has an option "HandleLidSwitch",
which I haven't modify, so that it is the default "suspend".
The suspend is just supposed to be blocked by an inhibitor,
which is also part of logind.

Note also that when I did the test, there was no desktop environment,
no X server, just 2 VTs involved. Which part of the system is in
charge of the VTs, then?

If I understand correctly, the suspend is done via the call of
manager_handle_action() in "login/logind-action.c". It would
be interesting to know the values of m and inhibit_key. But
according to what is logged, it seems that the call can only
be done via

manager_handle_action(manager, INHIBIT_HANDLE_LID_SWITCH, 
handle_action, manager->lid_switch_ignore_inhibited, is_edge);

in button_lid_switch_handle_action(); otherwise I would have
got another message before "Suspending...". So inhibit_key
would have the expected value. But I'm wondering about
manager; if it is not constant, this seems to be wrong
(as the inhibitors are associated with it).

Then, concerning button_lid_switch_handle_action(), there are
2 calls:

1. From button_recheck(), and it seems that this is what is called
   when I change the VT while the lid is already closed.

2. From button_dispatch(). The button_lid_switch_handle_action()
   call is preceded by "Lid closed.", which is what I get when
   I close the lid. And if I'm on a "wrong" VT, the system will
   be suspended.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 22.05.20 um 12:19 schrieb Vincent Lefevre:
> Control: forwarded -1 https://github.com/systemd/systemd/issues/15887
>

Thanks for forwarding this issue.

> On 2020-05-22 06:08:02 +0200, Michael Biebl wrote:
>> I can't reproduce the issue with those instructions.
>> Must be something specific to your hardware / software configuration.
>>
>> To further debug this yourself, you might try running logind manually.
>> Stop the running instance, then run
>> SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind
> 
> The running instance cannot be stopped as it is automatically
> restarted. 

This is strange. Something is triggering the start of systemd-logind
(via D-Bus most likely). My educated guess is, that it is actually this
process, which triggers the suspend, not logind itself.

Remember when I initially said, that logind provides the mechanism and
the policy is supposed to be proved by something else (usually the
desktop environment).



signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

Control: forwarded -1 https://github.com/systemd/systemd/issues/15887

On 2020-05-22 06:08:02 +0200, Michael Biebl wrote:
> I can't reproduce the issue with those instructions.
> Must be something specific to your hardware / software configuration.
> 
> To further debug this yourself, you might try running logind manually.
> Stop the running instance, then run
> SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

The running instance cannot be stopped as it is automatically
restarted. I had to add "Environment=SYSTEMD_LOG_LEVEL=debug"
to the [Service] section as explained here:

  https://lists.freedesktop.org/archives/systemd-devel/2013-March/010004.html

> Maybe you find any clues what's going on your system.

I've reported the bug upstream with debug information. I've also
attached the logs to this message.

But systemd-logind still does not explain *why* it is suspending
the system. Before the VT change, I can see that systemd-logind
takes the inhibitor into account ("Refusing suspend operation,
handle-lid-switch is inhibited"). And just after the VT change,
it suspends the system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
May 22 10:44:03 zira systemd-logind[792]: VT changed to 1
May 22 10:44:08 zira login[32071]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 22 10:44:12 zira login[32071]: pam_unix(login:auth): Couldn't open 
/etc/securetty: No such file or directory
May 22 10:44:12 zira login[32071]: pam_unix(login:session): session opened for 
user vinc17 by LOGIN(uid=0)
May 22 10:44:12 zira systemd-logind[792]: Got message type=method_call 
sender=:1.135 destination=org.freedesktop.login1 path=/org/freedesktop/login1 
interface=org.freedesktop.login1.Manager member=CreateSession cookie=2 
reply_cookie=0 signature=uusussbssa(sv) error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Sent message type=method_call 
sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus 
interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=444 
reply_cookie=0 signature=s error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Got message type=method_return 
sender=org.freedesktop.DBus destination=:1.18 path=n/a interface=n/a member=n/a 
cookie=46 reply_cookie=444 signature=u error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Sent message type=method_call 
sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus 
interface=org.freedesktop.DBus member=GetConnectionUnixProcessID cookie=445 
reply_cookie=0 signature=s error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Got message type=method_return 
sender=org.freedesktop.DBus destination=:1.18 path=n/a interface=n/a member=n/a 
cookie=47 reply_cookie=445 signature=u error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Unable to connect to 
/run/systemd/userdb/io.systemd.Multiplexer: No such file or directory
May 22 10:44:12 zira systemd-logind[792]: n/a: varlink: setting state 
idle-client
May 22 10:44:12 zira systemd-logind[792]: 
/run/systemd/userdb/io.systemd.DynamicUser: Sending message: 
{"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{"uid":1000,"service":"io.systemd.DynamicUser"}}
May 22 10:44:12 zira systemd-logind[792]: 
/run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state idle-client 
→ awaiting-reply
May 22 10:44:12 zira systemd-logind[792]: 
/run/systemd/userdb/io.systemd.DynamicUser: New incoming message: 
{"error":"io.systemd.UserDatabase.NoRecordFound","parameters":{}}
May 22 10:44:12 zira systemd-logind[792]: 
/run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state 
awaiting-reply → processing-reply
May 22 10:44:12 zira systemd-logind[792]: Got lookup error: 
io.systemd.UserDatabase.NoRecordFound
May 22 10:44:12 zira systemd-logind[792]: 
/run/systemd/userdb/io.systemd.DynamicUser: varlink: changing state 
processing-reply → idle-client
May 22 10:44:12 zira systemd-logind[792]: Starting services for new user vinc17.
May 22 10:44:12 zira systemd-logind[792]: Sent message type=method_call 
sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=446 
reply_cookie=0 signature=ss error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Got message type=method_return 
sender=:1.0 destination=:1.18 path=n/a interface=n/a member=n/a cookie=1546 
reply_cookie=446 signature=o error-name=n/a error-message=n/a
May 22 10:44:12 zira systemd-logind[792]: Sent message type=signal sender=n/a 
destination=n/a path=/org/freedesktop/login1 
interface=org.freedesktop.login1.Manager member=UserNew cookie=447 
reply_cookie=0 signature=uo error-name=n/a error-message=n/a
May 22 10:44:12 

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Control: tags -1 + unreproducible

Am 22.05.20 um 01:44 schrieb Vincent Lefevre:
> On 2020-05-21 21:02:20 +0200, Michael Biebl wrote:

> To reproduce the issue (I've done the test after stopping the
> display manager in order to make sure that it does not interfere):
> 
> 1. Switch to VT 1 and log in.
> 
> 2. Start a systemd-inhibit lock.
> 
> 3. Close the lid.
> 
> 4. Log out (from VT 1).
> 
> 5. Wait a bit. Nothing happens.
> 
> 6. Switch to VT 2.
> 
> After 6, the system is suspended (with my last test, immediately,
> but with a similar test yesterday, this was after a few seconds).
> 

I can't reproduce the issue with those instructions.
Must be something specific to your hardware / software configuration.

To further debug this yourself, you might try running logind manually.
Stop the running instance, then run
SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-logind

Maybe you find any clues what's going on your system.




signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-21 21:02:20 +0200, Michael Biebl wrote:
> My point is: Only if I stop systemd-inhibit, the system will suspend on
> lid-close. As long as it is running, it does not.
 ^
This is not what I observe (see below).

> But it might very well be, that I misunderstand what you are trying to
> say. Please try to explain it better then, in more detail.

To reproduce the issue (I've done the test after stopping the
display manager in order to make sure that it does not interfere):

1. Switch to VT 1 and log in.

2. Start a systemd-inhibit lock.

3. Close the lid.

4. Log out (from VT 1).

5. Wait a bit. Nothing happens.

6. Switch to VT 2.

After 6, the system is suspended (with my last test, immediately,
but with a similar test yesterday, this was after a few seconds).

It should not, because the systemd-inhibit lock is still running
(and this can be checked after waking up the system).

I think that the issue occurs when the VT that currently corresponds
to the display is not the one from which the systemd-inhibit lock
has been started. I think that all suspend issues I've seen until
now are in this case (I'm not 100% sure because I initially did not
think that the closed lid was the issue as it does not appear in the
journalctl logs, so that I did not pay attention to the status of
the lid; but that could be the most plausible explanation).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 21.05.20 um 20:41 schrieb Vincent Lefevre:
> On 2020-05-21 20:38:16 +0200, Michael Biebl wrote:
>> Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
>>> The suspend also occurs if I switch to a VT.
>>>
>>> So it seems that if a "block" was triggered, it is cancelled once
>>> the login session that started it is no longer associated with the
>>> screen (something like that).
>>
>> fwiw, I can't reproduce this.
>> What I tried:
>> login on tty1, run systemd-inhibit
>> switch to tty2, close the lid -> no suspend
>> switch to tty1, kill systemd-inhibit
>> switch to tty2, close the lid -> suspend
> 
> You did not understand. I do *not* kill systemd-inhibit.
> But the system got suspended.
> 

My point is: Only if I stop systemd-inhibit, the system will suspend on
lid-close. As long as it is running, it does not.

But it might very well be, that I misunderstand what you are trying to
say. Please try to explain it better then, in more detail.



signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-21 20:38:16 +0200, Michael Biebl wrote:
> Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
> > The suspend also occurs if I switch to a VT.
> > 
> > So it seems that if a "block" was triggered, it is cancelled once
> > the login session that started it is no longer associated with the
> > screen (something like that).
> 
> fwiw, I can't reproduce this.
> What I tried:
> login on tty1, run systemd-inhibit
> switch to tty2, close the lid -> no suspend
> switch to tty1, kill systemd-inhibit
> switch to tty2, close the lid -> suspend

You did not understand. I do *not* kill systemd-inhibit.
But the system got suspended.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Michael Biebl]

Am 21.05.20 um 00:26 schrieb Vincent Lefevre:
> The suspend also occurs if I switch to a VT.
> 
> So it seems that if a "block" was triggered, it is cancelled once
> the login session that started it is no longer associated with the
> screen (something like that).

fwiw, I can't reproduce this.
What I tried:
login on tty1, run systemd-inhibit
switch to tty2, close the lid -> no suspend
switch to tty1, kill systemd-inhibit
switch to tty2, close the lid -> suspend





signature.asc
Description: OpenPGP digital signature

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

The suspend also occurs if I switch to a VT.

So it seems that if a "block" was triggered, it is cancelled once
the login session that started it is no longer associated with the
screen (something like that).

This would explain the issue I had with light-locker / lightdm
(bug 961124), because this is exactly this case.

The systemd-inhibit(1) man page says:

  --mode=
  Takes either "block" or "delay" and describes how the lock is
  applied. If "block" is used (the default), the lock prohibits any
  of the requested operations without time limit, and only privileged
  users may override it. If "delay" is used, the lock can only delay
  the requested operations for a limited time. If the time elapses,
  the lock is ignored and the operation executed. The time limit may
  be specified in logind.conf(5). Note that "delay" is only available
  for "sleep" and "shutdown".

So "without time limit", and I can't see any override in my case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

And once again, after I logged out from the VT to log in as root.
And this time, no light-locker or lightdm running.

[...]
May 21 00:06:42 zira login[902]: pam_unix(login:session): session closed for us>
May 21 00:06:42 zira systemd[1]: getty@tty1.service: Succeeded.
May 21 00:06:42 zira systemd-logind[785]: Session 13 logged out. Waiting for pr>
May 21 00:06:42 zira systemd[1]: getty@tty1.service: Scheduled restart job, res>
May 21 00:06:42 zira systemd[1]: Stopped Getty on tty1.
May 21 00:06:42 zira systemd[1]: Started Getty on tty1.
May 21 00:06:44 zira login[107800]: pam_unix(login:auth): Couldn't open /etc/se>
May 21 00:06:48 zira inhibit-suspend[107804]: (vinc17) on-line: yes
May 21 00:06:48 zira inhibit-suspend[107809]: (vinc17) output: 0
May 21 00:06:48 zira login[107800]: pam_unix(login:auth): Couldn't open /etc/se>
May 21 00:06:48 zira login[107800]: pam_unix(login:session): session opened for>
May 21 00:06:48 zira systemd[1]: Created slice User Slice of UID 0.
May 21 00:06:48 zira systemd[1]: Starting User Runtime Directory /run/user/0...
May 21 00:06:48 zira systemd-logind[785]: New session 96 of user root.
May 21 00:06:48 zira systemd-logind[785]: Suspending...
May 21 00:06:48 zira systemd[1]: Reached target Sleep.
May 21 00:06:48 zira systemd[1]: Starting Suspend...
[...]

and after resuming, the systemd-inhibit lock was still there.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

Package: systemd
Version: 245.5-2
Severity: normal

I use a systemd-inhibit lock, which has currently been running
since 19:12, as shown by:

zira:~,2> ps -fwwC systemd-inhibit
UID  PIDPPID  C STIME TTY  TIME CMD
vinc17 34134   1  0 19:12 ?00:00:00 systemd-inhibit 
--what=handle-lid-switch --who=vinc17 --why=power supply or external output 
--mode=block /home/vinc17/wd/src/scripts/inhibit-suspend 10 log +

zira:~,2> systemd-inhibit --list --no-pager
WHOUID  USER   PID   COMMWHAT  WHY  
   MODE 
vinc17 1000 vinc17 34134 systemd-inhibit handle-lid-switch power supply or 
external output block

1 inhibitors listed.

But when I closed the lid at 20:55, the system got suspended:

[...]
May 20 20:55:08 zira inhibit-suspend[48475]: (vinc17) on-line: yes
May 20 20:55:08 zira inhibit-suspend[48480]: (vinc17) output: 0
May 20 20:55:14 zira systemd-logind[785]: Lid closed.
May 20 20:55:14 zira systemd-logind[785]: Suspending...
[...]

I don't know what changed now for systemd, but I've exceptionally
started the X server from a VT.

-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-8
ii  libapparmor1 2.13.4-1+b1
ii  libaudit11:2.8.5-3+b1
ii  libblkid12.35.1-5
ii  libc62.30-8
ii  libcap2  1:2.34-2
ii  libcrypt11:4.4.16-1
ii  libcryptsetup12  2:2.3.2-1
ii  libgcrypt20  1.8.5-5
ii  libgnutls30  3.6.13-2
ii  libgpg-error01.37-1
ii  libidn2-02.3.0-1
ii  libip4tc21.8.4-3
ii  libkmod2 27+20200310-2
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.35.1-5
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1+b1
ii  libselinux1  3.0-1+b3
ii  libsystemd0  245.5-2
ii  mount2.35.1-5
ii  systemd-timesyncd [time-daemon]  245.5-2
ii  util-linux   2.35.1-5

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.137
ii  libnss-systemd   245.5-2
ii  libpam-systemd   245.5-2
ii  udev 245.5-2

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent

/etc/systemd/logind.conf changed:
[Login]
HandlePowerKey=ignore

/etc/systemd/system.conf changed:
[Manager]
DefaultTimeoutStopSec=20s


-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)