Ticket #2008 (closed enhancement: fixed)

Opened 11 years ago

Last modified 11 years ago

Suspend exceptions: Do not suspend when certain apps are running

Reported by: Benih Owned by: openmoko-kernel
Priority: normal Milestone:
Component: kernel Version: Om2008.8
Severity: minor Keywords: suspend exception
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

I think it would be useful if the phone would not go into suspend if some (user definable) applications are running.

This could be achieved by the suspender looking into some /etc/suspend.deny file in which process names (or even better regular expressions) are listed. If the suspend-timer (that one that is already configurable via the "settings" application) then reaches zero, instead of just going to suspend, it would instead look into /etc/suspend.deny and see if one of the regular expressions match the current process table. If so, it does nothing and waits for some period (5 seconds? or the suspend timeout the user defined already in his configuration) to do the check again.
If then no match occurs, it goes to suspend, this would be the case if the process stops to run.
If the user interacts with the phone, the timer will start over again anyway.

This will be useful in certain situations like GPS-tracking with tangoGPS since the user does not need to disable suspend for that cases. It will go automatically.
The easy sytax of /etc/suspend.deny will enable the average user to adjust his needs easily. For users not used to the command line, easy editors could be written. Since it is an easy file format, the file could even be modified by install scripts (opkg of tangogps for example) that want to add such an suspend exception.

Please also note ticket #1793, which wants to add a suspend exception if the device is powered by USB. Maybe that enhancement could be implemented with /etc/suspend.deny as well.

Change History

comment:1 Changed 11 years ago by andy

This has been discussed a bit before, something that came up then was detection by what device nodes have file handles open on them. So instead of having a whitelist of GPS apps as you suggest, you effectively grep lsof looking for ttySAC1 or whatever.

One can also look down proc and find out what ALSA is doing, although pulseaudio probably messes that up.

For USB power detection you can look down /sys and find it out, so it will fit your scheme OK.

comment:2 follow-up: ↓ 4 Changed 11 years ago by Benih

That are good pints.
But it would be cool if that will be configurable via some central file so everything is in the users hands and doesn't need to be implemented in software. Instead the software should only follow some configuration.

So, what if /etc/suspend.deny provides some rule-scheme that allows the user to specifiy the things you mentioned:


# rule    parameter
proc	/tangogps/i     # dont suspend if this regex matches the process table
lsof	/ttySAC1/       # dont suspend if this regex matches the "lsof" output
cat/x	/foo/	        # dont suspend if "cat /f" matches the regex

This way, other "rules" could easily be added as neccessary. New rules could easily be implemented. And packages could easily add lines that adjust suspension mode, as well as the user is able to add his needs.
The more generic rules are available, the better the user can tune his phone. Just think of special apps he compiled himself!

comment:3 Changed 11 years ago by Benih

Another interesting rule would be to test if some file is in place:
{{
# rule parameter
fexists /home/root/foobar # dont suspend if /home/root/foobar file exists
}}

comment:4 in reply to: ↑ 2 Changed 11 years ago by thagen

I must say that I would agree with Benih. To have some magic with lsof is really not the way to go. This will be way too hidden for the users and it will be very hard to debug. A generic file is a lot more future proof.

Tore

comment:5 Changed 11 years ago by beni

An even better solution would be to just implement some "plugin" interface to the suspender.
The suspender may only call a "suspend.deny" executable with predefined return codes.
If that executable returns "0", then suspend can occur. If it returns something else than "0", then suspend should be aborted.
"suspend.deny" executable could then be set via the update-alteratives procedure.
This way, users have all possibilitys to implement their own suspending-denial scripts. The user could easily install the one he likes (via opkg) while developers can happily implement their own suspend.deny stuff. Users may even decide to not install some suspend.deny implementation at all. Openmoko devs only need to implement that call to suspend.deny, the community could provide the rest.

I already have some simple suspend.deny with the above mentioned features in mind, that could serve as some proof-of concept and may even be the default suspend.deny program.

comment:6 Changed 11 years ago by beni

I think, several rule files would be better than one, so packages can install rules that depend on ordering (imagine some package that asks the user or something).

In addition to the above mentioned ideas, the best solution would be:
The suspender looks in /usr/bin (or something like that, maybe /sbin is better?) for an executable (binary, script etc) called "suspend.deny". If he finds it, he calls it. If the return code is 0, then suspend, otherwise abort suspend.

The default suspend solution should feature simple rule files.
The rules will be stored below /etc/suspend.deny.d/. The rules files will be processed in alphabetical order, files will be named like "10somerule", "99alastrule". Rule files that do not depend on some partivular order should always start with "50", so overriding below and above is no problem.
If one rule line of any rule file denies suspend, the following rules must not be evaluated. Instead, the suspend.deny implementation returns some code other than "0" immediately.

The rules files should have a very simple syntax:
[rule] [parameter1] [parameter2] ... [parameterN]

