GNU bug report logs - #57052
elogind-service specifies a variable that's ignored by defualt

Previous Next

Package: guix;

Reported by: Cairn <cairn <at> pm.me>

Date: Mon, 8 Aug 2022 07:20:01 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57052 in the body.
You can then email your comments to 57052 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Mon, 08 Aug 2022 07:20:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cairn <cairn <at> pm.me>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Mon, 08 Aug 2022 07:20:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Cairn <cairn <at> pm.me>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: elogind-service specifies a variable that's ignored by defualt
Date: Sun, 07 Aug 2022 23:29:30 +0000
[Message part 1 (text/plain, inline)]
"HandleLidSwitchExternalPower= is completely ignored by default (for backwards compatibility)"[1]

I noticed (with help in IRC) that my laptop wasn't suspending on lid close when plugged in and charging, which I hadn't seen happen on other systems. I now know that I can set this by configuring the `elogind-service` parameter `handle-lid-switch-external-power`. Regardless, it seems like it should default to being unset rather than set/ignored, since that would heed the line I quoted above.

[1]: https://www.freedesktop.org/software/systemd/man/logind.conf.html
[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Mon, 08 Aug 2022 10:46:01 GMT) Full text and rfc822 format available.

Message #8 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: elogind-service specifies a variable that's ignored by defualt
Date: Mon, 08 Aug 2022 12:45:10 +0200
Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn:
> "HandleLidSwitchExternalPower= is completely ignored by default (for
> backwards compatibility)"[1]
> 
> I noticed (with help in IRC) that my laptop wasn't suspending on lid
> close when plugged in and charging, which I hadn't seen happen on
> other systems. I now know that I can set this by configuring the
> `elogind-service` parameter `handle-lid-switch-external-power`.
> Regardless, it seems like it should default to being unset rather
> than set/ignored, since that would heed the line I quoted above.
I think you're misreading that line.  What it states is not that
"HandleLidSwitchExternalPower" is ignored by default, but
"HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
be no value unless one was provided (whichever semantics "no value" has
later on) is only confusingly explained later on.

IMHO the Guix behaviour of always setting a value is the right one
(explicit is better than implicit after all).  As for the default
values, one might disagree as to which fits, but I don't think ignoring
lid switches while powered is harmful.

Cheers




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 01:54:01 GMT) Full text and rfc822 format available.

Message #11 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: bokr <at> bokr.com
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored
 by defualt
Date: Tue, 9 Aug 2022 03:52:43 +0200
Hi Liliana,

On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote:
> Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn:
> > "HandleLidSwitchExternalPower= is completely ignored by default (for
> > backwards compatibility)"[1]
> > 
> > I noticed (with help in IRC) that my laptop wasn't suspending on lid
> > close when plugged in and charging, which I hadn't seen happen on
> > other systems. I now know that I can set this by configuring the
> > `elogind-service` parameter `handle-lid-switch-external-power`.
> > Regardless, it seems like it should default to being unset rather
> > than set/ignored, since that would heed the line I quoted above.
> I think you're misreading that line.  What it states is not that
> "HandleLidSwitchExternalPower" is ignored by default, but
> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
> be no value unless one was provided (whichever semantics "no value" has
> later on) is only confusingly explained later on.
> 
> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all).  As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.
>

What would you advise if there's no battery power,
or for some reason one is running on plug power only,
for worriers that the bulding power might fail?

I'd guess a power brick would power for some milliseconds 
and wonder if this is detectable, i.e., to do something
at least to leave a goodbye world message somewhere if the machine
was not suspended with sufficient state to resume after power restore?

Buy a UPS, and don't go away long enough for that to run out? :)

> Cheers
> 
--
Regards,
Bengt Richter




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 06:35:02 GMT) Full text and rfc822 format available.

Message #14 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: bokr <at> bokr.com
Cc: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored
 by defualt
