-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates 23:29:11 I awake it (power on).
Why?
I see no reason given in the pm-suspend.log or any other about why it does so.
Is this an optional setting? Where do I look, where to disable?
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
...
Is this an optional setting? Where do I look, where to disable?
Right click on GNOME Power Manager in your tray (battery icon),
No such thing.
select preferences, check what settings you have in there (for both Power and Battery, it is possible to say "Put computer to sleep when inactive for xx amount of time)
I try to add the battery monitor (this is a desktop, no battery), and the thing complains there is no acpi:
Can't access ACPI events in /var/run/ acpid.socket! Make sure the ACPI subsystem is working and the acpid daemon is running.
However, that daemon is running:
minas-morgul:~ # rcacpid status Checking for service acpid running
However, the applet is added (it is the only one found searching for "power"), but there is no such setting.
I run "gnome-power-manager" on an xterm. It exits, and nothing is seen.
I then start "gnome-power-preferences" on the same xterm; the settings are these:
On AC Power Actions Put computer to sleep when inactive for 30 minutes
I move the slider to "never".
I wonder who and why designed a default to power off the machine when inactive. Just imagine a user power off a server like this! :-(
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
On 2008/10/26 00:30 (GMT+0200) Carlos E. R. composed:
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates 23:29:11 I awake it (power on).
Why?
I see no reason given in the pm-suspend.log or any other about why it does so.
Is this an optional setting? Where do I look, where to disable?
Could be a hardware failure. I have a box with 11.0, Factory, Mandriva & others that was going to sleep at random for several months. Turned out to be failing PS. I replaced the swollen caps in the PS, and the problem disappeared.
Carlos,
On Sun, 2008-10-26 at 00:30 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates 23:29:11 I awake it (power on).
Why?
I see no reason given in the pm-suspend.log or any other about why it does so.
Is this an optional setting? Where do I look, where to disable?
Right click on GNOME Power Manager in your tray (battery icon), select preferences, check what settings you have in there (for both Power and Battery, it is possible to say "Put computer to sleep when inactive for xx amount of time)
Cheers, Magnus
On Sun, 2008-10-26 at 01:04 +0200, Carlos E. R. wrote:
I then start "gnome-power-preferences" on the same xterm; the settings are these:
On AC Power Actions Put computer to sleep when inactive for 30 minutes
I move the slider to "never".
I wonder who and why designed a default to power off the machine when inactive. Just imagine a user power off a server like this! :-(
This was added due to a feature request for Energy Star;
# Enable Energy Star compliant default configuration %gconf_set /apps/gnome-power-manager/actions/sleep_type_battery --type=string "suspend" %gconf_set /apps/gnome-power-manager/timeout/sleep_computer_battery --type=int 1200 %gconf_set /apps/gnome-power-manager/timeout/sleep_computer_ac --type=int 1200 %gconf_set /apps/gnome-power-manager/timeout/sleep_display_ac --type=int 300
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
Cheers, Magnus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
I move the slider to "never".
I wonder who and why designed a default to power off the machine when inactive. Just imagine a user power off a server like this! :-(
This was added due to a feature request for Energy Star;
# Enable Energy Star compliant default configuration %gconf_set /apps/gnome-power-manager/actions/sleep_type_battery --type=string "suspend" %gconf_set /apps/gnome-power-manager/timeout/sleep_computer_battery --type=int 1200 %gconf_set /apps/gnome-power-manager/timeout/sleep_computer_ac --type=int 1200 %gconf_set /apps/gnome-power-manager/timeout/sleep_display_ac --type=int 300
Argh.
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
Thank you!
While I agree that hibernating and powering off a computer that is doing nothing is generally a good idea, giving users that power of decision is not a good idea. It must be root who decides the policy, whatever it is: hibernate when idle, never hibernate, let user choose... whatever. Root must be king, regardless of what desktop the users use.
It gave me quite a fright: I thought it had crashed or something. There was noise in the room, the box is not in direct sight, so I didn't notice immediately it was off: just that it did not respond.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Le dimanche 26 octobre 2008, à 11:49 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html
Vincent
Carlos E. R. wrote:
While I agree that hibernating and powering off a computer that is doing nothing
I tend to disagree. Even an idle computer does _something_: It waits for commands from its master, maintaining quasi-immediate availability (quasi, because the screen goes black, but thats ~1 second).
Since the automatic sleeping seems to be on by default, this raises some questions: What mechanisms are in place to prevent the computer from going to sleep during an overnight compile job or download? What mechanism prevents a dual use desktop+server from going to sleep during lunch break? What about organizer-applications that want to (acoustically) notify me about something that's on my schedule while I am not using the PC?
Considering that, people may be, well, 'unhappy' about their computer going to sleep while it is supposed to be working. And this feature would probably be the first thing that I switch off.
Regards nordi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Carlos E. R. wrote:
While I agree that hibernating and powering off a computer that is doing nothing
I tend to disagree. Even an idle computer does _something_: It waits for commands from its master, maintaining quasi-immediate availability (quasi, because the screen goes black, but thats ~1 second).
You removed the second part of my paragraph that changed the meaning :-)
However, if you want to be polemic, a computer that is waiting for input is said to be idling in computer parlance. Doing almost nothing. Some designs slow down the CPU, or even actually send the CPU to sleep, on those phases. Events such a keypress or a timing interval can awake it. No such feature on PCs.
Since the automatic sleeping seems to be on by default, this raises some questions: What mechanisms are in place to prevent the computer from going to sleep during an overnight compile job or download? What mechanism prevents a dual use desktop+server from going to sleep during lunch break? What about organizer-applications that want to (acoustically) notify me about something that's on my schedule while I am not using the PC?
Well, the logic could detect "how busy" is the machine.
Considering that, people may be, well, 'unhappy' about their computer going to sleep while it is supposed to be working. And this feature would probably be the first thing that I switch off.
Well, Magnus already has said that he would change the default.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Le dimanche 26 octobre 2008, à 10:36 +0900, Magnus Boman a écrit :
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
This might not be an oversight -- you'd need to ask the person who implemented the Energy Star stuff.
Vincent
Le dimanche 26 octobre 2008, à 10:38 +0100, nordi a écrit :
Since the automatic sleeping seems to be on by default, this raises some questions: What mechanisms are in place to prevent the computer from going to sleep during an overnight compile job or download? What mechanism prevents a dual use desktop+server from going to sleep during lunch break? What about organizer-applications that want to (acoustically) notify me about something that's on my schedule while I am not using the PC?
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
Vincent
On Sun, 2008-10-26 at 11:12 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Carlos E. R. wrote:
While I agree that hibernating and powering off a computer that is doing nothing
I tend to disagree. Even an idle computer does _something_: It waits for commands from its master, maintaining quasi-immediate availability (quasi, because the screen goes black, but thats ~1 second).
You removed the second part of my paragraph that changed the meaning :-)
However, if you want to be polemic, a computer that is waiting for input is said to be idling in computer parlance. Doing almost nothing. Some designs slow down the CPU, or even actually send the CPU to sleep, on those phases. Events such a keypress or a timing interval can awake it. No such feature on PCs.
Since the automatic sleeping seems to be on by default, this raises some questions: What mechanisms are in place to prevent the computer from going to sleep during an overnight compile job or download? What mechanism prevents a dual use desktop+server from going to sleep during lunch break? What about organizer-applications that want to (acoustically) notify me about something that's on my schedule while I am not using the PC?
Well, the logic could detect "how busy" is the machine.
Considering that, people may be, well, 'unhappy' about their computer going to sleep while it is supposed to be working. And this feature would probably be the first thing that I switch off.
Well, Magnus already has said that he would change the default.
Oh, I hope I didn't say that :-) I will try to get it changed as, in my opinion, it shouldn't suspend by default.
Here's the bug report: https://bugzilla.novell.com/show_bug.cgi?id=439018
Cheers, Magnus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Not always the user is root, and not always it is a portable.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Le dimanche 26 octobre 2008, à 11:38 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
On Sun, 2008-10-26 at 11:12 +0100, Carlos E. R. wrote:
Well, Magnus already has said that he would change the default.
Oh, I hope I didn't say that :-) I will try to get it changed as, in my opinion, it shouldn't suspend by default.
Here's the bug report: https://bugzilla.novell.com/show_bug.cgi?id=439018
Ah! I see the difference :-)
I can add my opinion to the bug, if you like. I certainly dislike that thing being forced into us, and I very much want to disable it system-wide.
Just imagine the damage for server-type machines! Novell will be inundated with reports. Even for SLES/SLED: suppose an office where you need to retrieve a file from a shared folder of a co-worker while he is away.
This forced compliance thing is absurd, IMO.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:38 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
minas-morgul:~ # gconf-editor Cannot open display: Run 'gconf-editor --help' to see a full list of available command line options.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Regards nordi
Le dimanche 26 octobre 2008, à 11:53 +0100, nordi a écrit :
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Yes, all apps can do that: it's just a dbus call.
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Absolutely. I was quite "disturbed", and I'd be very annoyed if it weren't factory.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Absolutely.
This thing needs a module in Yast.
A module where root defines the overall policy for the entire system:
- allow/disallow users to manually hibernate - allow/disallow users to automatically hibernate when iddle - force machine to automatically hibernate when iddle - change policy depending on the hour: for example, if the machine is iddle after hours, allow/force hibernate it. - define admisible idling period
As it is now, it is more a damm nuisance than a feature :-/
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:49 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html
What, this?
gconftool-2 --direct \ --config-source configuration-source \ --type data-type \ --set preference-key value
Are you saying that I have to go down to the command line to configure a GUI? This is ridiculous. :-/
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Vincent Untz [2008-10-26 12:04]:
Le dimanche 26 octobre 2008, à 11:53 +0100, nordi a écrit :
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Yes, all apps can do that: it's just a dbus call.
"make" linked against libdbus. I always wanted that. Yeah.
Regards, Bernhard
* Carlos E. R. [2008-10-26 11:49]:
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:38 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
minas-morgul:~ # gconf-editor Cannot open display: Run 'gconf-editor --help' to see a full list of available command line options.
xhost +localhost (yes, it's insecure, but on a local workstation ...) More secure: ssh -X root@localhost
We used to have 'sux' in former times for exactly that reason, I don't know where and why it's gone.
Regards, Bernhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Yes, all apps can do that: it's just a dbus call.
Do they do it, now? On 11.1? All of them? :-(
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
How?
minas-morgul:~ # gconf-editor Cannot open display: Run 'gconf-editor --help' to see a full list of available command line options.
xhost +localhost (yes, it's insecure, but on a local workstation ...) More secure: ssh -X root@localhost
Doesn't work:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> sux - Password: minas-morgul:~ # gconf-editor Cannot open display: Run 'gconf-editor --help' to see a full list of available command line options.
We used to have 'sux' in former times for exactly that reason, I don't know where and why it's gone.
Sux can be recreated, it is a symlink. I have done so, but it doesn't work, either. I can not even run Yast in graphical mode.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Carlos E. R. [2008-10-26 12:16]:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> sux -
su(x) without -. You need to have DISPLAY=:0 in the environment, regardless of authentication.
Regards, Bernhard
Le dimanche 26 octobre 2008, à 12:09 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:49 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html
What, this?
gconftool-2 --direct \ --config-source configuration-source \ --type data-type \ --set preference-key value
Are you saying that I have to go down to the command line to configure a GUI? This is ridiculous. :-/
You can also use gconf-editor... The link just explains you how things work.
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 12:09 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:49 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html
What, this?
gconftool-2 --direct \ --config-source configuration-source \ --type data-type \ --set preference-key value
Are you saying that I have to go down to the command line to configure a GUI? This is ridiculous. :-/
You can also use gconf-editor... The link just explains you how things work.
No, gconf does not start. I already said that.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 12:16]:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> sux -
su(x) without -. You need to have DISPLAY=:0 in the environment, regardless of authentication.
You are a disbeliever, I see. I tell you it does not work, this is a new, and reported, bug in factory:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> set | grep DISPLAY DISPLAY=:0.0 cer@minas-morgul:~> su - Password: minas-morgul:~ # set | grep DISPLAY minas-morgul:~ # export DISPLAY=:0.0 minas-morgul:~ # gconf-editor Invalid MIT-MAGIC-COOKIE-1 keyCannot open display: Run 'gconf-editor --help' to see a full list of available command line options. minas-morgul:~ # set | grep DISPLAY DISPLAY=:0.0 minas-morgul:~ #
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Le dimanche 26 octobre 2008, à 12:12 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Yes, all apps can do that: it's just a dbus call.
Do they do it, now? On 11.1? All of them? :-(
No idea. That's why I said "can do" and not "do". Again, I'm just explaining how things work and I'm not saying the current setting makes sense...
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
Run gconf-editor, change /apps/gnome-power-manager/timeout/sleep_computer_ac to 0, right-click and select "Set as default" (not sure how it's called in english).
You can also do it with the command line if you want to automate this for multiple computers.
I didn't try it, so if it doesn't work, file a bug.
Vincent
Le dimanche 26 octobre 2008, à 12:20 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 12:09 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 11:49 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Sure, and root can do this via gconf (you can have mandatory settings, or change the default settings in gconf).
How?
http://library.gnome.org/admin/system-admin-guide/stable/gconf-7.html
What, this?
gconftool-2 --direct \ --config-source configuration-source \ --type data-type \ --set preference-key value
Are you saying that I have to go down to the command line to configure a GUI? This is ridiculous. :-/
You can also use gconf-editor... The link just explains you how things work.
No, gconf does not start. I already said that.
(I guess you mean gconf-editor, and not gconf)
Note that I didn't say that you have to launch gconf-editor as root. It should ask for a password if you try to change something while you don't have the right privileges (like setting the default or mandatory value for a gconf key).
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
How exactly do I disable that setting for all the users?
Run gconf-editor, change /apps/gnome-power-manager/timeout/sleep_computer_ac to 0, right-click and select "Set as default" (not sure how it's called in english).
You can also do it with the command line if you want to automate this for multiple computers.
I didn't try it, so if it doesn't work, file a bug.
It certainly doesn't, as I can't even run gconf :-(
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Carlos E. R. [2008-10-26 12:24]:
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 12:16]:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> sux -
su(x) without -. You need to have DISPLAY=:0 in the environment, regardless of authentication.
You are a disbeliever, I see. I tell you it does not work, this is a new, and reported, bug in factory:
If you know that this is a special bug in Factory, then why the noise here?! Factory is always a bit broken due to the nature of Factory, so well ...
But I think the "ssh -X root@localhost" thing should work regardless of that.
Regards, Bernhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
No, gconf does not start. I already said that.
(I guess you mean gconf-editor, and not gconf)
Of course, then I would have said "command not found".
Note that I didn't say that you have to launch gconf-editor as root. It should ask for a password if you try to change something while you don't have the right privileges (like setting the default or mandatory value for a gconf key).
Ok, I fire it as user, then search for "/apps/gnome-power-manager/timeout/sleep_computer_ac". I find it, and it contains:
sleep computer ac: 0 <===== sleep computer battery: 1200 sleep display ac: 300 sleep display battery: 300
This are obviously the settings for the current user, not the defaults for all users.
So, at least as user I can't change it. And I guess that as root it would change the setting for the root desktop, not all users either - if I could run gconf as root, that I can't.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
You are a disbeliever, I see. I tell you it does not work, this is a new, and reported, bug in factory:
If you know that this is a special bug in Factory, then why the noise here?! Factory is always a bit broken due to the nature of Factory, so well ...
Because I'm waiting for some one to acknowledge it and tell me how to repair it!
But I think the "ssh -X root@localhost" thing should work regardless of that.
No:
cer@minas-morgul:~> ssh -X root@localhost ssh: connect to host localhost port 22: Connection refused
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
But I think the "ssh -X root@localhost" thing should work regardless of that.
It doesn't work for two reasons.
One, the sshd daemon was dead. chkconfig said it was set to start on boot, but it did not, and did not report failure, therefore I didn't know.
Two, it does not work:
cer@minas-morgul:~> ssh -X root@localhost The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is 44:3e:9c:f0:65:63:34:5c:52:73:97:f0:b9:31:3c:ae. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Password: Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Sat Oct 25 17:05:31 2008 from console Have a lot of fun... minas-morgul:~ # gconf-editor Invalid MIT-MAGIC-COOKIE-1 keyCannot open display: Run 'gconf-editor --help' to see a full list of available command line options. minas-morgul:~ # set | grep DISPLAY DISPLAY=localhost:10.0 minas-morgul:~ #
So... I think I had enough of Beta 3, as I can't use Yast and continue testing, and nobody says how to repair this.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Carlos E. R. [2008-10-26 13:24]:
So... I think I had enough of Beta 3, as I can't use Yast and continue testing, and nobody says how to repair this.
Beta. You said it. (And you can use yast in ncurses mode. I always do that, regardless if X forwarding works or not.)
Regards, Bernhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 13:24]:
So... I think I had enough of Beta 3, as I can't use Yast and continue testing, and nobody says how to repair this.
Beta. You said it. (And you can use yast in ncurses mode. I always do that, regardless if X forwarding works or not.)
I know it is beta, it is not the first time I use factory. But at least I expect bugs to be acknowledged and be told how to repair, if possible, or how long to wait for a patch. Feedback goes in both directions, you know.
And yes, I've been using yast in ncurses mode, now and for years before now. To me, it is quite difficult or cumbersome to use, because:
- It doesn't allow mouse clicking: Midnight Commander, Alpine... use the mouse in text mode, in xterms. - Tab cycles, but you can't back-cycle by alt-tab. - To exit a menu I have to type Esc-Esc-Esc-[space|cursor] - Some options are missing or I can't find them: for instance, I wasn't able to configure my printer.
This is not new, it has always been so.
And then, instead of testing the features I was expecting to test, I find unexpected bugs that turn out to be unwanted, un-thought, features, like this automated hibernation thing, that I can't disable system-wide.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Le dimanche 26 octobre 2008, à 12:36 +0100, Carlos E. R. a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
No, gconf does not start. I already said that.
(I guess you mean gconf-editor, and not gconf)
Of course, then I would have said "command not found".
Saying "gconf does not start" implies for me that the gconf daemon does not start, and not gconf-editor.
Note that I didn't say that you have to launch gconf-editor as root. It should ask for a password if you try to change something while you don't have the right privileges (like setting the default or mandatory value for a gconf key).
Ok, I fire it as user, then search for "/apps/gnome-power-manager/timeout/sleep_computer_ac". I find it, and it contains:
sleep computer ac: 0 <===== sleep computer battery: 1200 sleep display ac: 300 sleep display battery: 300
This are obviously the settings for the current user, not the defaults for all users.
So, at least as user I can't change it. And I guess that as root it would change the setting for the root desktop, not all users either - if I could run gconf as root, that I can't.
Please carefully read http://lists.opensuse.org/opensuse-factory/2008-10/msg00549.html
Note that you can right-click on a setting and make it the default for all users.
Vincent
Hi,
Le dimanche 26 octobre 2008, à 13:58 +0100, Carlos E. R. a écrit :
And yes, I've been using yast in ncurses mode, now and for years before now. To me, it is quite difficult or cumbersome to use, because:
- It doesn't allow mouse clicking: Midnight Commander, Alpine... use
the mouse in text mode, in xterms.
Indeed, would be nice.
- Tab cycles, but you can't back-cycle by alt-tab.
shift+tab
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
(no idea about what this is -- I'm probably not used enough to yast)
- Some options are missing or I can't find them: for instance, I
wasn't able to configure my printer.
I can see the yast-printer stuff here. It's in hardware.
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 12:36 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
No, gconf does not start. I already said that.
(I guess you mean gconf-editor, and not gconf)
Of course, then I would have said "command not found".
Saying "gconf does not start" implies for me that the gconf daemon does not start, and not gconf-editor.
You are being too picky :-p
Ok, I fire it as user, then search for "/apps/gnome-power-manager/timeout/sleep_computer_ac". I find it, and it contains:
sleep computer ac: 0 <===== sleep computer battery: 1200 sleep display ac: 300 sleep display battery: 300
This are obviously the settings for the current user, not the defaults for all users.
So, at least as user I can't change it. And I guess that as root it would change the setting for the root desktop, not all users either - if I could run gconf as root, that I can't.
Please carefully read http://lists.opensuse.org/opensuse-factory/2008-10/msg00549.html
Note that you can right-click on a setting and make it the default for all users.
No, you can not. Or maybe you can, but I can't. When I try I get this message box:
] The application "gconf-editor" attempted to change an aspect of ] your configuration that your system administrator or operating ] system vendor does not allow you to change. Some of the settings ] you have selected may not take effect, or may not be restored ] next time you use the application.
Clicking Details, I get:
No database available to save your configuration: Unable to store a value at key '/apps/gnome-power-manager/timeout/sleep_computer_ac', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Carlos E. R. [2008-10-26 13:58]:
- It doesn't allow mouse clicking: Midnight Commander, Alpine... use
the mouse in text mode, in xterms.
Yes, that's not implemented. Would be nice, I agree.
- Tab cycles, but you can't back-cycle by alt-tab.
Shift-Tab works for me.
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
ESC (wait 1 sec) and then the menu is closed for me (yast autoyast).
- Some options are missing or I can't find them: for instance, I
wasn't able to configure my printer.
yast printer.
I almost never use that yast control center since that stuff never is there where I expect it to be ... "yast -l" lists all modules.
Regards, Bernhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
Hi,
Le dimanche 26 octobre 2008, à 13:58 +0100, Carlos E. R. a écrit :
And yes, I've been using yast in ncurses mode, now and for years before now. To me, it is quite difficult or cumbersome to use, because:
- It doesn't allow mouse clicking: Midnight Commander, Alpine... use
the mouse in text mode, in xterms.
Indeed, would be nice.
- Tab cycles, but you can't back-cycle by alt-tab.
shift+tab
Ah! Ok, one thing I didn't know. :-)
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
(no idea about what this is -- I'm probably not used enough to yast)
Well, I mean that if I try to escape, go away from a menu, Esc alone does not work, it is not recognized and I have to type it thrice. This is not yast fault alone, I have seen it elsewhere: in 'mc' I have to type Esc twice (one less). Or Esc and another key. It works as if Esc is a "dumb" key, like accents in Spanish or French.
Again, this is not new, has been this way since I came to linux a decade ago.
- Some options are missing or I can't find them: for instance, I
wasn't able to configure my printer.
I can see the yast-printer stuff here. It's in hardware.
Yes, of course it is, but it does not see my printer (an HP on the network), I have to manually tell it. When I tell it to test the port, to see if it "sees" the printer, it says nothing: neither failure nor success. When I tell it to find drivers, it gives the entire alphabetical printer list, and I get no drop-down manufacturer list to say "HP".
At this point, I don't know if there is a bug detecting/configuring printers, or if the ncurses interface is too poor or different for me to work it out.
Of course, I could add the printer directly in cups, but that's not what I want: first I allow yast to configure one printer, then I go to cups and modify.
Therefore, I need the yast graphical interface to test things.
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 13:58]:
- Tab cycles, but you can't back-cycle by alt-tab.
Shift-Tab works for me.
New to me, I did't expect it. The standard is alt. I'll try to remember this difference.
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
ESC (wait 1 sec) and then the menu is closed for me (yast autoyast).
Ok... it does, true. Still, it is confusing.
- Some options are missing or I can't find them: for instance, I
wasn't able to configure my printer.
yast printer.
I know, I don't mean that. See my reply a minute ago.
I almost never use that yast control center since that stuff never is there where I expect it to be ... "yast -l" lists all modules.
I'll try to remember this, but it is not the problem this time :-)
- -- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
* Carlos E. R. [2008-10-26 14:21]:
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
(no idea about what this is -- I'm probably not used enough to yast)
Well, I mean that if I try to escape, go away from a menu, Esc alone does not work, it is not recognized and I have to type it thrice. This is not yast fault alone, I have seen it elsewhere: in 'mc' I have to type Esc twice (one less). Or Esc and another key. It works as if Esc is a "dumb" key, like accents in Spanish or French.
That's how ESC works in Terminals. It comes from the fact that pressing Alt-C is the same like ESC c (not at the same time but one after another).
Regards, Bernhard
* Carlos E. R. [2008-10-26 14:25]:
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 13:58]:
- Tab cycles, but you can't back-cycle by alt-tab.
Shift-Tab works for me.
New to me, I did't expect it. The standard is alt.
Since when? Alt-Tab always cycles windows for me, even on Microsoft Windows. That's also how the key is labeled.
I'll try to remember this difference.
Shift-Tab works everywhere. Even Shift-Alt-Tab cycles windows in reverse order here.
- To exit a menu I have to type Esc-Esc-Esc-[space|cursor]
ESC (wait 1 sec) and then the menu is closed for me (yast autoyast).
Ok... it does, true. Still, it is confusing.
It is how ESC works on VT100 terminals (vi changes the terminal mode, but that means that Alt-<key> cannot be replaced by Esc-<key> any more and that's important for Yast if you use it from a "broken" Terminal).
Regards, Bernhard
----- Original Message ----- From: "Carlos E. R." carlos.e.r@opensuse.org To: "os-fctry" opensuse-factory@opensuse.org Sent: Sunday, October 26, 2008 6:04 AM Subject: Re: [opensuse-factory] Beta 3: Desktop machine hibernated on its own
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Absolutely. I was quite "disturbed", and I'd be very annoyed if it weren't factory.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Absolutely.
This thing needs a module in Yast.
A module where root defines the overall policy for the entire system:
- allow/disallow users to manually hibernate
- allow/disallow users to automatically hibernate when iddle
- force machine to automatically hibernate when iddle
- change policy depending on the hour: for example, if the machine is
iddle after hours, allow/force hibernate it.
- define admisible idling period
There should be a (or at least there was, if it's not there anymore, I haven't used Beta 3 yet) Power Management module in YaST. I'm sure it probably has control over the g-p-m app too, so it applies to all users (but I could be wrong).
As far as the setting, if the main desktop applications can tell the power management system to not turn off because it's doing something important (downloading podcasts in Banshee, burning a CD, etc.) then I wouldn't have a problem with it. Users running servers, as was alluded to in an earlier message, are probably savvy enough to check the power management system settings before putting that machine into production use. -- Kevin "Yeaux" Dupuy - openSUSE Member Public Mail - kevin.dupuy@opensuse.org Meet Bob Barr - Libertarian for President <www.BobBarr2008.com>
Carlos E. R. wrote:
Bernhard Walle wrote:
- Carlos E. R. [2008-10-26 12:16]:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> sux -
su(x) without -. You need to have DISPLAY=:0 in the environment, regardless of authentication.
You are a disbeliever, I see. I tell you it does not work, this is a new, and reported, bug in factory:
minas-morgul:~ # logout cer@minas-morgul:~> xhost +localhost localhost being added to access control list cer@minas-morgul:~> set | grep DISPLAY DISPLAY=:0.0 cer@minas-morgul:~> su - Password: minas-morgul:~ # set | grep DISPLAY minas-morgul:~ # export DISPLAY=:0.0 minas-morgul:~ # gconf-editor Invalid MIT-MAGIC-COOKIE-1 keyCannot open display:
I sometimes get this error to and have found a work-around. may be it will work for you to. As root go to the home dir of the user running the Desktop. The following works for me:
s050436: /home/jarno # cp .Xauthority ~/.Xauthority (The file has a name like this, typing .Xauth and auto-completion should give it, currently i'm working under windows and can't check it) now root should get access to the display
Run 'gconf-editor --help' to see a full list of available command line options. minas-morgul:~ # set | grep DISPLAY DISPLAY=:0.0 minas-morgul:~ #
Greetz, Jarno van Roosmalen
Le dimanche 26 octobre 2008, à 14:07 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
Le dimanche 26 octobre 2008, à 12:36 +0100, Carlos E. R. a écrit :
Vincent Untz wrote:
No, gconf does not start. I already said that.
(I guess you mean gconf-editor, and not gconf)
Of course, then I would have said "command not found".
Saying "gconf does not start" implies for me that the gconf daemon does not start, and not gconf-editor.
You are being too picky :-p
Not really: I really thought for a few seconds that your gconf daemon didn't start, and was wondering what was going on...
[...]
Note that you can right-click on a setting and make it the default for all users.
No, you can not. Or maybe you can, but I can't. When I try I get this message box:
Mmmh, interesting. It looks like the feature was half-done only upstream :/ I'll try to keep it in mind and finish it later.
Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2008-10-27 at 09:56 +0100, Vincent Untz wrote:
Saying "gconf does not start" implies for me that the gconf daemon does not start, and not gconf-editor.
You are being too picky :-p
Not really: I really thought for a few seconds that your gconf daemon didn't start, and was wondering what was going on...
Oops, sorry. I was just saving keypresses.
Note that you can right-click on a setting and make it the default for all users.
No, you can not. Or maybe you can, but I can't. When I try I get this message box:
Mmmh, interesting. It looks like the feature was half-done only upstream :/ I'll try to keep it in mind and finish it later.
I opened a bugzilla (439075) yesterday.
- -- Cheers, Carlos E. R.
Carlos E. R. wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
# awk '/shutdown|reboot|hibernate|suspend/ {print $1 " auth_admin_keep_always"}' \ < /etc/polkit-default-privs.standard >> /etc/polkit-default-privs.local # set_polkit_default_privs
cu Ludwig
* Ludwig Nussel [2008-10-27 10:01]:
Carlos E. R. wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
# awk '/shutdown|reboot|hibernate|suspend/ {print $1 " auth_admin_keep_always"}' \ < /etc/polkit-default-privs.standard >> /etc/polkit-default-privs.local # set_polkit_default_privs
Is there a good documentation about Policykit that contains such stuff?
Regards, Bernhard
Bernhard Walle wrote:
- Ludwig Nussel [2008-10-27 10:01]:
Carlos E. R. wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
# awk '/shutdown|reboot|hibernate|suspend/ {print $1 " auth_admin_keep_always"}' \ < /etc/polkit-default-privs.standard >> /etc/polkit-default-privs.local # set_polkit_default_privs
Is there a good documentation about Policykit that contains such stuff?
The above mechanism is basically a SUSE specific wrapper around polkit-action. See man polkit-default-privs and man polkit-action.
cu Ludwig
On Oct 26, 08 11:46:42 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
On Sun, 2008-10-26 at 11:12 +0100, Carlos E. R. wrote:
Well, Magnus already has said that he would change the default.
Oh, I hope I didn't say that :-) I will try to get it changed as, in my opinion, it shouldn't suspend by default.
Here's the bug report: https://bugzilla.novell.com/show_bug.cgi?id=439018
Ah! I see the difference :-)
I can add my opinion to the bug, if you like. I certainly dislike that thing being forced into us, and I very much want to disable it system-wide.
Just imagine the damage for server-type machines! Novell will be inundated with reports. Even for SLES/SLED: suppose an office where you need to retrieve a file from a shared folder of a co-worker while he is away.
A server machine that runs openSUSE is something different than a server running SLES. I hope we agree on that.
This forced compliance thing is absurd, IMO.
for some, perhaps. For others not. the reason, as said on other place is Energy Star compliance. If openSUSE 11.1 will have this activated by default needs to be decided by coolo and his product manager. It could - and may be should - different than an Enterprise product.
Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2008-10-27 at 22:51 +0100, Stefan Behlert wrote:
Just imagine the damage for server-type machines! Novell will be inundated with reports. Even for SLES/SLED: suppose an office where you need to retrieve a file from a shared folder of a co-worker while he is away.
A server machine that runs openSUSE is something different than a server running SLES. I hope we agree on that.
Of course, but irrelevant. Both are servers, only that one pays you >:-)
This forced compliance thing is absurd, IMO.
for some, perhaps. For others not. the reason, as said on other place is Energy Star compliance.
OpenSUSE is not certified, so it can not be compliant. AFAIK, it only applies to machines sold with software and both certified. And it does not apply to servers: pg. 11, secction 3 - "All products, except for desktop-derived servers". Also, AFAIK, the product has to be labeled on the box as such with instructions:
- ---- Either option must at least include the following information:
# Notice that the computer has been shipped enabled for power management and what the time settings are; and # How to properly wake the computer from Sleep mode; - ----
If openSUSE 11.1 will have this activated by default needs to be decided by coolo and his product manager. It could - and may be should - different than an Enterprise product.
It is different.
If you have to add this (does KDE enforce this compliance?) you must make it configurable via Yast.
- -- Cheers, Carlos E. R.
On Mon, 2008-10-27 at 22:51 +0100, Stefan Behlert wrote:
On Oct 26, 08 11:46:42 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
On Sun, 2008-10-26 at 11:12 +0100, Carlos E. R. wrote:
Well, Magnus already has said that he would change the default.
Oh, I hope I didn't say that :-) I will try to get it changed as, in my opinion, it shouldn't suspend by default.
Here's the bug report: https://bugzilla.novell.com/show_bug.cgi?id=439018
Ah! I see the difference :-)
I can add my opinion to the bug, if you like. I certainly dislike that thing being forced into us, and I very much want to disable it system-wide.
Just imagine the damage for server-type machines! Novell will be inundated with reports. Even for SLES/SLED: suppose an office where you need to retrieve a file from a shared folder of a co-worker while he is away.
A server machine that runs openSUSE is something different than a server running SLES. I hope we agree on that.
This forced compliance thing is absurd, IMO.
for some, perhaps. For others not. the reason, as said on other place is Energy Star compliance. If openSUSE 11.1 will have this activated by default needs to be decided by coolo and his product manager. It could - and may be should - different than an Enterprise product.
For SLED, it would make sense as, in most cases, the Desktop would be setup by system administrators. For openSUSE, people with limited knowledge will likely think that something is wrong, either with the install or with their machine. I really think we could gain a bad reputation by having this by default. I guess one way to solve it would be to ask the user if it's ok to suspend when machine has been inactive for 30 minutes. On a multi-user system, if one user answers Yes and another answers No, then PolicyKit (ConsoleKit?) should not allow it to suspend if the user who answered No is logged in.
Cheers, Magnus
Vincent Untz escribió:
Le dimanche 26 octobre 2008, à 10:36 +0900, Magnus Boman a écrit :
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
This might not be an oversight -- you'd need to ask the person who implemented the Energy Star stuff.
I hope it is, forcing to hibernate by default, without asking looks plain wrong.
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
On Oct 28, 08 00:57:13 -0300, Cristian RodrÃguez wrote: [...]
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
It should be mentioned there, yes. And it's already on the list for the release notes. As usual, the releasenotes are just not finished. We are at beta, still :( but you know that :)
Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.00.0810281218430.4842@nimrodel.valinor
On Tuesday, 2008-10-28 at 00:57 -0300, Cristian RodrÃguez wrote:
Vincent Untz escribió:
Le dimanche 26 octobre 2008, à 10:36 +0900, Magnus Boman a écrit :
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
This might not be an oversight -- you'd need to ask the person who implemented the Energy Star stuff.
I hope it is, forcing to hibernate by default, without asking looks plain wrong.
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
Absolutely!
You (Novell) should remember that a system must be tested before been allowed to hibernate. And for compliance, certified, too: openSUSE can not be certified.
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
Has Novell tested, solved, and certified that this works correctly now?
- -- Cheers, Carlos E. R.
Carlos E. R. wrote:
Vincent Untz escribió:
I hope it is, forcing to hibernate by default, without asking looks plain wrong.
+1 but see below
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
IMHO the hibernate should be aborted if open files are found on external (e.g. USB) drives that will be lost due to storage sub-system crashes on hibernation, at least until that storage sub-system is fixed and able to survive the hibernation. It's not as if such open files aren't easy to detect.
This (abort on open files) should be the case even if hibernation is manually instigated by the user from the desktop, though perhaps a "-F | --force" command-line option might be implemented to allow it to be forced. It's absolutely essential if hibernation might be instigated by a default policy.
I should add that I'm all in favour of power-saving measures such as hibernation - but they do require prior resolution of issues such as this. Until then it mustn't be the default.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2008-10-28 at 11:43 -0000, Richard (MQ) wrote:
This (abort on open files) should be the case even if hibernation is manually instigated by the user from the desktop, though perhaps a "-F | --force" command-line option might be implemented to allow it to be forced. It's absolutely essential if hibernation might be instigated by a default policy.
Rather pop up a dialog - if the hibernation is triggered from the desktop. If it comes from a command like "powersave -U" it has to be forced (it may come from low UPS battery alarm). Same for low battery. Also to consider is if the user closes the lid of a portable, I think it should be forced, or give a loud audible warning.
And all this should be configurable by root via Yast.
I should add that I'm all in favour of power-saving measures such as hibernation - but they do require prior resolution of issues such as this. Until then it mustn't be the default.
Absolutely!
- -- Cheers, Carlos E. R.
On Oct 27, 08 23:14:55 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2008-10-27 at 22:51 +0100, Stefan Behlert wrote:
Just imagine the damage for server-type machines! Novell will be inundated with reports. Even for SLES/SLED: suppose an office where you need to retrieve a file from a shared folder of a co-worker while he is away.
A server machine that runs openSUSE is something different than a server running SLES. I hope we agree on that.
Of course, but irrelevant. Both are servers, only that one pays you >:-)
I disagree with the 'irrelevant'. If you try to drive a VW Beagle like a Ferrari Testerossa, you cannot complain about different driving behavior. If you use openSUSE as a server OS, you should a) know what you do b) be prepared to make adjustments in the default configuration If you expect the same default configuration on a desktop and a server product, something is wrong :)
Doesn't hinder you to pay for both :) :)
This forced compliance thing is absurd, IMO.
for some, perhaps. For others not. the reason, as said on other place is Energy Star compliance.
OpenSUSE is not certified, so it can not be compliant. AFAIK, it only applies to machines sold with software and both certified. And it does not
Correct. To avoid being picky: It is prepared to allow compliance easily. You asked for a reason, and someone complained already in this thread about too much pickiness, so let's say 'is prepared for'. That's the reason. Not the fact that someone is aftter you :)
apply to servers: pg. 11, secction 3 - "All products, except for desktop-derived servers". Also, AFAIK, the product has to be labeled on the box as such with instructions:
I'm not sure why you mention this? openSUSE is not made for servers? You _can_ use it on a server. If it's wise, good, and recommended - that's something different.
[...]
If openSUSE 11.1 will have this activated by default needs to be decided by coolo and his product manager. It could - and may be should - different than an Enterprise product.
It is different.
Is it? I thought SLED and openSUSE currently show the same behavior.
Stefan
On Wed 29. Oct - 14:10:00, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
There should be a (or at least there was, if it's not there anymore, I haven't used Beta 3 yet) Power Management module in YaST. I'm sure it probably has control over the g-p-m app too, so it applies to all users (but I could be wrong).
No, there isn't anymore. Power Management is controlled on the desktop by the user. And I think that's actually what 99% of all usual home users want.
Yes, as long as we (users) make the decision to hibernate automatically or not. It is different when you set the default to hibernate without asking us.
As you said, it's just a decision which have to be made, others would maybe say, wow, what a good default, it helps to save the environment.
For instance: my home machine serves a samba share to my external digital TV box, so that it can do time shifting and recording. With your default of hibernating, you can make it loose data!
That's advanced, you are root, you know what you do, you can change the default. And yes, it will be in the release notes.
And even on homes, a machine can have several users, and I have no click
If one user session isn't active, aka another user is logged in, the inactive session won't trigger a autosuspend.
and shoot method of changing that default. That's all I ask: either change the default, or provide a click and shoot method (or CLI script at least) to change that default system wide.
That would be an easy script calling 'sed', I'll provide one on the upcoming wiki page.
Regards, Holger
Hi,
sorry for stepping in late, I'm actually the one guilty for all this :-)
On Sun 26. Oct - 00:30:02, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates
I hope you mean suspend (s2ram) and not hibernate (s2disk)?
Regards, Holger
On Sun 26. Oct - 01:04:19, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Magnus Boman wrote:
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
...
Is this an optional setting? Where do I look, where to disable?
Right click on GNOME Power Manager in your tray (battery icon),
No such thing.
The gnome-power-manager applet is not shown by default when running on AC power, so you have to go for
gnome-control-center --> Power Management
Regards, HOlger
On Sun 26. Oct - 11:38:55, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Not always the user is root, and not always it is a portable.
Just disable "suspend" for the usual user through /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
Indeed, a YaST module for all PolicyKit configurations would be nice.
Regards, Holger
On Sun 26. Oct - 11:53:44, nordi wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
As Vincent already mentioned, gnome-power-manager has a D-Bus interface to inhibit a suspend, kpowersave doesn't.
Actually it's a question about for whom is openSUSE designed for. If you have the "common desktop user" as a target group, you could assume that he just uses the default desktop applications. And all those could trigger a suspend inhibition. If they don't, and it makes sense, it's a bug.
Regards, Holger
On Sun 26. Oct - 12:12:52, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Untz wrote:
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Yes, all apps can do that: it's just a dbus call.
Do they do it, now? On 11.1? All of them? :-(
Assuming that it's mentioned in the release notes, user who use other applications than the default ones, they also know how to change the default settings.
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
Change who's allowed to suspend the system in /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
Regards, Holger
On Sun 26. Oct - 12:04:35, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Absolutely. I was quite "disturbed", and I'd be very annoyed if it weren't factory.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Absolutely.
This thing needs a module in Yast.
Not necessarily. Someone who uses openSUSE in an advanced way should be able to do advanced things. Like editing the PolicyKit configuration with vi.
Regards, Holger
On Sun 26. Oct - 20:11:18, Kevin Yeaux wrote:
----- Original Message ----- From: "Carlos E. R." carlos.e.r@opensuse.org To: "os-fctry" opensuse-factory@opensuse.org Sent: Sunday, October 26, 2008 6:04 AM Subject: Re: [opensuse-factory] Beta 3: Desktop machine hibernated on its own
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
nordi wrote:
Vincent Untz wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Absolutely. I was quite "disturbed", and I'd be very annoyed if it weren't factory.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
Absolutely.
This thing needs a module in Yast.
A module where root defines the overall policy for the entire system:
- allow/disallow users to manually hibernate
- allow/disallow users to automatically hibernate when iddle
- force machine to automatically hibernate when iddle
- change policy depending on the hour: for example, if the machine is
iddle after hours, allow/force hibernate it.
- define admisible idling period
There should be a (or at least there was, if it's not there anymore, I haven't used Beta 3 yet) Power Management module in YaST. I'm sure it probably has control over the g-p-m app too, so it applies to all users (but I could be wrong).
No, there isn't anymore. Power Management is controlled on the desktop by the user. And I think that's actually what 99% of all usual home users want.
As far as the setting, if the main desktop applications can tell the power management system to not turn off because it's doing something important (downloading podcasts in Banshee, burning a CD, etc.) then I wouldn't have a problem with it. Users running servers, as was alluded to in an earlier message, are probably savvy enough to check the power management system settings before putting that machine into production use.
Regards, Holger
On Tue 28. Oct - 12:22:13, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.00.0810281218430.4842@nimrodel.valinor
On Tuesday, 2008-10-28 at 00:57 -0300, Cristian RodrÃguez wrote:
Vincent Untz escribió:
Le dimanche 26 octobre 2008, à 10:36 +0900, Magnus Boman a écrit :
Looking at the default for GNOME Power Manager AC settings, if a timeout is set, it will suspend. This is most likely an oversight and I'll pursue this to get it fixed.
This might not be an oversight -- you'd need to ask the person who implemented the Energy Star stuff.
I hope it is, forcing to hibernate by default, without asking looks plain wrong.
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
Absolutely!
You (Novell) should remember that a system must be tested before been allowed to hibernate. And for compliance, certified, too: openSUSE can not be certified.
Default configuration should be to _suspend_ (the fast one), not to hibernate. And we have a whitelist for all working machines which are able to _suspend_. For desktops, I guess these are still quite a few.
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
Different problem, however a problem ;-)
Has Novell tested, solved, and certified that this works correctly now?
Do you have the bug id?
Regards, Holger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.00.0810291343550.4858@nimrodel.valinor
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
On Tue 28. Oct - 12:22:13, Carlos E. R. wrote:
On Tuesday, 2008-10-28 at 00:57 -0300, Cristian RodrÃguez wrote:
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
Absolutely!
You (Novell) should remember that a system must be tested before been allowed to hibernate. And for compliance, certified, too: openSUSE can not be certified.
Default configuration should be to _suspend_ (the fast one), not to hibernate. And we have a whitelist for all working machines which are able to _suspend_. For desktops, I guess these are still quite a few.
Suspend to memory in my desktop is broken, the cpu fans stops and the cpu reaches very high temperatures. Known bios bug, not your problem: nevertheless, dangerous if 'you' decide to suspend my machine.
You should not neither suspend or hibernate a machine by default, this must be the owner decision. This is openSUSE, not sles/sled.
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
Different problem, however a problem ;-)
Has Novell tested, solved, and certified that this works correctly now?
Do you have the bug id?
Yes, 439663.
And it took me an entire afternoon to prepare the test, run it, and report it. I'd expect it not to be dismissed after a perfunctory read.
The old bug was 343874, which was closed as INVALID because that disk was mounted via fstab (!). The current one I tested with:
- a reiser partition mounted via fstab - a reiser partition mounted automatically by gnome desktop - an encrypted (LUKS) reiser partition mounted via /etc/crypttab, /etc/fstab/, via the script /etc/init.d/boot.crypto - an encrypted (LUKS) reiser partition mounted automatically via the desktop - a flash type usb keychain with vfat mounted automatically.
The main problem is that a mounted external filesystem changes device when thawed, from /dev/sda to /dev/sdc, for example. It does not survive.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:26 +0100, Holger Macht wrote:
Right click on GNOME Power Manager in your tray (battery icon),
No such thing.
The gnome-power-manager applet is not shown by default when running on AC power, so you have to go for
gnome-control-center --> Power Management
Which breaks the Energy Star rule that this thing should be clearly labeled for the user.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:26 +0100, Holger Macht wrote:
Hi,
sorry for stepping in late, I'm actually the one guilty for all this :-)
Ah, thanks :-)
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates
I hope you mean suspend (s2ram) and not hibernate (s2disk)?
Nope. The machine hibernated on its own. Which was lucky, because if it had suspended to ram the cpu would have burnt. Known bios bug.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
Yes, all apps can do that: it's just a dbus call.
Do they do it, now? On 11.1? All of them? :-(
Assuming that it's mentioned in the release notes, user who use other applications than the default ones, they also know how to change the default settings.
If they know they have to change something! I didn't know.
I assume you mean that "gcc" is not a default app? Because it will not be detected. Or thunderbird? My machine hybernated while I had a Thunderbird session opened and connected to two remote imap servers.
Plus, there is no _easy_ method for root to change this default systemwise. Gconf-editor is broken in this respect (bugzilla filled), and an exact command line to dissable autohibernation is not published, AFAIK.
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
Change who's allowed to suspend the system in /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
Which is not easy!
I'm not a professional sysadmin (this is not SLES), so I have no idea how to change that policy. First provide a GUI tool to change those settins, then come back and tell us :-|
Further: I do want to hybernate my machine, I do it several times a day. But _I_, not you. On my command, when I know it is safe.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
There should be a (or at least there was, if it's not there anymore, I haven't used Beta 3 yet) Power Management module in YaST. I'm sure it probably has control over the g-p-m app too, so it applies to all users (but I could be wrong).
No, there isn't anymore. Power Management is controlled on the desktop by the user. And I think that's actually what 99% of all usual home users want.
Yes, as long as we (users) make the decision to hibernate automatically or not. It is different when you set the default to hibernate without asking us.
For instance: my home machine serves a samba share to my external digital TV box, so that it can do time shifting and recording. With your default of hibernating, you can make it loose data!
And even on homes, a machine can have several users, and I have no click and shoot method of changing that default. That's all I ask: either change the default, or provide a click and shoot method (or CLI script at least) to change that default system wide.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
Absolutely.
This thing needs a module in Yast.
Not necessarily. Someone who uses openSUSE in an advanced way should be able to do advanced things. Like editing the PolicyKit configuration with vi.
You gotta be kidding! :-/
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
A user that is not the admin of the (home) machine will not have read the release notes. If you keep that setting it must be announced to each user.
Plus, the user might be a KDE user, which one days switches to gnome to try it. Bingo! Lost data.
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
As Vincent already mentioned, gnome-power-manager has a D-Bus interface to inhibit a suspend, kpowersave doesn't.
Actually it's a question about for whom is openSUSE designed for. If you have the "common desktop user" as a target group, you could assume that he just uses the default desktop applications. And all those could trigger a suspend inhibition. If they don't, and it makes sense, it's a bug.
Is a samba share to another computer considered a default app by you? NFS? Imap? They are used on homes.
You are wrong, all applications shipped by openSUSE/ SuSE/ Novell/ buildservice should be compliant. You can not force us to only use "gnome" apps.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
gnome-power-manager has some inhibit mechanisms. This means an application can say "don't suspend" (eg, when you're burning a CD). And the user can also control this with an applet.
However, root should be able to control what power he gives the users over this. Root should be able to disable the ability of users to power off, reset, or hibernate the computer, or on the contrary, force an hibernation; and this regardless of what desktop the user is using.
Not always the user is root, and not always it is a portable.
Just disable "suspend" for the usual user through /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
When you provide a GUI to it or a holdmyhandstepbystep manual.
Indeed, a YaST module for all PolicyKit configurations would be nice.
Indeed!
- -- Cheers, Carlos E. R.
Sorry if this was just suggester.
Why don't create a popup on both gnome and kde to show the first time the suspend procedure starts to ask the user if he wants to keep this behaviour as default? This will avoid problems avoiding the first auto-suspend and have the advantage to let the user choose the preferred behaviour of it's system.
What do you think?
On Wed 29. Oct - 14:04:09, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
Yes, all apps can do that: it's just a dbus call.
Do they do it, now? On 11.1? All of them? :-(
Assuming that it's mentioned in the release notes, user who use other applications than the default ones, they also know how to change the default settings.
If they know they have to change something! I didn't know.
I assume you mean that "gcc" is not a default app? Because it will not be detected. Or thunderbird? My machine hybernated while I had a Thunderbird session opened and connected to two remote imap servers.
The application does not have to be detected, it has to inform the freedesktop.org interface that it's something doing and thus the system should not be suspended. These days _every_ applications should be power management aware, because it's just something omnipresent. So yes, a bugreport agains Thunderbird, preferably upstream, would be a good idea.
Plus, there is no _easy_ method for root to change this default systemwise.
Root shouldn't have to do this, but the user. In most cases, for servers, you don't have a full blows GNOME/KDE desktop at all, so this shouldn't be an issue there. And nobody said it should be easy.
Gconf-editor is broken in this respect (bugzilla filled), and an exact command line to dissable autohibernation is not published, AFAIK.
I'll create a www.opensuse.org/EnergyStar page to include the rationale and tips and tricks.
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
Change who's allowed to suspend the system in /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
Which is not easy!
I'm not a professional sysadmin (this is not SLES), so I have no idea how to change that policy. First provide a GUI tool to change those settins, then come back and tell us :-|
gnome-control-center -> Power Management
Further: I do want to hybernate my machine, I do it several times a day. But _I_, not you. On my command, when I know it is safe.
It's just the default, so you are free to change it.
Regards, Holger
On Wed 29. Oct - 14:16:36, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
A user that is not the admin of the (home) machine will not have read the release notes. If you keep that setting it must be announced to each user.
Plus, the user might be a KDE user, which one days switches to gnome to try it. Bingo! Lost data.
Lost data must not happen. Concrete example?
I also doubt that apache, gcc/make or $favoriteP2Pclient are capable of telling Gnome to leave the computer running. Even if a application can do that, can a KDE application tell Gnome, can a Gnome application tell KDE to not shut down the system?
As Vincent already mentioned, gnome-power-manager has a D-Bus interface to inhibit a suspend, kpowersave doesn't.
Actually it's a question about for whom is openSUSE designed for. If you have the "common desktop user" as a target group, you could assume that he just uses the default desktop applications. And all those could trigger a suspend inhibition. If they don't, and it makes sense, it's a bug.
Is a samba share to another computer considered a default app by you? NFS? Imap? They are used on homes.
You are wrong, all applications shipped by openSUSE/ SuSE/ Novell/ buildservice should be compliant. You can not force us to only use "gnome" apps.
It should not hurt, really, every application should be able to properly recover from a system sleep. Yes, a lot works needs to be done, but it has to be done.
Regards, Holger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:22 +0100, Holger Macht wrote:
Assuming that it's mentioned in the release notes, user who use other applications than the default ones, they also know how to change the default settings.
If they know they have to change something! I didn't know.
I assume you mean that "gcc" is not a default app? Because it will not be detected. Or thunderbird? My machine hybernated while I had a Thunderbird session opened and connected to two remote imap servers.
The application does not have to be detected, it has to inform the freedesktop.org interface that it's something doing and thus the system should not be suspended. These days _every_ applications should be power management aware, because it's just something omnipresent. So yes, a bugreport agains Thunderbird, preferably upstream, would be a good idea.
No, sorry. It was your decission to implement this default, so you search for non-compliant apps. I'm wasting a lot of my valuable time as it is on this absurd default thing :/
Plus, there is no _easy_ method for root to change this default systemwise.
Root shouldn't have to do this, but the user. In most cases, for servers, you don't have a full blows GNOME/KDE desktop at all, so this shouldn't be an issue there. And nobody said it should be easy.
Oh, yes, it has to be easy. Remember we are talking about openSUSE, not SLES.
Gconf-editor is broken in this respect (bugzilla filled), and an exact command line to dissable autohibernation is not published, AFAIK.
I'll create a www.opensuse.org/EnergyStar page to include the rationale and tips and tricks.
That might help. But better change the default, and let the user change it. Ie, the other way round. Our decision to autohibernate, not yours.
I'm not saying this setting makes sense by default -- I changed it on my computer ;-) I'm merely explaining how things could work.
How exactly do I disable that setting for all the users?
Change who's allowed to suspend the system in /usr/share/PolicyKit/policy/org.freedesktop.hal.power-management.policy
Which is not easy!
I'm not a professional sysadmin (this is not SLES), so I have no idea how to change that policy. First provide a GUI tool to change those settins, then come back and tell us :-|
gnome-control-center -> Power Management
That only works for the current user.
Further: I do want to hybernate my machine, I do it several times a day. But _I_, not you. On my command, when I know it is safe.
It's just the default, so you are free to change it.
Not system wide, I'm not! :-/
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:19 +0100, opensourcecat wrote:
Sorry if this was just suggester.
Why don't create a popup on both gnome and kde to show the first time the suspend procedure starts to ask the user if he wants to keep this behaviour as default? This will avoid problems avoiding the first auto-suspend and have the advantage to let the user choose the preferred behaviour of it's system.
What do you think?
That would be better.
And even better if root can change the default systemwide with a single command.
- -- Cheers, Carlos E. R.
On Wed 29. Oct - 13:52:48, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.2.00.0810291343550.4858@nimrodel.valinor
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
On Tue 28. Oct - 12:22:13, Carlos E. R. wrote:
On Tuesday, 2008-10-28 at 00:57 -0300, Cristian RodrÃguez wrote:
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
Absolutely!
You (Novell) should remember that a system must be tested before been allowed to hibernate. And for compliance, certified, too: openSUSE can not be certified.
Default configuration should be to _suspend_ (the fast one), not to hibernate. And we have a whitelist for all working machines which are able to _suspend_. For desktops, I guess these are still quite a few.
Suspend to memory in my desktop is broken, the cpu fans stops and the cpu reaches very high temperatures. Known bios bug, not your problem: nevertheless, dangerous if 'you' decide to suspend my machine.
Please post the output of 's2ram -n'. If it's not known to be working, it won't suspend.
You should not neither suspend or hibernate a machine by default, this must be the owner decision. This is openSUSE, not sles/sled.
_It is_ a user decision, the user can easily change the default.
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
Different problem, however a problem ;-)
Has Novell tested, solved, and certified that this works correctly now?
Do you have the bug id?
Yes, 439663.
Isn't this actually a dup of 439018? Anyway I'll look into this story ;-)
Regards, Holger
And it took me an entire afternoon to prepare the test, run it, and report it. I'd expect it not to be dismissed after a perfunctory read.
The old bug was 343874, which was closed as INVALID because that disk was mounted via fstab (!). The current one I tested with:
- a reiser partition mounted via fstab
- a reiser partition mounted automatically by gnome desktop
- an encrypted (LUKS) reiser partition mounted via /etc/crypttab, /etc/fstab/, via the script /etc/init.d/boot.crypto
- an encrypted (LUKS) reiser partition mounted automatically via the desktop
- a flash type usb keychain with vfat mounted automatically.
The main problem is that a mounted external filesystem changes device when thawed, from /dev/sda to /dev/sdc, for example. It does not survive.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkIXKMACgkQtTMYHG2NR9U+CACfeNhIJYLnGS4bw5FQmS2rLrNc 12gAoJNmtXIIktH4j5An7NRc2jbcu/ry =W83g -----END PGP SIGNATURE-----
On Wed 29. Oct - 14:31:27, Holger Macht wrote:
On Wed 29. Oct - 14:16:36, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
But if the user does not expect the system to shutdown he will not change any settings and might be very annoyed the first time that happens. So it should at least be mentionned in the release notes or, even better, be switched off for openSuse, just as suggested in the bug report.
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
A user that is not the admin of the (home) machine will not have read the release notes. If you keep that setting it must be announced to each user.
Plus, the user might be a KDE user, which one days switches to gnome to try it. Bingo! Lost data.
Lost data must not happen. Concrete example?
Ok, forget this one, you've included it in your bug report.
Regards, Holger
On Wed 29. Oct - 13:56:38, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 13:26 +0100, Holger Macht wrote:
Hi,
sorry for stepping in late, I'm actually the one guilty for all this :-)
Ah, thanks :-)
Default Beta 3, gnome, fresh install.
I left the machine running while I had my dinner. When I came back, the machine was off, hibernating:
22:23:29 I left it. 22:53:28 Machine hibernates
I hope you mean suspend (s2ram) and not hibernate (s2disk)?
Nope. The machine hibernated on its own. Which was lucky, because if it had suspended to ram the cpu would have burnt. Known bios bug.
Please report this. This are actually two bugs, the one that we should only do automatic _suspend_ and that your system is obviously in the whitelist although not working.
Regards, Holger
On Wed 29. Oct - 14:19:56, opensourcecat wrote:
Sorry if this was just suggester.
Why don't create a popup on both gnome and kde to show the first time the suspend procedure starts to ask the user if he wants to keep this behaviour as default? This will avoid problems avoiding the first auto-suspend and have the advantage to let the user choose the preferred behaviour of it's system.
What do you think?
That sounds good. I'll see if we can still get this in. However, this is only an option (and a good one) for openSUSE.
Regards, Holger
On Wed 29. Oct - 14:32:19, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:22 +0100, Holger Macht wrote:
Assuming that it's mentioned in the release notes, user who use other applications than the default ones, they also know how to change the default settings.
If they know they have to change something! I didn't know.
I assume you mean that "gcc" is not a default app? Because it will not be detected. Or thunderbird? My machine hybernated while I had a Thunderbird session opened and connected to two remote imap servers.
The application does not have to be detected, it has to inform the freedesktop.org interface that it's something doing and thus the system should not be suspended. These days _every_ applications should be power management aware, because it's just something omnipresent. So yes, a bugreport agains Thunderbird, preferably upstream, would be a good idea.
No, sorry. It was your decission to implement this default, so you search for non-compliant apps. I'm wasting a lot of my valuable time as it is on this absurd default thing :/
No, it wasn't my decision, but my proposal.
Plus, there is no _easy_ method for root to change this default systemwise.
Root shouldn't have to do this, but the user. In most cases, for servers, you don't have a full blows GNOME/KDE desktop at all, so this shouldn't be an issue there. And nobody said it should be easy.
Oh, yes, it has to be easy. Remember we are talking about openSUSE, not SLES.
Gconf-editor is broken in this respect (bugzilla filled), and an exact command line to dissable autohibernation is not published, AFAIK.
I'll create a www.opensuse.org/EnergyStar page to include the rationale and tips and tricks.
That might help. But better change the default, and let the user change it. Ie, the other way round. Our decision to autohibernate, not yours.
And not my decision in the end ;-)
Regards, Holger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:35 +0100, Holger Macht wrote:
Default configuration should be to _suspend_ (the fast one), not to hibernate. And we have a whitelist for all working machines which are able to _suspend_. For desktops, I guess these are still quite a few.
Suspend to memory in my desktop is broken, the cpu fans stops and the cpu reaches very high temperatures. Known bios bug, not your problem: nevertheless, dangerous if 'you' decide to suspend my machine.
Please post the output of 's2ram -n'. If it's not known to be working, it won't suspend.
nimrodel:~ # s2ram -n Machine unknown This machine can be identified by: sys_vendor = "NETWORK" sys_product = " " sys_version = " " bios_version = ""
- From hwinfo, bios:
Vendor: "Award Software International, Inc." Version: "6.00 PG"
Board Info: #2 Manufacturer: "MICRO-STAR INTERNATIONAL CO., LTD" Product: "MS-6534"
There is an upgrade for the faulty bios, but for the other alternate bios maker, not mine.
Notice that hybernation works, suspend doesn't - well it works, but cpu fan stops and cpu heats a lot.
You should not neither suspend or hibernate a machine by default, this must be the owner decision. This is openSUSE, not sles/sled.
_It is_ a user decision, the user can easily change the default.
After the dameage!
Do you have the bug id?
Yes, 439663.
Isn't this actually a dup of 439018? Anyway I'll look into this story ;-)
No, it is not. It is the problem of machine hybernating with open files on external media, and this media not recovering and files being lost.
Machine should not autohibernate on that situation. Or with NFS sessions opened, or whatever network connections opened.
- -- Cheers, Carlos E. R.
----- Original Message ----- From: "Holger Macht" hmacht@suse.de To: "Kevin Yeaux" kevin.dupuy@opensuse.org Cc: "Carlos E. R." carlos.e.r@opensuse.org; "os-fctry" opensuse-factory@opensuse.org Sent: Wednesday, October 29, 2008 7:27 AM
There should be a (or at least there was, if it's not there anymore, I haven't used Beta 3 yet) Power Management module in YaST. I'm sure it probably has control over the g-p-m app too, so it applies to all users (but I could be wrong).
No, there isn't anymore. Power Management is controlled on the desktop by the user. And I think that's actually what 99% of all usual home users want.
OK, well in thatcase there should be some way to turn off this setting system-wide. This isn't just for expert users. Think of the father at home that doesn't want the computer turning off just because his kids are done doing their homework in their own accounts. -- Kevin "Yeaux" Dupuy - openSUSE Member Public Mail - kevin.dupuy@opensuse.org Meet Bob Barr - Libertarian for President <www.BobBarr2008.com>
Hello,
on Mittwoch, 29. Oktober 2008, Holger Macht wrote: ...
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
I have already opened a request to add a section to the release notes: https://bugzilla.novell.com/show_bug.cgi?id=439980 No need to open a new one, just add your text there ;-)
Actually it's a question about for whom is openSUSE designed for. If you have the "common desktop user" as a target group, you could assume that he just uses the default desktop applications. And all those could trigger a suspend inhibition. If they don't, and it makes sense, it's a bug.
I use openSUSE on several servers hosted some hundred kilometers away. It wouldn't be "nice" if they auto-suspend because nobody presses any key for an hour...
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Regards,
Christian Boltz
Am Donnerstag 30 Oktober 2008 schrieb Christian Boltz:
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
Very little people use gnome in runlevel 3.
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Please check the form factor of HAL on these machines. And no, samba (sharing files with windows) and mysql (akonadi and amarok) are bad examples.
lshal | grep system.formfac
Unless it's "desktop" or "laptop", there is nothing to fear. ("unknown" here)
Greetings, Stephan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:45 +0100, Holger Macht wrote:
Sorry if this was just suggester.
Why don't create a popup on both gnome and kde to show the first time the suspend procedure starts to ask the user if he wants to keep this behaviour as default? This will avoid problems avoiding the first auto-suspend and have the advantage to let the user choose the preferred behaviour of it's system.
What do you think?
That sounds good. I'll see if we can still get this in. However, this is only an option (and a good one) for openSUSE.
Provided suspend (hibernate in my case) is stopped till the user accepts. If autosuspends triggers chances are the user is not there to stop it, and damages may happen.
- -- Cheers, Carlos E. R.
Stephan Kulow wrote:
Am Donnerstag 30 Oktober 2008 schrieb Christian Boltz:
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
Very little people use gnome in runlevel 3.
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Please check the form factor of HAL on these machines. And no, samba (sharing files with windows) and mysql (akonadi and amarok) are bad examples.
lshal | grep system.formfac
Unless it's "desktop" or "laptop", there is nothing to fear. ("unknown" here)
Greetings, Stephan
I hit a problem last night where after the system came out of auto-suspend, my wired networks wouldn't work. Everything looked fine, "ifconfig", "route -n", "rcnetwork restart", but no activity on the switch. I powered the box off completely, did physical checks after I had messed with changing eth0 and eth1 configs in case eth0 or the cable had gone bad. Powered up and everything was normal again. The penny dropped when the same thing happened when I woke the system this morning, did a complete power down, powered up and everything works. I've disabled auto-suspend now. Fixed IP addresses on eth0 and on eth1 when cable and config swapped with the eth0 config. The wireless card got an IP address via dhcp when "rcnetwork restart" done. I have other boxes on Beta 3plus that haven't been rebooted yet to see if I get the same behaviour with them. A bug report later. Regards Sid.
Sid Boyce wrote:
Stephan Kulow wrote:
Am Donnerstag 30 Oktober 2008 schrieb Christian Boltz:
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
Very little people use gnome in runlevel 3.
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Please check the form factor of HAL on these machines. And no, samba (sharing files with windows) and mysql (akonadi and amarok) are bad examples.
lshal | grep system.formfac
Unless it's "desktop" or "laptop", there is nothing to fear. ("unknown" here)
Greetings, Stephan
I hit a problem last night where after the system came out of auto-suspend, my wired networks wouldn't work. Everything looked fine, "ifconfig", "route -n", "rcnetwork restart", but no activity on the switch. I powered the box off completely, did physical checks after I had messed with changing eth0 and eth1 configs in case eth0 or the cable had gone bad. Powered up and everything was normal again. The penny dropped when the same thing happened when I woke the system this morning, did a complete power down, powered up and everything works. I've disabled auto-suspend now. Fixed IP addresses on eth0 and on eth1 when cable and config swapped with the eth0 config. The wireless card got an IP address via dhcp when "rcnetwork restart" done. I have other boxes on Beta 3plus that haven't been rebooted yet to see if I get the same behaviour with them. A bug report later. Regards Sid.
The laptop on Beta3 wakes up fully functional. On this Beta 3plus box I have to reboot to get my wired network back. I've tried all the suggestions on the list, read the man pages, tried yast powermanagement and set it to "nil", commented out all uncommented entries in /etc/suspend.conf, polkit-auth --revoke and not find a way to turn it off. Regards Sid.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2008-10-30 at 12:50 +0100, Stephan Kulow wrote:
indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Please check the form factor of HAL on these machines. And no, samba (sharing files with windows) and mysql (akonadi and amarok) are bad examples.
Why bad examples? Many peoples at home and office use samba to share files, on their desktops using kde or gnome. What will happen when the suspend or hibernate automatically?
lshal | grep system.formfac
Unless it's "desktop" or "laptop", there is nothing to fear. ("unknown" here)
nimrodel:/mnt/usb # lshal | grep system.formfac system.formfactor = 'desktop' (string)
Ok, mine is a desktop, so I must be afraid. And it automatically autohibernates, ie, suspend to DISK, because of your new default setting.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:28 +0100, Holger Macht wrote:
No, there isn't anymore. Power Management is controlled on the desktop by the user. And I think that's actually what 99% of all usual home users want.
Yes, as long as we (users) make the decision to hibernate automatically or not. It is different when you set the default to hibernate without asking us.
As you said, it's just a decision which have to be made, others would maybe say, wow, what a good default, it helps to save the environment.
Power management is nothing new, I have used it on MsDos many years back. But it is very problematic. You are taking the decision on to you (Novell), instead of asking: "do you want to...?"
You should have a setting somewhere in sysconfig, for example, where the owner (aka root) of the machine decides if the machine autohibernates or not by default.
Question for you: machine has no session opened, it is on the gdm login. There is nobody working on it. Shouldn't it hibernate? But it will not, AFAIK. Why does it have to hibernate if somebody is logged in?
Because if energy star compliance is so important, machine must conserve energy always...
For instance: my home machine serves a samba share to my external digital TV box, so that it can do time shifting and recording. With your default of hibernating, you can make it loose data!
That's advanced, you are root, you know what you do, you can change the default. And yes, it will be in the release notes.
No, I can't. Only for one user. I have to log in as each user and change it.
And even on homes, a machine can have several users, and I have no click
If one user session isn't active, aka another user is logged in, the inactive session won't trigger a autosuspend.
Even if one is gnome, the other kde? Or xfce? Or text?
and shoot method of changing that default. That's all I ask: either change the default, or provide a click and shoot method (or CLI script at least) to change that default system wide.
That would be an easy script calling 'sed', I'll provide one on the upcoming wiki page.
Thanks. Better on notes for root. Not many years ago SuSE system emailed root with such news.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:48 +0100, Holger Macht wrote:
The application does not have to be detected, it has to inform the freedesktop.org interface that it's something doing and thus the system should not be suspended. These days _every_ applications should be power management aware, because it's just something omnipresent. So yes, a bugreport agains Thunderbird, preferably upstream, would be a good idea.
No, sorry. It was your decission to implement this default, so you search for non-compliant apps. I'm wasting a lot of my valuable time as it is on this absurd default thing :/
No, it wasn't my decision, but my proposal.
English is sometimes imprecise... let me rephrase: not "thou", but "you". Ie, Novell.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:43 +0100, Holger Macht wrote:
22:23:29 I left it. 22:53:28 Machine hibernates
I hope you mean suspend (s2ram) and not hibernate (s2disk)?
Nope. The machine hibernated on its own. Which was lucky, because if it had suspended to ram the cpu would have burnt. Known bios bug.
Please report this. This are actually two bugs, the one that we should only do automatic _suspend_ and that your system is obviously in the whitelist although not working.
Done: Bug 440410
Ok, as long as you don't now dissable manual hibernation, which I use several times a day.
I don't care about suspend 2 ram not working: it is a BIOS bug, not a linux bug, and I will not flash it, nor can I even if I wanted.
In fact it does suspend to ram fine. WindowsMe did it since I bought the machine, 2 times out of 3. The other time it crashed (windows...). The problem is that the CPU remains active (mut be), but the CPU fan does not, so the CPU reaches unbeareable temps (finger burn).
So if you want to blacklist suspend on my motherboard, you must do so for only two known faulty versions of the bios, and not the correct versions (for only one make, which happens to not be mine).
In fact, I think I reported this years ago to an address that was posted for these reports.
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2008-10-29 at 14:31 +0100, Holger Macht wrote:
Plus, the user might be a KDE user, which one days switches to gnome to try it. Bingo! Lost data.
Lost data must not happen. Concrete example?
I already gave it, bugzilla opened.
External disk with opened files.
External user writing to files via samba, nfs, ftp, etc. Specially the samba case is typical on homes.
You are wrong, all applications shipped by openSUSE/ SuSE/ Novell/ buildservice should be compliant. You can not force us to only use "gnome" apps.
It should not hurt, really, every application should be able to properly recover from a system sleep. Yes, a lot works needs to be done, but it has to be done.
Right. Then you first do it, then come back in ten years and THEN set the default to hibernate >:-)
- -- Cheers, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2008-11-01 at 03:58 +0100, Gerald Pfeifer wrote:
On Sun, 26 Oct 2008, Magnus Boman wrote:
This was added due to a feature request for Energy Star;
That part is fine. What really troubles me is that we give no indication to the user, nor even admin, why this is happening.
Absolutely! I had to ask here to discover what had happened. And I'm supposedly an expert... what will happen to the thousands out there? You can guess.
I'd like to see some form of notification for the user as well, but at least we really need to log this properly, which is why I have reopened
https://bugzilla.novell.com/show_bug.cgi?id=439018#c25
to get at least this in place.
Yes.
- The event should be logged. Some machines crash on suspend/hibernate, so the log is very important afterwards. Any automatic action on a Linux machine must be logged. Logging is the traditional *nix method, etc. - Popping a message right before the act is almost useless, because he will not see it in time to stop it. Better inform much earlier. Saying that he will see it later, is bad policy: the machine may crash, and he will be very pissed with Novell.
- The admin should be informed at install time, and means should be given to him on YaST so that: a) suspend can be prohibited, b) suspend can be enforced, c) defaults can be changed. Ie, a method to define power profiles system wide, regardless of what desktop is used.
Notice that, as important as is conserving energy when a user is logged in, it is also important when nobody is logged in, probably even more important. So power profiles must be system wide, regardless of who is logged in. The user should be empowered, then, on his desktop, only to change the system profile to the extent that the admin permits.
If openSUSE is going to embrace EnergySTAR, lets do it fully!
- -- Cheers, Carlos E. R.
On Thu 30. Oct - 11:53:09, Christian Boltz wrote:
Hello,
on Mittwoch, 29. Oktober 2008, Holger Macht wrote: ...
Of course it should be mentioned in the release notes. So if, hypothetically, the decision is to keep this setting, I will care about having a corresponding section in the release notes.
I have already opened a request to add a section to the release notes: https://bugzilla.novell.com/show_bug.cgi?id=439980 No need to open a new one, just add your text there ;-)
Actually it's a question about for whom is openSUSE designed for. If you have the "common desktop user" as a target group, you could assume that he just uses the default desktop applications. And all those could trigger a suspend inhibition. If they don't, and it makes sense, it's a bug.
I use openSUSE on several servers hosted some hundred kilometers away. It wouldn't be "nice" if they auto-suspend because nobody presses any key for an hour...
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
It doesn't autosuspend there, gnome-power-manager/kpowersave are responsible for autosuspend and they're not running in this case.
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Regards, Holger
On Thu 30. Oct - 12:59:01, Sid Boyce wrote:
Stephan Kulow wrote:
Am Donnerstag 30 Oktober 2008 schrieb Christian Boltz:
Hmm, can auto-suspend be disabled if the (default) runlevel is 3? IMHO using runlevel 3 is a very good indication that a machine is used as server ;-)
Very little people use gnome in runlevel 3.
Having things like apache, mysql or samba daemons running is also a good indication for a server - maybe the initscripts of these daemons could also disable auto-suspend.
Please check the form factor of HAL on these machines. And no, samba (sharing files with windows) and mysql (akonadi and amarok) are bad examples.
lshal | grep system.formfac
Unless it's "desktop" or "laptop", there is nothing to fear. ("unknown" here)
Greetings, Stephan
I hit a problem last night where after the system came out of auto-suspend, my wired networks wouldn't work. Everything looked fine, "ifconfig", "route -n", "rcnetwork restart", but no activity on the switch. I powered the box off completely, did physical checks after I had messed with changing eth0 and eth1 configs in case eth0 or the cable had gone bad. Powered up and everything was normal again. The penny dropped when the same thing happened when I woke the system this morning, did a complete power down, powered up and everything works. I've disabled auto-suspend now. Fixed IP addresses on eth0 and on eth1 when cable and config swapped with the eth0 config. The wireless card got an IP address via dhcp when "rcnetwork restart" done. I have other boxes on Beta 3plus that haven't been rebooted yet to see if I get the same behaviour with them. A bug report later. Regards Sid.
But this definitely smells like a driver problem, aka a bug that has to be fixed.
Regards, Holger
On Sun, 26 Oct 2008, Magnus Boman wrote:
This was added due to a feature request for Energy Star;
That part is fine. What really troubles me is that we give no indication to the user, nor even admin, why this is happening.
I'd like to see some form of notification for the user as well, but at least we really need to log this properly, which is why I have reopened
https://bugzilla.novell.com/show_bug.cgi?id=439018#c25
to get at least this in place.
Gerald
-
Bernhard Walle -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Cristian RodrÃguez -
Felix Miata -
Gerald Pfeifer -
Holger Macht -
Jarno van Roosmalen -
Kevin Yeaux -
Ludwig Nussel -
Magnus Boman -
nordi -
opensourcecat -
Richard (MQ) -
Sid Boyce -
Stefan Behlert -
Stephan Kulow -
Vincent Untz