Looking For A Suspend That Suits ArtfulPup.(SOLVED)

[BJF]

ASUS EeePC 701 4G, Celeron processor, 1Gb RAM, 1Gb Swap partition, Saluki full on SSD, ArtfulPup on SD card.

The ArtyPup install is working really well on this netbook, but one of the features missed is Saluki's ability to Suspend on lid close and wake up refreshed and ready to go.
Laptop-mode has been installed from the PPM and appears in the Menu without an icon and does not respond to a click. If called from LXTerminal it returns that it is active but not configured. I tried the Ubuntu forum command:

Code: Select all

lmt-configure-gui

which returns:

Code: Select all

/usr/bin/lmt-config-gui: line 6: python2: command not found

Can the Forum please direct me to a way to access laptop-mode preferably by GUI, or alternatively walk me through tinkering with the acpi to achieve the same sort of ends? I'd like to replicate Saluki's shut-the-lid-and-come-back-next-day if possible. Currently Artful is set to go to Screensave after 7mins and ShutDown after 10mins, but it's just not the same!

Thanks.

[Marv]

ASUS EeePC 701 4G, Celeron processor, 1Gb RAM, 1Gb Swap partition, Saluki full on SSD, ArtfulPup on SD card.

The ArtyPup install is working really well on this netbook, but one of the features missed is Saluki's ability to Suspend on lid close and wake up refreshed and ready to go.
Laptop-mode has been installed from the PPM and appears in the Menu without an icon and does not respond to a click. If called from LXTerminal it returns that it is active but not configured. I tried the Ubuntu forum command:

Code: Select all

lmt-configure-gui

which returns:

Code: Select all

/usr/bin/lmt-config-gui: line 6: python2: command not found

Can the Forum please direct me to a way to access laptop-mode preferably by GUI, or alternatively walk me through tinkering with the acpi to achieve the same sort of ends? I'd like to replicate Saluki's shut-the-lid-and-come-back-next-day if possible. Currently Artful is set to go to Screensave after 7mins and ShutDown after 10mins, but it's just not the same!

Thanks.

First, a question. How is your SD card attached to the laptop? If via USB, there is a section of code (lines 29 through 34) in the /etc/acpi/actions/suspend.sh script that prevents suspend if a USB mount is detected. Others and myself have commented that part out in newer kerneled pups like Artful with fairly good results.

Something to try at the very first is running

Code: Select all

echo -n mem > /sys/power/state

in a terminal and seeing if a suspend results. If so, mild tinkering will get you there, if not it's more serious. If Saluk i suspends on the eeePC, Artful should also if it's not a USB thing.

With Grub4Dos installs to onboard SSD, all my laptops (currently i5 or core 2 duo based) suspend out of the box in both Artful and Bionic pups. I do run a modified suspend.sh but it is mostly to accomodate different WMs and give consistent notifications and look and feel across them

The stock suspend.sh in Artful should be:

Code: Select all

#!/bin/sh
# suspend.sh 28sep09 by shinobar
# 12feb10 pass poweroff
# 23apr12 fix was not suspend from acpi_poweroff.sh
#20140526 shinobar: avoid multiple run
#20140629 shinobar: ACPI_CONFIG
ACPI_CONFIG=/etc/acpi/acpi.conf
[ -s "$ACPI_CONFIG" ] && . "$ACPI_CONFIG"
case "$DISABLE_SUSPEND" in
y*|Y*|true|True|TRUE|1) exit;;
esac

#avoid multiple run
LOCKFILE=/tmp/acpi_suspend-flg
if [ -f "$LOCKFILE" ]; then
  PID=$(cat "$LOCKFILE")
  ps| grep "^[ ]*$PID " && exit
fi
echo -n $$ > "$LOCKFILE"
sync
[ "$(cat "$LOCKFILE")" = $$ ] || exit 0 

# do not suspend at shutdown proccess
#111129 added suspend to acpi_poweroff.sh
PS=$(ps)
[ ! -f /tmp/suspend ] && echo "$PS"| grep -qE 'sh[ ].*poweroff' && rm -f "$LOCKFILE" && exit 0
rm -f /tmp/suspend

# do not suspend if usb media mounted
USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
for USB in $USBS
do
	mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
done

# process before suspend
# sync for non-usb drives
sync
rmmod ehci_hcd

#suspend
echo -n mem > /sys/power/state

# process at recovery from suspend
#restartwm
modprobe ehci_hcd
#/etc/rc.d/rc.network restart

rm -f "$LOCKFILE

Note that there should be a " at the end of the last line (it's been missing for a loong time) and that the lines removing and restarting ehci_hcd are vestigial as it is built into all newer kernels.

