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
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
>
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,
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
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
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
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,
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
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
> >
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.
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
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
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
13 matches
Mail list logo
