Proposal for resolving powernowd/apmd vs. (k)powersave conflict

Michael Biebl biebl at
Fri Mar 10 01:01:59 GMT 2006

Luka Renko wrote:
> Hello,


I promised last weekend that I would provide (k)powersave packages for
testing. Unfortunately I was sick the last few days and was unable to do
any work. Today I finally managed to prepare packages which I would like
you to test. More on that later.

> I am still looking how to make usable powersaved/kpowersave packages that
> would not clash with kubuntu-desktop (and hopefully also ubuntu-desktop and
> edubuntu-desktop). As you may know, the main problem is that powernowd and
> apmd packages are not compatible with powersaved (as they do the same stuff
> and there are known issues if both run at the same time). Debian powersaved
> package has a rule to remove apmd and powernowd, which then also removes
> *-desktop packages. :-(
> I would suggest the following workaround for this "catch22" problem:
> 1. Get rid of "Conflicts: powernowd apmd" rule
> This will allow powersaved/kpowersave to be installed on Kubuntu (including
> the case where ubuntu/edubuntu-desktop is there). As this can lead to known
> issues, we will also...
> 2. Change "/etc/init.d/powersaved start" to stop powernowd/apmd before
> starting powersaved
> Start should just call "stop" methods of powernowd/apmd rc scripts. Good
> thing is that powersaved is started after powernowd and ampd:
> /etc/rc3.d/S20apmd
> /etc/rc3.d/S20powernowd
> /etc/rc3.d/S25powersaved

This approach has many problems and I would advise strongly against it.

1.) It's a waste of resources. Having installed different cpufrequency
daemons while only one can be run at a time makes no sense (That's why I
added the Conflicts).
2.) Slowes down boot process. You have to start apmd and powernowd
first, and kill it later. And we all want a fast boot ;-)
3.) It's not transparent for the user: If a user sees powernowd start
during boot and later sees no powernowd process running he might think
that the process has crashed or something alike.
4.) Problems on package upgrades of powernowd/apmd. Imagine a package
upgrade of powernowd/apmd where the init script is called in the
postinst maintainer script. You would again have conflicting processes
running at the same time.

Given all this reasons, this approach seems not viable too me. Besides
this hack is not needed at all ;-)
If kubuntu decides to go with (k)powersave, kubuntu-desktop would simply
depend on kpowersave/powersaved instead of apmd/powernowd/klaptopdaemon.
Problem solved.
For now, to give you a chance to easily test my packages I added a
Conflicts/Replaces/Provides: powernowd, apmd to powersaved and a
Conflicts/Replaces/Provides: klaptopdaemon to kpowersave.
This way kubuntu-desktop is not unistalled if you "apt-get install

The more important problem is, how we handle the event processing done
by acpid. Right now, acpi-support installs a bunch of scripts in
/etc/acpi/. When an acpi event happens (e.g. a power button pressed
event), acpid calls the script defined in /etc/acpi/events/powerbtn
(/etc/acpi/ This is obviously not what we want, because
powersaved should be responsible for all event processing and apply the
correct rules and policies. acpid's sole purpose is to provide a socket
where several processes (powersaved, hald, Xorg) can listen on acpid events.

So we have three possibilities here (in decreasing order of my preference):
1.) Install a diversion of /usr/sbin/acpid. Create a wrapper script for
acpid and filter the arguments passed to acpid. When acpid is called
with -c /etc/acpi/events replace it with -c /etc/acpi/event.ignore (an
empty directory installed by powersaved). This effectively and
efficiently disables the event processing of acpid. This is the approach
I have taken right now. Take a look at /usr/sbin/acpid after installing
I first tried to divert the /etc/init.d/acpid init script but this
failed because dpkg's config file handling comes into play at that moment.
2.) Add a
if pidof powersaved; then
    exit 0
stanza at the beginning of each script in /etc/acpi. This means we would
have to prepare new releases for acpid and acpi-support. In addition it
would be less efficient, because acpid would starts a shell for each
event to process and simply quits directly afterwards.
3.) Provide a modified version of the acpid package for kubuntu (IIRC
this is not possible) which includes a modified init script.

I strongly prefer the first option.
I prepared packages and uploaded it to my private repo.
Add the following to /etc/apt/sources.list

deb dapper main
deb-src dapper main

My repository is signed with my GPG key. You can find instructions how
to use it at [1].
Please test these packages and report any problems.

@Jonathan: Is there a realistic chance that these packages make it into
Dapper or is too late for the feature freeze?
@Achim,Luka: Please start the procedure to get these packages into the
Dapper archive. I'm not familiar with the (K)ubuntu procedures so I
wanted to pass this task on to you or at least give me assistance. IIRC
Jonathan talked about a laptop testing group in ubuntu where we should
send these packages too, how would we do that.

Let's get as much testing quickly as possible and then Jonathan can
decide if (k)powersave should be used as the default power management
solution for Kubuntu 6.04


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url :

More information about the kubuntu-devel mailing list