Edit: Just to clarify, I'm referring to lid-suspend when I say suspend above.

[mikeslr]

Hi BJF,

I don't have ArtfulPup on my computer's grub4dos menu.lst. But your question prompted me to explore its author's, peebee's, next Puppy, upup-bionic beaver. See this post: http://murga-linux.com/puppy/viewtopic. ... 695#989695.

If PupShutDown Manager already appears on Menu>Utilities, then by initiating it and selecting the "G" icon on the bottom left of the GUI that will open, suspend should be initiated. Then, of course, you could add the PupShutDown Manager to your Taskbar; or copy my method in order to initiate it from the "Leave or Exit" listing on the Menu.

mikesLr

[Papy]

pupshutdown is not shown in the menu artfulpup but in applications .desktop
reinstalled with pet
OK now.

[BJF]

(Sorry, been away for a bit.)

Marv: did-

Code: Select all

echo -n mem > /sys/power/state

-and got an instant Suspend. And it came back with a touch on the power switch. However, due to the Save File being formatted ext2 (??), there were missing inodes all over the boot-up parade screen and Artful was not a happy aardvark at all.
I reinstalled with UpupBB and formatted the save file as ext3, and applied the code. It worked exactly as Artful had but the save file now repairs anything it finds on boot and carries on.
I noted that both Artful and Bionic's suspend.sh files are shorter than your published version and stop before the line-

Code: Select all

# do not suspend at shutdown proccess

I haven't tried substituting the published one. I'd like advice on that.

Mikesir: I installed PupShutDown Manager. Choosing the Suspend option does nothing.

In a lightbulb moment, I made a script from Marv's code, created a Desktop icon that executes it, and can now click the EeeP to sleep. Just closing the lid still sees the screen blank when the Saver eventually clicks in, and the netbook shuts down after 10mins of inactivity as it has been programmed to. So currently I do have a working Suspend button to push, but a Lid-Shut Suspend like Saluki has on this machine would be just the best thing.

Thanks everyone.

[BJF]

Marv's published Artful suspend.sh was copied into /etc/acpi/actions/, the original renamed .old and the machine rebooted.
Shutting the lid still changes nothing. Neither does PupShutDown Manager. The homemade Desktop link still works.
Note please that the OS is now UpupBB and not the original ArtfulAardvark. Is that a factor? Should I change the thread title to avoid confusion?

Thanks.

[Marv]

Marv's published Artful suspend.sh was copied into /etc/acpi/actions/, the original renamed .old and the machine rebooted.
Shutting the lid still changes nothing. Neither does PupShutDown Manager. The homemade Desktop link still works.
Note please that the OS is now UpupBB and not the original ArtfulAardvark. Is that a factor? Should I change the thread title to avoid confusion?

Thanks.

Could change the title but I'll follow it here as well. Working in upupBB is easier for me as I have a copy of that in the kennel. In the suspend.sh, add the following lines after line 6 (following the initial documentation section):

Code: Select all

echo runnning the suspend script, interrupt structure working >> /tmp/lidcheck
cat /proc/acpi/button/lid/LID/state >> /tmp/lidcheck

Save the suspend file, close the lid, open it, and post what is in /tmp/lidcheck. If /tmp/lidcheck isn't created that also is informative. That should help in seeing what is or rather isn't going on with your laptop.

[BJF]

Marv: This-

Code: Select all

runnning the suspend script, interrupt structure working
state:      closed

Cheers.

[Marv]

Good, exactly what you should see. Now, continuing in a methodical way, add the lines commented #add in this snippet to the suspend.sh and repeat the lid closure test. I'll dig up a 'debounce ' bit I needed on some laptops in the maintime. I'm just adding to the lidcheck file, you could delete it before you run the new test if it makes it easier to interpret, else just cut and paste the new part.

Code: Select all

# do not suspend at shutdown proccess
#111129 added suspend to acpi_poweroff.sh
PS=$(ps)
[ ! -f /tmp/suspend ] && echo "$PS"| grep -qE 'sh[ ].*poweroff' && rm -f "$LOCKFILE" && exit 0
rm -f /tmp/suspend

echo acpi config, multipleruntest, shutdowndisable ok >> /tmp/lidcheck  #add 

# do not suspend if usb media mounted
USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
for USB in $USBS
do
	mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
done

echo usbmounttest ok >> /tmp/lidcheck  # add

# process before suspend
# sync for non-usb drives
sync
rmmod ehci_hcd

echo sync ok >> /tmp/lidcheck  # add

#suspend