The so far needed rules supported in the default implementation would be:

  • Executing of an external script (gives maximum flexibility to the user to implement stuff not yet available via rule)
  • testing process table by regex
  • testing "lsof" by regex
  • testing for file content by regex
  • testing for file existance

comment:7 Changed 11 years ago by andy

It sounds rather like pm-utils /etc/pm/sleep.d ... if the scripts in there return nonzero it aborts suspend I believe.

comment:8 Changed 11 years ago by beni

I have read a bit through http://pm-utils.freedesktop.org/wiki/ and especially the source at http://cgit.freedesktop.org/pm-utils/tree/
That sounds very good to me.

This would mean, that the individual packages (such as tangogps) would add pm-utils/sleep.d scripts. The advanced user could place his own scripts there easily.

What are openmokos plans for suspend stuff? Will they use pm-utils (if installed)?
If so, i will happily write some piece of code, that allows the user to use the discussed /etc/suspend.deny file, which will of course be standalone (integrated into pm-utils) then. I think i could also provide scripts for common apps like tangogps.

Unfortunately i could not find any pm-utils package for openmoko to start testing. Is there some preinstalled one?

comment:9 Changed 11 years ago by andy

I don't have anything to do with our userspace I'm afraid. But, I would bet that Debian has it as something you can readily install. Whether it is "plumbed in" right I don't know, but I would bet you will get where you want to be a lot quicker by trying pm-utils and looking at what's broken there if anything.

comment:10 Changed 11 years ago by raster

this has been going on for a long while. everything you n4eed is already there. ompower is a userspace daemon you talk to via dbus to request power states of a device (right now only cpu supported and implicitly screen backlight is managed as a result). its a very small program too so can be extended very easily.

to request suspend:

dbus-send --system --dest=org.openmoko.Power / \
org.openmoko.Power.Core.RequestResourceState? \
string:cpu string:my-system-name string:off

to tell ompower that "i want to keep suspend from happening because i need the cpu":

dbus-send --system --dest=org.openmoko.Power / \
org.openmoko.Power.Core.RequestResourceState? \
string:cpu string:my-system-name string:on

when you are done with your desire to keep the cpu up or you dont think it should be suspended anymore:

dbus-send --system --dest=org.openmoko.Power / \
org.openmoko.Power.Core.RemoveRequestedResourceState? \
string:cpu string:my-system-name

so in the case of "i dont want to suspend while it is connected via usb"

on usb connect:

dbus-send --system --dest=org.openmoko.Power / \
org.openmoko.Power.Core.RequestResourceState? \
string:cpu string:usb-connection string:on

on usb disconnect:

dbus-send --system --dest=org.openmoko.Power / \
org.openmoko.Power.Core.RemoveRequestedResourceState? \
string:cpu string:usb-connection

you can do this of course from anything that can talk dbus - not just the cmd-line. remember the "my-system-name" is an identifier for who is asking (i did it this way so it could be used from the cmd-line via dbus-send). it says "me - the usb connection" or "me the dialler" or "me the gps nav program" is asking for the cpu to stay on, or suspend. as long as at least 1 person is asking for the cpu to be on - it stays on. when everyone who asked for it to be on removes their "keep it on for me" requests, then ompower will allow it to suspend *IF there is any off request in the queue. at that point ompower executes "apm -s".

comment:11 Changed 11 years ago by beni

Very interesting!

I wrote a page on the wiki (http://wiki.openmoko.org/wiki/Ompower), that summarizes ompower so developers know how to adjust the suspend process, since i could not find any information about it on the wiki or on google so far.

However, to implement the discussed /etc/suspend.deny.d/ scripts, ompower needs to be modified. It needs additional research if this is all necessary, since the way to go would be that the programs (eg. tangogps) talk dbus directly.

Implementing suspend avoidance is therefore the responsibility of the application developers. We should open tickets for the afected applications pointing the devs to the wiki article.

comment:12 Changed 11 years ago by raster

bingo! it's not the job of some susped.deny thing or other such hacks that guess based on open files or on process names etc. that is entirely an ugly hack that is bound to break down in so many places. if an app truly wants the system not to suspend while it's up - the app should ask. there is a dbus api just for that. :) if an app wants the system to sleep (e.g. some idle timeout) again - dbus api to ask just for that. the rest is just complicating what is a very simple system already in place. :) there really is zero need for suspend.deny if you knwo what is already in place (as ompower implements a suspend.deny via dbus requests as such).

comment:13 Changed 11 years ago by beni

So this all is about a documentation issue which is already fixed by the wiki article.
It should be evaluated if this article needs to be linked from some dev-howto.

Thanks to raster for all his clarifying!
I think the ticket may be closed now.

comment:14 Changed 11 years ago by raster

  • Status changed from new to closed
  • Resolution set to fixed

fixed - wiki page done.

Note: See TracTickets for help on using tickets.