|
Home > Archive > Debian Developers > March 2004 > Bug in apmd debian scripts
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug in apmd debian scripts
|
|
| Chris Hanson 2004-03-25, 9:46 am |
| Date: Thu, 25 Mar 2004 11:52:29 +0100
From: Clemens Wacha <clemens.wacha@gmx.net>
Hello,
in /etc/apm/apmd_proxy script it says
if [ we are going to suspend ]; then
run-parts /etc/apm/suspend.d
fi
in suspend.d you have symlinks to /etc/apm/scripts.d
this does not work because run-parts only executes script but does
NOT follow links to scripts
That was bug #238816, which is fixed in the latest version.
And btw it's highly confusing that we have more than one possibility
to run scripts on suspend/resume events
1. from /etc/apm/event.d
2. from /etc/apm/resume.d
3. from /etc/apm/suspend.d
4. from /etc/apm/other.d
... etc
I'd vote for seperate dirs like
suspend.d (all suspend requests)
standby.d (all standby requests)
resume.d (all resume requests)
battery.d (change battery request ( the request that tells us when
battery is low)
and other.d (for other change requests)
and completely remove script.d because it doesnt work anyway and
remove events.d because it makes thing more difficult than needed
and its function is less obvious than the folder approach.
There are good reasons why this confusing system is used.
First, the "events.d" directory exists for backwards compatibility.
Until about two years ago, it was the only way to define APM scripts.
Second, the newer directories were created in order to give the user
more control over the ordering of scripts. It's often the case that
suspend/standby events want the opposite sequencing from resume
events. The separate directories aren't intended to be a way to
distinguish different kinds of requests, which should be done by
examining the script's arguments.
Third, the use of the "scripts.d" directory and symlinks allows all of
the actions for a particular subsystem to be in a single file,
separate from the time sequencing of each subsystem's actions.
This is not an ideal system, but it does provide enough flexibility
for most purposes. If it's confusing, that is probably a shortcoming
of the documentation.
Thomas Hood has been working on an alternative system, in which the
event sequencing is controlled by statements inside the scripts. This
promises to simplify things in the long run.
Chris
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Oliver Kurth 2004-03-25, 10:34 am |
| On Thu, 2004-03-25 at 15:16, Chris Hanson wrote:
> Thomas Hood has been working on an alternative system, in which the
> event sequencing is controlled by statements inside the scripts. This
> promises to simplify things in the long run.
Why? I find ordering by name much more intuitive and easier to check. I
do not like having to look into each script to find out when they are
run.
Greetings,
Oliver
| |
| Thomas Hood 2004-03-25, 2:34 pm |
| Oliver Kurth wrote:
> On Thu, 2004-03-25 at 15:16, Chris Hanson wrote:
>
> Why?
The alternative system to which Chris referred uses priority
declarations instead of sequence numbers to determine execution
order. The declarations can either be in the scripts themselves
or in external files or both. Scripts that are not prioritized
relative to one another are run simultaneously.
It is possible to design the system so that the priorities depend
on how the script is executed -- i.e., with which arguments.
E.g., it is possible to make A follow B on suspend but precede it
on resume. Such a system eliminates the need for the symlink
farms that one finds in the current apmd package.
--
Thomas Hood <jdthood@yahoo.co.uk>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Oliver Kurth 2004-03-25, 3:34 pm |
| On Thu, 2004-03-25 at 19:59, Thomas Hood wrote:
> Oliver Kurth wrote:
>
> The alternative system to which Chris referred uses priority
> declarations instead of sequence numbers to determine execution
> order. The declarations can either be in the scripts themselves
> or in external files or both. Scripts that are not prioritized
> relative to one another are run simultaneously.
>
> It is possible to design the system so that the priorities depend
> on how the script is executed -- i.e., with which arguments.
> E.g., it is possible to make A follow B on suspend but precede it
> on resume. Such a system eliminates the need for the symlink
> farms that one finds in the current apmd package.
Hm. To run them simultanuously, one could give them the same order
number, eg. 40-foo would be run at the same time as 40-bar (of course,
run-parts would have to changed for that). And I am not convinced that
it is really worth it. For another order, one could execute them in
reverse order (--reverse for run-parts), or use the sym link farm, which
is okay for me. I do not adhore sym links, at least not if they follow
an easy to understand scheme, which is the case here. This works for the
init.d scripts, why not in other script.d directories?
As I wrote in my original mail, I do not want to look into every single
file to see in which order they are executed. And if the information is
in an external file, this can be just another script, no need for
run-parts then. And it would be even more flexible...
I do not want to stop your creativity, but I do not like
overcomplicating simple things.
Greetings,
Oliver
|
|
|
|
|