Edit:
Let's assume that all of the diagnostic (# add) lines report in to the lidcheck file and you still don't get lidsuspend. I think that is likely. It is possible that the lid closure switch on your laptop is sending a button close and then a button open on shutting the lid (bouncing/fluttering). Some of the switches on my old pentium M lappies did this. Pull all of the diagnostic lines we added and put just this at the beginning of suspend.sh, just after the documentation section and try a lidsuspend. I've simulated a flakey switch as best I can and this did help that. The 5 seconds is pretty long and if it does work could be shortened experimentally. I needed that length for my 'simulation'.

Code: Select all

LIDSTATE=`cat /proc/acpi/button/lid/LID/state | grep -o '......$'` #debounce
[ $LIDSTATE ! = "closed" ] &&  exit || sleep 5                     #debounce

[BJF]

Marv: I've done as I was told. I think I have anyway. The last code reported to /tmp/ that the lid was closed but no Suspend ensued. So I added your flakey switch code and removed the test code, and closed the lid and waited. Not 5mins obviously. But no Suspend still. I've published my current suspend.sh for correction and critique before proceeding:

Code: Select all

#!/bin/sh
# suspend.sh 28sep09 by shinobar
# 12feb10 pass poweroff
# 23apr12 fix was not suspend from acpi_poweroff.sh
#20140526 shinobar: avoid multiple run
#20140629 shinobar: ACPI_CONFIG
LIDSTATE=`cat /proc/acpi/button/lid/LID/state | grep -o '......$'` #debounce
[ $LIDSTATE ! = "closed" ] &&  exit || sleep 5                     #debounce
ACPI_CONFIG=/etc/acpi/acpi.conf
[ -s "$ACPI_CONFIG" ] && . "$ACPI_CONFIG"
case "$DISABLE_SUSPEND" in
y*|Y*|true|True|TRUE|1) exit;;
esac

#avoid multiple run
LOCKFILE=/tmp/acpi_suspend-flg
if [ -f "$LOCKFILE" ]; then
  PID=$(cat "$LOCKFILE")
  ps| grep "^[ ]*$PID " && exit
fi
echo -n $$ > "$LOCKFILE"
sync
[ "$(cat "$LOCKFILE")" = $$ ] || exit 0 

# do not suspend at shutdown proccess
#111129 added suspend to acpi_poweroff.sh
PS=$(ps)
[ ! -f /tmp/suspend ] && echo "$PS"| grep -qE 'sh[ ].*poweroff' && rm -f "$LOCKFILE" && exit 0
rm -f /tmp/suspend

# do not suspend if usb media mounted
USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
for USB in $USBS
do
	mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
done


# process before suspend
# sync for non-usb drives
sync
rmmod ehci_hcd

#suspend
echo -n mem > /sys/power/state

# process at recovery from suspend
#restartwm
modprobe ehci_hcd
#/etc/rc.d/rc.network restart

rm -f "$LOCKFILE

Now admittedly I don't know what I'm talking about, and Saluki isn't on an SD, it's on the 4Gb SSD, but would peering at how Jemimah et al get it to Suspend help in any way? /etc/acpi/actions in the Savefile does not contain a suspend.sh file though.

Thanks again.

[Marv]

Morning, Ah, so the install is on an SD card? "Saluki isn't on an SD, it's on the 4Gb SSD" That may be relevant though I can't see why the script would run from the command line or terminal and not from lidsuspend since the first diagnostics show it is being called in that case. Let's back up a step. What is the output of /tmp/lidcheck when a lidsuspend is attempted with all of the #add lines from my snippet added into suspend.sh? I was trying to see where the script fails for you. I should have waited for that before I added the Edit with the flakey switch code. Sorry. Oh ya, the wait is 5 seconds in a sleep 5. Here is my lidcheck from a test as above:

Code: Select all

runnning the suspend script, interrupt structure working
lidstate is closed
acpi config, multipleruntest, shutdowndisable ok
usbmounttest ok
sync ok

Edit to add SD thoughts and my 'normal' lidcheck results.

[HerrBert]

...
First, a question. How is your SD card attached to the laptop? If via USB, there is a section of code (lines 29 through 34) in the /etc/acpi/actions/suspend.sh script that prevents suspend if a USB mount is detected.
...

again, the question should not be if the SD card is mounted via USB. The script exits if ANY USB-drive is currently mounted.

[Marv]

...
First, a question. How is your SD card attached to the laptop? If via USB, there is a section of code (lines 29 through 34) in the /etc/acpi/actions/suspend.sh script that prevents suspend if a USB mount is detected.
...