Date: Tue, 09 Aug 2022 08:34:12 +0200
Am Dienstag, dem 09.08.2022 um 03:52 +0200 schrieb bokr <at> bokr.com:
> Hi Liliana,
> 
> On +2022-08-08 12:45:10 +0200, Liliana Marie Prikler wrote:
> > Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn:
> > > "HandleLidSwitchExternalPower= is completely ignored by default
> > > (for
> > > backwards compatibility)"[1]
> > > 
> > > I noticed (with help in IRC) that my laptop wasn't suspending on
> > > lid
> > > close when plugged in and charging, which I hadn't seen happen on
> > > other systems. I now know that I can set this by configuring the
> > > `elogind-service` parameter `handle-lid-switch-external-power`.
> > > Regardless, it seems like it should default to being unset rather
> > > than set/ignored, since that would heed the line I quoted above.
> > I think you're misreading that line.  What it states is not that
> > "HandleLidSwitchExternalPower" is ignored by default, but
> > "HandleLidSwitchExternalPower=" is ignored by default, i.e. there
> > will
> > be no value unless one was provided (whichever semantics "no value"
> > has
> > later on) is only confusingly explained later on.
> > 
> > IMHO the Guix behaviour of always setting a value is the right one
> > (explicit is better than implicit after all).  As for the default
> > values, one might disagree as to which fits, but I don't think
> > ignoring lid switches while powered is harmful.
> > 
> 
> What would you advise if there's no battery power,
> or for some reason one is running on plug power only,
> for worriers that the bulding power might fail?
> 
> I'd guess a power brick would power for some milliseconds 
> and wonder if this is detectable, i.e., to do something
> at least to leave a goodbye world message somewhere if the machine
> was not suspended with sufficient state to resume after power
> restore?
> 
> Buy a UPS, and don't go away long enough for that to run out? :)
I do think that we're starting to split hairs here, but for the sake of
the argument, elogind should be able to detect whether or not the power
supply it's attached to actually delivers power.  If your laptop
doesn't have a battery, then pulling the plug on it has the same
effects as pulling the plug on a regular PC, there's nothing you can do
in elogind to make that a safe action.

Cheers




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 10:29:01 GMT) Full text and rfc822 format available.

Message #17 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Cairn <cairn <at> pm.me>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 "57052 <at> debbugs.gnu.org" <57052 <at> debbugs.gnu.org>
Subject: Re: elogind-service specifies a variable that's ignored by defualt
Date: Tue, 09 Aug 2022 06:42:38 +0000
[Message part 1 (text/plain, inline)]
(Resending this email, since I forgot to add the debugs.gnu.org address as a recipient)

> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all). As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.

That's fair!

Well, if explicitly setting variables is the standard, then I suggest changing `handle-lid-switch-external-power` to the same value as `handle-lid-switch` ("suspend"). I agree that the current setting isn't harmful, but this change would match the default, unconfigured behavior of `elogind`. It would also be more consistent with other distros' defaults from what I've experienced.
[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 13:53:02 GMT) Full text and rfc822 format available.

Message #20 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored
 by defualt
Date: Tue, 09 Aug 2022 09:52:25 -0400
Hi,

Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at> writes:

> Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn:
>> "HandleLidSwitchExternalPower= is completely ignored by default (for
>> backwards compatibility)"[1]
>> 
>> I noticed (with help in IRC) that my laptop wasn't suspending on lid
>> close when plugged in and charging, which I hadn't seen happen on
>> other systems. I now know that I can set this by configuring the
>> `elogind-service` parameter `handle-lid-switch-external-power`.
>> Regardless, it seems like it should default to being unset rather
>> than set/ignored, since that would heed the line I quoted above.
> I think you're misreading that line.  What it states is not that
> "HandleLidSwitchExternalPower" is ignored by default, but
> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
> be no value unless one was provided (whichever semantics "no value" has
> later on) is only confusingly explained later on.
>
> IMHO the Guix behaviour of always setting a value is the right one
> (explicit is better than implicit after all).  As for the default
> values, one might disagree as to which fits, but I don't think ignoring
> lid switches while powered is harmful.

It can be.  I have a Lenovo T430s with a partially discolored LCD from
heat after I left it closed in a backpack for a couple hours, thinking
it would have suspend (it was not).  That would not have happened with
the value supposed to be default (which matches the behavior used on
most other systems).

So I'd favor having the default to suspend on any lid close.

Thanks,

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 13:58:01 GMT) Full text and rfc822 format available.

Message #23 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored
 by defualt
