You are not logged in.
Pages: 1
Hi all
I have this problem. I can perfectly suspend to Ram with s2ram -f but only if I run it as root
If I run it as a normal user I get
fgconsole: getconsolefd: Invalid argument
Switching from vt-1 to vt1
chvt: VT_ACTIVATE: Bad file descriptor
VT_WAITACTIVE: Bad file descriptor
Segmentation fault
Any idea??
Cheers
Offline
users do not have the permissions to suspend to ram.
The solution would seem to be sudo.
Just check out the examples in /etc/sudoers with visudo. (pacman -Sy sudo)
Offline
I usually suspend with pm-utils (pm-suspend), and that works if you are a member of the "power" group. I don't know if that is applicable to s2ram though...
"Your beliefs can be like fences that surround you.
You must first see them or you will not even realize that you are not free, simply because you will not see beyond the fences.
They will represent the boundaries of your experience."
SETH / Jane Roberts
Offline
I checked that and I get the same problem even after adding my account to the power group... :-(
Offline
yep, I am already using sudo to suspend to ram but it is annoying to type a password just to suspend
Offline
You can set sudo so it doesn't ask for password for particular commands. You have to run "visudo" as root, to edit the sudoers file and add something like this:
[your user] ALL = NOPASSWD: /usr/sbin/s2ram
to the "User privilege specification" section.
Offline
You can set sudo so it doesn't ask for password for particular commands. You have to run "visudo" as root, to edit the sudoers file and add something like this:
[your user] ALL = NOPASSWD: /usr/sbin/s2ram
to the "User privilege specification" section.
Thanks man, this worked!, you rock!
Now, if I can use a little more of your patience, how to link the s2ram command to the closing of the lid?
cheers
Offline
Run the acpid service and define an action fro the lid event in /etc/acpi
Mortuus in anima, curam gero cutis
Offline
I can add my confidence that defining the action even in /etc/acpi is probably the best method to go for, especially if you want to have the seamless "set it and forget it" mentality.
I've used the acpid daemon and utils for at least 2 years without any issue.
Offline
What patroclo7 said, but in more detail...
Make sure that you have acpid daemon installed and enabled. Edit the file /etc/acpi/handler.sh and look for the section of the script that says "button/lid)". Add a new line with "sudo s2ram" (or whatever the command you use for for suspending) to that section (before the ";;") and restart the acpid daemon. This should work, as long as acpid correctly identifies that when the lid is closed/opened which should be the case on most laptops.
Offline
thanks fwojciec for the great input as I had no idea how to do that otherwise.
The lid closing correctly put the system in standby. When I reopen it the system tries to awaken but then goes in standby again... I guess the closing and opening are giving the same message to acpid. Is there a way we can avoid that?
Offline
Sorry - I've never had a problem of this kind with any of my laptops, so no idea how to fix that. A crude workaround would be to assign the suspend command to a key combination and to suspend that way while you're looking for a solution to the acpi method.
Offline
When I reopen it the system tries to awaken but then goes in standby again... I guess the closing and opening are giving the same message to acpid
On my laptop, I have experienced the same behaviour, due to 'lid' event being generated during opening and closing as well. The solution was to put
fgrep -q closed /proc/acpi/button/lid/LID/state || exit 0
before putting laptop to sleep.
Offline
where should I "put" this???
is this a terminal command?
Offline
I tried to run this
fgrep -q closed /proc/acpi/button/lid/LID/state || exit 0
as a command but now when I reopen the lid the system doesn't awaken anymore by itself and when I wake it manually it takes forever to do it... mmmm....
Offline
no, ok... I got it it put it in the handler.sh file before the sudo s2ram -f command
works like a charm!
Offline
Yes, this is a quite common scenario in acpi, sadly, also in passing from battery to ac: two events are seen in both cases (battery and ac), and so acpid needs to check the final state after the two events to see if the system is actually on battery or on AC. Something analogous seems to happen with your lid.
Mortuus in anima, curam gero cutis
Offline
I use KLaptop, and I believe it made the KDE ACPI Helper application set-uid root Or you can make /proc/acpi/sleep writable everytime at boot via rc.local if you so desire.
My lid is BIOS-handled so that's good for me
Last edited by schivmeister (2008-01-01 12:31:03)
I need real, proper pen and paper for this.
Offline
Pages: 1