again, the question should not be if the SD card is mounted via USB. The script exits if ANY USB-drive is currently mounted.

True. I thought I was clear about that here " if a USB mount is detected.". The real puzzle for me is why the script runs and suspends when the OP starts it from command line but not from the lidsuspend acpi button. Seems as though it should exit at the USBTEST in that case as well if that is the fail point. Waiting to see what his diagnostics show...

[HerrBert]

as i understood, BJF didn't start /etc/acpi/actions/suspend.sh on commandline, only echoes -n mem > blahblah

/etc/acpi/actions in the Savefile does not contain a suspend.sh file though.

if suspend.sh does not exist in your savefile, it didn't get changed or changes were not saved.

[Marv]

as i understood, BJF didn't start /etc/acpi/actions/suspend.sh on commandline, only echoes -n mem > blahblah

That would explain what's going on. I understood (or misunderstood) that he ran the whole suspend script I posted as an example from CLI. I hope that's all it is. If he reports the diagnostics that should confirm that. If not I do have a more selective switch debouncer to try. It might work for some of the laptops in the thread you linked that suspended but immediately woke up. Hard to test well without the bad hardware.

I think BJF was referring to the Saluki install/savefile not having a suspend.sh in /etc/acpi/actions. That has quite a different acpi setup.

[BJF]

Sorry, I broke my suspend.sh with copy-and-paste. It has been recovered and the two lidcheck code lines added back where specified at # add.

/temp/lidcheck remains empty and still no suspend.

My current accurately updated /etc/acpi/actions/suspend.sh is here:

Code: Select all

#!/bin/sh
# suspend.sh 28sep09 by shinobar
# 12feb10 pass poweroff
# 23apr12 fix was not suspend from acpi_poweroff.sh
#20140526 shinobar: avoid multiple run
#20140629 shinobar: ACPI_CONFIG
ACPI_CONFIG=/etc/acpi/acpi.conf
[ -s "$ACPI_CONFIG" ] && . "$ACPI_CONFIG"
case "$DISABLE_SUSPEND" in
y*|Y*|true|True|TRUE|1) exit;;
esac

#avoid multiple run
LOCKFILE=/tmp/acpi_suspend-flg
if [ -f "$LOCKFILE" ]; then
  PID=$(cat "$LOCKFILE")
  ps| grep "^[ ]*$PID " && exit
fi
echo -n $$ > "$LOCKFILE"
sync
[ "$(cat "$LOCKFILE")" = $$ ] || exit 0

# do not suspend at shutdown proccess
#111129 added suspend to acpi_poweroff.sh
PS=$(ps)
[ ! -f /tmp/suspend ] && echo "$PS"| grep -qE 'sh[ ].*poweroff' && rm -f "$LOCKFILE" && exit 0
rm -f /tmp/suspend

echo acpi config, multipleruntest, shutdowndisable ok >> /tmp/lidcheck  #add 

# do not suspend if usb media mounted
USBS=$(probedisk2|grep '|usb' | cut -d'|' -f1 )
for USB in $USBS
do
   mount | grep -q "^$USB" && rm -f "$LOCKFILE" && exit 0
done

# process before suspend
# sync for non-usb drives
sync
rmmod ehci_hcd

#suspend
echo -n mem > /sys/power/state

echo sync ok >> /tmp/lidcheck  # add 

# process at recovery from suspend
#restartwm
modprobe ehci_hcd
#/etc/rc.d/rc.network restart

rm -f "$LOCKFILE

Interestingly, there is a mirror of my file above in /etc/acpi/actions/lid/ called 00000080.

With the SD being mounted and read by a USB device (I'll reboot and do ESC to find out how the cardreader is defined, and come back), does that rule out Suspending entirely, or is there a possibility to exclude the Reader by specifying it as an exception to the mounted USB check, or is that ice too thin to skate on? And how does the Command line pull it off, but then is it ducking the USB mount question.

Thanks guys.

EDIT: The netbook sees the cardreader as:

USB:USB2.0 CardReader SD0.

-I'm tempted to comment out the USB mount check in suspend.sh to see what happens!

[Marv]

@BJF PM sent, running an old Artful 17.11 +4 on a USB stick in the Fujitsu S761. Suspending using either of the 'play with fires' I sent you. No short term problems seen, suspended mid-post etc.

[BJF]

I'm marking this as SOLVED because I now have my EeePC going into Suspend when the lid is shut, made possible by alterations to the suspend.sh file that cause it to not recognise the SD Cardreader as a USB device and so resist the action. This is NOT to be recommended but works for me on my netbook. I thank those who assisted me with this outcome. Well done

Cheers.