# tuxonice works from shell, but not correctly acpid

## Poedel

Hi!

I am using tuxonice sources on my netbook.

LXDE is the environment. I switched its own powermanagement off to prevent problems.

acpid is configured and launched. Closing the lid should call hibernation - it does.

When waking it up it works, but hibernates again immediately, if I did not press esc to cancel.

Calling hibernate from a shell works perfectly.

I had a look at the logs beeing superverbosely. I found somethink like lastresume < 3secs - canceled.

whyever it is invoced again & again until the security time limit is reached.

It would be really nice if I could make it hibernate when the lid is closed and start without hibernationfallback afterwards  :Wink: 

Any ideas?

----------

## Hu

This is usually an indication of a buggy BIOS that raises the notification event too many times.  The check for fast repetition usually manages to compensate for double notifications, but if your BIOS is spamming the event, more drastic measures may be required.

----------

## Poedel

this is a eeepc netbook by asus. There is no possibility to adjust acpi behaviour at all. Anyway it would behave the same way when hibernated from the shell by calling the command hibernate. This works perfectly. Probably there is another instance checking acpi events when lid is closed.

----------

## dmpogo

 *Poedel wrote:*   

> this is a eeepc netbook by asus. There is no possibility to adjust acpi behaviour at all. Anyway it would behave the same way when hibernated from the shell by calling the command hibernate. This works perfectly. Probably there is another instance checking acpi events when lid is closed.

 

check in the log what acpi events acpid reports ( if necessary increase acpid reporting) and then see by hand how acpi related scripts respond to those events.   Being simple scripts it may be possible to add some logic to ignore the spurious events if those are present (or forbid a script to react on a new event if it comes too soon, it may, for example,  set and clear some /etc/ignore file )

I have setup my acpi scripts to suspend notebook on lid closure and in addtion to write a hibernate image, in case I forget it in standby state and battery runs out.  But in case I decide to open a lid back right away, a put a sleep delay of 30 sec so that standaby/hibernation is delayed, and before going ahead checks that lid is still closed.

----------

## Poedel

to clear it up a little bit:

this problem seems to be there for a pretty long time.

The first occurance I could find was 2008 when some1 was reporting about a gentoo-specific misprogramming in the serice serverlet from tuxonice. 

In some cases acpi reports not only the closure of the lid, but afterwards the opening, too.

This invokes the system to immediately call another hibernation process.

To stop this there is a feature in common.conf ober hibanation script called RestartServices acpid.

This is the problem mentioned, what the servlet does not start correctly. 

Choosing this option resume works fine, but due to acpid beeing not correclty restarted there is no possibility for an acpid called hibernation anymore since you restart acpid manually. 

Someone had a dirty workaround on the servlet script. But there are two years since then and the script differs too much to patch it easily. I wonder that they still kept the error inside.

My dirty workaround is to touch a file in /tmp as a pid file to check after resume if it is there. 

If it is there the system just came from resume and will not shut down but delete the pid file then.

In the other case it will hibernate. If there was no file, there was no resume just before.

not solved, but working

----------

## dmpogo

You can use acpi_listen to see exactly what your acpi events are generated on lid close/opening, if any, and adjust acpi script accordingly.

On my machine /proc/acpi/button/lid/LID/state  contains the current state of the lid which can be checked (rather than toucing file in /tmp )

----------

## Poedel

yes, true.. this acpi event is beeing set here, too.

This is more convinient   :Cool: 

just testing it on my old toshiba:

```
pcslap /home/poedel # acpi_listen 

button/lid LID 00000080 00000001

button/lid LID 00000080 00000002
```

How do I integrate this in my checkup? the whole line?

ah no.. the last one is the counter. And checking the last one for parity is probably more

complicated than just asking proc whether the lid is currently closed or open.

----------

## Poedel

here it is rearranged, my /etc/acpi/lid.sh

```
state=$( awk '{print $2}' < /proc/acpi/button/lid/LID/state )

if [ $state == 'closed' ]

then

  /usr/sbin/hibernate

fi
```

----------

## dmpogo

 *Poedel wrote:*   

> here it is rearranged, my /etc/acpi/lid.sh
> 
> ```
> state=$( awk '{print $2}' < /proc/acpi/button/lid/LID/state )
> 
> ...

 

The version I have is

```

#!/bin/bash

lid_state=/proc/acpi/button/lid/LID/state

test -e $lid_state || exit 0

if grep -q closed $lid_state ; then

#Often, we shutdown or hibernate and then immediately close lid.

#Try to sleep to let these processes finish

   sleep 30s

# Lid could have been open back during this wait

   if grep -q closed $lid_state ; then

      logger "lid closed -> suspending"

      /usr/sbin/hibernate-s2both

   fi

else

   logger "lid opened -> resuming"

fi

```

----------

## Poedel

n1!

I am using tuxonice with text-userinterface.

If I should wanna cancel my decision and reopen the lid I still have the possibility to hit esc whiler hibernation is still in progress.. grafically shown by a bar.

----------

## dmpogo

 *Poedel wrote:*   

> n1!
> 
> I am using tuxonice with text-userinterface.
> 
> If I should wanna cancel my decision and reopen the lid I still have the possibility to hit esc whiler hibernation is still in progress.. grafically shown by a bar.

 

Interrupting hibernation was not my problem (I also use tuxonice and text-userinterface)

My situation was that I sometimes in a rush hit shutdown or hibernate and then immediately close the lid (like running to catch a bus).

When I do that, the suspend from closing the lid tended to cancel the earlier shutdown or hibernate.  So I come in the office and see that my laptop was suspended and not shutdowned as I thought.  Which was especially annoying since when woken up it would continue to shutdown.

This is what 30 s delay does, it allows shutdown/hibernate done by hand to proceed to the stage when acpid is not active anymore and closing the lid does nothing.

It also solved another problem - sometimes I'll close the lid and immediatly decide to reopen it (forgotten to look at something). Now I don't need to wait through suspend cycle when I do this

----------