Date: Tue, 09 Aug 2022 09:57:05 -0400
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi,
>
> Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at> writes:
>
>> Am Sonntag, dem 07.08.2022 um 23:29 +0000 schrieb Cairn:
>>> "HandleLidSwitchExternalPower= is completely ignored by default (for
>>> backwards compatibility)"[1]
>>>
>>> I noticed (with help in IRC) that my laptop wasn't suspending on lid
>>> close when plugged in and charging, which I hadn't seen happen on
>>> other systems. I now know that I can set this by configuring the
>>> `elogind-service` parameter `handle-lid-switch-external-power`.
>>> Regardless, it seems like it should default to being unset rather
>>> than set/ignored, since that would heed the line I quoted above.
>> I think you're misreading that line.  What it states is not that
>> "HandleLidSwitchExternalPower" is ignored by default, but
>> "HandleLidSwitchExternalPower=" is ignored by default, i.e. there will
>> be no value unless one was provided (whichever semantics "no value" has
>> later on) is only confusingly explained later on.
>>
>> IMHO the Guix behaviour of always setting a value is the right one
>> (explicit is better than implicit after all).  As for the default
>> values, one might disagree as to which fits, but I don't think ignoring
>> lid switches while powered is harmful.
>
> It can be.  I have a Lenovo T430s with a partially discolored LCD from
> heat after I left it closed in a backpack for a couple hours, thinking
> it would have suspend (it was not).  That would not have happened with
> the value supposed to be default (which matches the behavior used on
> most other systems).
>
> So I'd favor having the default to suspend on any lid close.

For the record, this was noticed and discussed more than a year ago, see
Message-ID: <871rens9a2.fsf <at> nckx>.  It had fallen into the cracks, it
seems.

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 14:32:02 GMT) Full text and rfc822 format available.

Message #26 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
Cc: Cairn <cairn <at> pm.me>, 57052 <at> debbugs.gnu.org
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored by defualt
Date: Tue, 09 Aug 2022 14:31:49 +0000
>For the record, this was noticed and discussed more than a year ago, see
>Message-ID: <871rens9a2.fsf <at> nckx>.  It had fallen into the cracks

LOL.  I'm the one who asked Cairn to report this.  I didn't remember publicly reporting it, I only remembered noticing it and not fixing it, and didn't want it to get forgotten 'again'.  Sorry for the noise!

Strongly disagree that the current Guix behaviour makes any sense, let alone better!  That sounds like posthockholm rationalisation to me.  If people want opinionated variants, those can be written on top of a service that properly exposes upstream behaviour.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.




Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 14:33:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#57052; Package guix. (Tue, 09 Aug 2022 16:18:02 GMT) Full text and rfc822 format available.

Message #32 received at 57052 <at> debbugs.gnu.org (full text, mbox):

From: Cairn <cairn <at> pm.me>
To: "57052 <at> debbugs.gnu.org" <57052 <at> debbugs.gnu.org>
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored by
 defualt
Date: Tue, 09 Aug 2022 14:42:39 +0000
[Message part 1 (text/plain, inline)]
Would it not still be explicit if variables that should go unspecified were written out, but not given a value? Maybe I'm misunderstanding the point of explicit values though.
[signature.asc (application/pgp-signature, attachment)]

Reply sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
You have taken responsibility. (Wed, 10 Aug 2022 04:39:02 GMT) Full text and rfc822 format available.

Notification sent to Cairn <cairn <at> pm.me>:
bug acknowledged by developer. (Wed, 10 Aug 2022 04:39:02 GMT) Full text and rfc822 format available.

Message #37 received at 57052-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Cairn <cairn <at> pm.me>
Cc: liliana.prikler <at> ist.tugraz.at, 57052-done <at> debbugs.gnu.org,
 Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#57052: elogind-service specifies a variable that's ignored
 by defualt
Date: Wed, 10 Aug 2022 00:38:34 -0400
Hello,

Cairn <cairn <at> pm.me> writes:

> Would it not still be explicit if variables that should go unspecified
> were written out, but not given a value? Maybe I'm misunderstanding
> the point of explicit values though.

I made it *unspecified* in 59ee837d8b, given this service config doesn't
yet use 'define-configuration' that would have allowed for a proper
maybe-value.

Tested to work on a X200 and pushed!

Closing, at last.

Thanks,

Maxim




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 07 Sep 2022 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 225 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.