Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Suspend-sedation Problem

50 views
Skip to first unread message

John Hasler

unread,
Jul 30, 2015, 11:40:04 AM7/30/15
to
I'm trying to get suspend-sedation working on my Gateway 450SX4 with
Jessie installed. Suspend and Hibernate work. I'm following the
instructions at

https://wiki.debian.org/SystemdSuspendSedation

When I close the lid the machine suspends properly and wakes up and runs
the script after the timeout. However, it does not hibernate. It
executes the "else" clause, exits, goes back to suspend (expected as the
lid is closed) and then repeats, leaving this in the log each time:

Jul 30 10:11:36 gateway systemd-sleep[14022]: System resumed.
Jul 30 10:11:36 gateway systemd[1]: Requested transaction contradicts existing jobs: File exists
Jul 30 10:11:37 gateway sh[14029]: suspend-sedation: Woke up before alarm - normal wakeup.

"journalctl -ab" produces nothing more informative.

This exact behavior continues even if I replace the contents of the test
with the "true" command or insert the line

exit 0 ;\

before the "if" line.
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/87r3npe...@thumper.dhh.gt.org

John Hasler

unread,
Jul 30, 2015, 1:10:08 PM7/30/15
to
Additional information: "systemctl suspend" produces exactly the same
result as closing the lid except of course that the machine does not go
back into suspension after the script runs. "systemctl hibernate"
produces exactly the same result as "systemctl suspend" except that the
machines goes into hibernation for the time set in the script rather
than into suspension.
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/87mvyde...@thumper.dhh.gt.org

John Hasler

unread,
Jul 30, 2015, 3:40:06 PM7/30/15
to
I wasn't reloading the script properly. Still doesn't work, but now I
see that the "if" is dropping through because rtcwake always returns
"alarm: on" even though it must have expired because the script is
running. I still get the incomprehensible "file exists" message.
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/87io91e...@thumper.dhh.gt.org

John Hasler

unread,
Jul 31, 2015, 8:10:04 PM7/31/15
to
Gave up and kludged together a workaround. rtcwake will not return
"alarm: off" when run from a systemd service though it will when run
from a login shell. The "File exists" message is evidently a red
herring.
--
John Hasler
jha...@newsguy.com
Elmwood, WI USA


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/873803e...@thumper.dhh.gt.org

kytv

unread,
Aug 29, 2015, 10:30:04 AM8/29/15
to
John Hasler wrote:
> I'm trying to get suspend-sedation working on my Gateway 450SX4 with
> Jessie installed. Suspend and Hibernate work. I'm following the
> instructions at
>
> https://wiki.debian.org/SystemdSuspendSedation
>
> When I close the lid the machine suspends properly and wakes up and runs
> the script after the timeout. However, it does not hibernate. It
> executes the "else" clause, exits, goes back to suspend (expected as the
> lid is closed) and then repeats, leaving this in the log each time:
>
> Jul 30 10:11:36 gateway systemd-sleep[14022]: System resumed.
> Jul 30 10:11:36 gateway systemd[1]: Requested transaction contradicts existing jobs: File exists
> Jul 30 10:11:37 gateway sh[14029]: suspend-sedation: Woke up before alarm - normal wakeup.

FWIW I had the same problem. This "Works For Me™" in Debian Jessie:


ExecStart=/usr/sbin/rtcwake --seconds $ALARM_SEC --auto --mode no
ExecStop=/bin/sh -c '\
-if [ -z "$(cat $WAKEALARM)" ]; then \
+ALARM=$(cat $WAKEALARM); \
+NOW=$(date +%%s); \
+if [ "$NOW" -ge "$ALARM" ]; then \
echo "suspend-sedation: Woke up - no alarm set. Hibernating..."; \
systemctl hibernate; \
else \
signature.asc

Eirik Schwenke

unread,
Sep 2, 2015, 1:10:06 AM9/2/15
to
Hi,

I see there's been some recent changes to the https://wiki.debian.org/SystemdSuspendSedation article.

First a change to move from a (my) dumb string check against "/usr/sbin/rtcwake --mode show" output to avoid issues with l10n (while there doesn't appear to be translations for Norwegian, I gather some locales output "alarm: off" as a localized string, not English).

The change moved to first setting WAKEALARM to point to /sys/class/rtc/rtc0/wakealarm with help of systemd "Environment=" and then setting WAKEALARM either an empty string, or teading a number into WAKEALARM, via command substitution -- and finally checking for the WAKEALARM to be zero '[ -z "$(cat $WAKEALARM)"]. Essentially a complicated way to check if /sys/class/rtc/rtc0/wakealarm is an empty (pseudo)file.

(This isn't meant as criticism against the change - the whole thing is more complicated than it should be and the new version shouldn't be prone to l10n bugs).

Then there was a different change, to do numerical comparison against date +%%s. I think the new code contains two errors: a) it should be:

NOW="$(date +%s)";

At least my date complains that % isn't a valid number if "+%%s" is used. Probably a simple typo.

In the case that no wake-alarm is set; WAKEALARM will be the empty string and dash (and bash) will complain that an integer expression is expected. As far as I can tell adding a test for the empty string (-z) and chaining with logical-or (-o) will *not* work:

a=""
if [ -z "${a}" -o 10 -ge "${a}" ]
then
echo "Never reached."
else
echo "Then apparently is smaller than null"
fi

So, with the current script there appear to be a couple of issues with both the code and the logic. Now on my end, the original script mostly♤ works; and the comment on the last change of the wiki says the current version works for "KillYourTV". As the wiki isn't a good VCS I'd rather not change the script(again) without a little more feedback.

Is anyone using the current version? Is it working? Did the original version work? That's:

https://wiki.debian.org/SystemdSuspendSedation?action=recall&rev=6

How about rev=11 ? For the record as of now the lates is 13.

I'm not on the list, please add me to cc of any replies.

I'm hoping we can find something that's both clean and correct - and actually works for everyone... :-)

Best regards,

Eirik Schwenke

♤ On occasion my thinkpad T420s refuse to suspend on lid close. I usually just open up the lid and manually go directly to hibernate-disk from the command line. No idea why this sometimes happens.


--
Via phone - please excuse quoting and spelling

David Wright

unread,
Sep 2, 2015, 12:40:06 PM9/2/15
to
Quoting Eirik Schwenke (ei...@schwenke.info):

> Then there was a different change, to do numerical comparison against date +%%s. I think the new code contains two errors: a) it should be:
>
> NOW="$(date +%s)";
>
> At least my date complains that % isn't a valid number if "+%%s" is used. Probably a simple typo.
>
> In the case that no wake-alarm is set; WAKEALARM will be the empty string and dash (and bash) will complain that an integer expression is expected. As far as I can tell adding a test for the empty string (-z) and chaining with logical-or (-o) will *not* work:
>
> a=""
> if [ -z "${a}" -o 10 -ge "${a}" ]

bash and dash both support default values for unset/null parameters,
so you can write ${a:-0} or whatever.

${parameter:-word} Use Default Values. If parameter is unset or null,
the expansion of word is substituted. Otherwise, the value of
parameter is substituted.

You can only dodge a syntax error by a short-circuiting OR; leaving it
until you evaluate the test is too late. Thus

if [ ... ] || [ ... bad syntax here ... ]
then

would work but I wouldn't use that construction here. It's really
designed for cases where evaluating the second test would cause an
undesired side-effect.

Cheers,
David.
0 new messages