[opensuse] Tell system to use pm-utils
Hello, only pm-utils can run scripts after resuming. This is why I want the system (openSUSE 12.3) to use pm-utils. How can I do this? I suspend from the KDE menu. How can I make KDE use pm-utils? Malte
On 08/28/2013 12:37 AM, Malte Gell wrote:
Hello,
only pm-utils can run scripts after resuming.
That is not true, systemd executes shell scripts from /usr/lib/systemd/system-sleep This is why I want the
system (openSUSE 12.3) to use pm-utils.
How can I do this?
It currently does just that.. it calls pm-utils at suspend/resume but not for long, it will go away soon. Better tell us what you are trying to accomplish, because I am pretty sure you shouldn't be using anything like the above tools .. 99.99999% of the time is the wrong thing to do. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 28.08.2013 08:03, schrieb Cristian Rodríguez:
Better tell us what you are trying to accomplish, because I am pretty sure you shouldn't be using anything like the above tools .. 99.99999% of the time is the wrong thing to do.
I want to run a script in /usr/lib/pm-utils/sleep.d/ but the script does not get executed... Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-28 a las 09:03 +0200, Malte Gell escribió:
Am 28.08.2013 08:03, schrieb Cristian Rodríguez:
Better tell us what you are trying to accomplish, because I am pretty sure you shouldn't be using anything like the above tools .. 99.99999% of the time is the wrong thing to do.
I want to run a script in /usr/lib/pm-utils/sleep.d/ but the script does not get executed...
The correct place is "/etc/pm/sleep.d/". - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlId3ckACgkQja8UbcUWM1yhLQD+IooSob0Ys3puIZzRwHQTZ5jN zQr913RfIli2c9VgRAgA+gIkUliXnRrH8lpl8Okl0uWKFog2fTo9DjUxfOjx+nM9 =9eCL -----END PGP SIGNATURE-----
Am 28.08.2013 13:23, schrieb Carlos E. R.:
El 2013-08-28 a las 09:03 +0200, Malte Gell escribió:
Am 28.08.2013 08:03, schrieb Cristian Rodríguez:
Better tell us what you are trying to accomplish, because I am pretty sure you shouldn't be using anything like the above tools .. 99.99999% of the time is the wrong thing to do.
I want to run a script in /usr/lib/pm-utils/sleep.d/ but the script does not get executed...
The correct place is "/etc/pm/sleep.d/".
I now copied the script to /etc/pm/sleep.d but it still does not get executed... The script itself is okay. Malte
Am 28.08.2013 13:23, schrieb Carlos E. R.:
The correct place is "/etc/pm/sleep.d/".
Everything works now, errors identified. I just wonder, if /usr/lib/pm-utils/sleep.d is the wrong place, why does openSUSE install scripts there at all? Why doesn´t openSUSE copy these scripts to /etc/pm/sleep.d in the first place? thanx Malte
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-28 a las 16:43 +0200, Malte Gell escribió:
Am 28.08.2013 13:23, schrieb Carlos E. R.:
The correct place is "/etc/pm/sleep.d/".
Everything works now, errors identified.
I just wonder, if /usr/lib/pm-utils/sleep.d is the wrong place, why does openSUSE install scripts there at all? Why doesn´t openSUSE copy these scripts to /etc/pm/sleep.d in the first place?
Two theories. There may be a system directory and a user directory. Or there may be an storage place for scripts that do not run by default, until you copy or link them somewhere else. Now that you identified the errors, you could put back your script in the old place and find out if it runs. If it doesn't, it may also be that your script does not have the exact syntax it should have. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlIePNoACgkQja8UbcUWM1ykAQD+N/0VPfLOG4dhSAhfA3W+kmpl e/+qR8aP8D+T90cjhzwA/3Jb533tOU5mZXGyRYzw2WvtsRCiZWSI/9pFp0+u5dyk =j1iV -----END PGP SIGNATURE-----
El 28/08/13 10:43, Malte Gell escribió:
Am 28.08.2013 13:23, schrieb Carlos E. R.:
The correct place is "/etc/pm/sleep.d/".
Everything works now, errors identified.
Ok. Anyway.. just curious, what you are trying to do _exactly_ ? I ask because most of the time people use these scripts to workaround actual bugs that need to be fixed at their source. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 28.08.2013 21:19, schrieb Cristian Rodríguez:
El 28/08/13 10:43, Malte Gell escribió:
Am 28.08.2013 13:23, schrieb Carlos E. R.:
The correct place is "/etc/pm/sleep.d/".
Everything works now, errors identified.
Ok.
Anyway.. just curious, what you are trying to do _exactly_ ?
I have a Sundtek DVB-C USB stick and after resuming the driver has to be started again. The Sundtek driver package copies the resume script to /usr/lib/pm-utils/sleep.d/10mediasrv I moved it now to /etc/pm/sleep.d/ Ok, the script still does not work properly, but this is a Sundtek driver issue now :-) The syntax is ok. If you want to know the content of the script, I paste it below. Malte #!/bin/sh # Sundtek Media Framework case "$1" in hibernate|suspend) echo `date +"%Y-%m-%d %H:%M:%S [$$]"`" Stopping driver system is going into suspend/standby" >> /var/log/mediasrv.log /opt/bin/mediaclient --shutdown ;; thaw|resume) echo `date +"%Y-%m-%d %H:%M:%S [$$]"`" Restarting driver after system resume" >> /var/log/mediasrv.log #/opt/bin/mediaclient --shutdown /opt/bin/mediaclient --start ;; *) exit $NA ;; esac
El 29/08/13 08:28, Malte Gell escribió:
Am 28.08.2013 21:19, schrieb Cristian Rodríguez:
El 28/08/13 10:43, Malte Gell escribió:
Am 28.08.2013 13:23, schrieb Carlos E. R.:
The correct place is "/etc/pm/sleep.d/".
Everything works now, errors identified.
Ok.
Anyway.. just curious, what you are trying to do _exactly_ ?
I have a Sundtek DVB-C USB stick
Ok, the script still does not work properly, but this is a Sundtek driver issue now :-)
Ah yeah, this is a known issue, it is not specific to the sundtek driver but a general issue in the particular kernel subsystem. There is more than one report about these devices failing to come up after suspend/resume. No idea if any progress has been made, only know that developers are aware about it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 29.08.2013 19:32, schrieb Cristian Rodríguez:
Ah yeah, this is a known issue, it is not specific to the sundtek driver but a general issue in the particular kernel subsystem.
Well, that device is said to work with Ubuntu after resuming... Distribution specific patches seem to have some impact here. Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Carlos E. R. -
Cristian Rodríguez -
Malte Gell