Does SailfishOS suspend a running app after some time? [answered]

Question

3

Does SailfishOS suspend a running app after some time? [answered]

app-management

asked 2019-05-02 19:02:10 +0300

neo75

497 ●15 ●19 ●23

updated 2019-05-11 11:54:30 +0300

Hello, I have question regarding the use of Sailfish native app called Quakefish. I use this app for some informative long acceleration measurements, like tens of minutes or an hour. ¨ Does the Sailfish suspend the app after some time? Or Sailfish will let the app run for infinite amount of time, even under screensaver? I am asking because the behaviour of the app is like that after some time it is stopped, but when I unlock the screensaver, it continues the measurement. Is there any setting in the system? Thank you very much.

UPDATE 11.5.2019Thank you all for sharing deep knowledge and comments! Let me be more specific. I have tried to use native Quakefish app from Jolla store, but also the version of Quakefish from Openrepos. https://openrepos.net/content/boggins/quakefish Both worked the same. The app works quite simple: just reads from acceleration sensor the X,Y, Z components and writes them to simple CSV ascii file. Each line of file has just 3 numbers. The sampling rate I use is 50 Hz, so it generates 50 lines of numbers each second. After the measurement I load the CSV file into e.g. GNU Octave and do the signal processing, like FFT analysis and more. It is a bit of fun. For short measurements, like minutes, it works perfectly.

My problem is, that the app is not measuring all the time for longer periods and it seems, that the SailfishOS somehow suspends it. Imagine, that I run the measuring for 1 hour, putting the phone to a place, where I cannot access it during measurement. After 1 hour there should be 50 lines x 60 x 60 = 180.000 lines in the CSV file (at 50 Hz sampling rate). But it is not, only e.g. 40.000 lines are there written, so it is clear, that the app was not running whole time. When I took the phone after this hour, unlock the screensaver, the app just shows, that is running normaly...

Sorry for such a long post. Thank you for any help.

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by pawel
close date 2019-05-12 09:08:25.344371

Comments

1

Search for oom killer, e.g. this question and you'll find more info

rgrnetalk ( 2019-05-02 19:09:02 +0300 )edit

1

If the measurement continues after unlocking, without restarting the app by touching the cover, it's not the oom killer. That would stop the app completely, right?

I do remember reading about some internal clock slowing down when the phone is locked and is saving energy.

You should probably ask the author of the app about this issue.

hetas ( 2019-05-02 21:59:07 +0300 )edit

Search for oom killer, e.g. this question and you'll find more info
rgrnetalk ( 2019-05-02 19:09:02 +0300 )edit
If the measurement continues after unlocking, without restarting the app by touching the cover, it's not the oom killer. That would stop the app completely, right?
I do remember reading about some internal clock slowing down when the phone is locked and is saving energy.
You should probably ask the author of the app about this issue.
hetas ( 2019-05-02 21:59:07 +0300 )edit

Answer 1

13

answered 2019-05-03 11:22:25 +0300

spiiroin
13237 ●151 ●224 ●199

moderator

updated 2019-05-13 08:15:45 +0300

Some details below, but short answer to the question: Individual applications are not stopped by sfos, but unless some care is taken the whole device gets suspended when not in active use.

SFOS power management operates roughly in the following states:

Display on (normal operation)
Display off (most sensors stopped, depending on device some cpu cores stopped and/or running in lower clock frequency, ...)
Suspended to RAM (all cpu cores stopped, only select peripherals - such as power key, wlan, cellular - can wake up the system)

The policy governing transitions between these states is basically: Use the state with smallest power consumption allowed by current situation, i.e.

Power off display when there is no clear reason to keep it powered on (user activity, applications using blank prevention interfaces, ...)
Suspend to RAM when display is off and there is no clear reason to keep CPUs online (system level activity, applications using suspend blocking interfaces, ...)

Which then means applications need to signal their need to keep display on, cpus online, or waking up even if the device should be suspended.

There are (a bit low level) interfaces for this purpose

Keep display on even though there is no user activity -> blank prevention D-Bus API in mce -> around https://git.merproject.org/mer-core/mce-dev/blob/master/include/mce/dbus-names.h#L350
Finish some time consuming processing despite display getting blanked -> cpu keepalive D-Bus API in mce -> around https://git.merproject.org/mer-core/mce-dev/blob/master/include/mce/dbus-names.h#L604
Wake up periodically / after some specific delay -> libiphb (handled by dsme & mce) -> https://git.merproject.org/mer-core/libiphb/blob/master/src/libiphb.h

The intent is that application developers would not use these directly, but rather the convenience qml/qt/glib wrappers provided in nemo-keepalive library. The library contains some example apps e.g. for qml bindings at https://git.merproject.org/mer-core/nemo-keepalive/tree/master/examples/qml

Unfortunately the situation has been and still is that we have not been able to stabilize the nemo-keepalive interfaces and thus they are not "harbour approved" yet (though now there starts to be some light at the end of the tunnel).

EDIT 2019-05-13:

Regarding that quakefish case (a sailfish application that wants to receive and process sensor data while display is off). In theory it goes like this:

You need to stop device from suspending (some sensors are simply powered off when device suspends regardless of other circumstances) -> nemo-keepalive
You need to tell sensorfwd to keep sensor active despite display being off -> application needs to set "standby override" flag for the sensor in question -> which probably maps to "alwaysOn" property in qt sensors

The "in theory" part comes from the fact that sensorfwd does not support standby-override for all sensor types. And even for those sensors that do support it, there might still be some hiccups in/dealing with underlying android sensor interfaces/services.

edit flag offensive delete publish link

Comments

1

Thanks for a comprehensive answer to nearly all my questions I ever have had on this topic!

lakutalo ( 2019-05-03 11:55:19 +0300 )edit

Thank you for sharing all that information with the community.

Direc ( 2019-05-12 11:46:52 +0300 )edit

Accepted Answer

4

answered 2019-05-02 20:16:10 +0300

DrYak

9624 ●93 ●134 ●128

http://www.sympato.ch/

To be more precise:

Sailfish doesn't suspend an app after some time but after some memory limit. i.e.: Sailfish will shutdown apps to conserve memory usage if it runs low on memory. This happens more often on older device with less available memory.

Look around for "oom killer" as suggested by Rgrnetalk in a comment.

A way to counter act is to get a good quality SD card that can sustain a lot of abuse (prefere "industrial" cards, or cards with dynamic and static wearl-leveling and ECC like Transcend, etc.) and create a swap partition on it (command line: mkswap /dev/mmcblk1p+partition) and use it (either command line swapon+ device or edit /etc/fstab for a more permanent solution, but use the nofailoptions so your smartphone can still boot without the card). When you system runs low on memory, instead of killing apps, it will simply swap out to the card to free memory. But beware that some cheaper cards might die prematurely due to the increased writing, so do no cheap out buy good quality (Raspbery Pi forums are a possible source to look around, where people have tested and abused tons of different cards models. Looking for cards sold specifically for use in constantly writing situation like dashcams is another solution).

Also, specifically for apps on the official Jolla store: Jolla doesn't allow apps that run in the background in daemon mode. Depending on how your app is designed, this restriction might be a problem. See if there is an equivalent app on a 3rd party repository that doesn't enforce such limitations like openrepos

edit flag offensive delete publish link

Answer 3

4

answered 2019-05-02 22:34:58 +0300

olf
10393 ●104 ●201 ●158

updated 2019-05-02 22:44:18 +0300

IMO the "OOM killer" is not the reason for the behaviour described by @neo75, but device sleep is:
All apps (native and Android) appear to be "frozen" while the device is in sleep mode. They simply continue to run when the device is woken up (i.e., they are not killed due to an OOM situation and hence also not restarted).
The timer for entering sleep mode can be set in Settings -> Display -> Sleep after (it seems to count the time after screen blanking) and the periods of the device being in sleep mode can be observed per SysMon, when CPU sleep is at 100% (technically this is not exactly the same, but "device sleep mode" and "100% CPU sleep" do correlate very well).

P.S.: So "yes" @neo75, the apps appear to be "suspended" when the device is in sleep mode, but are technically neither suspended or stopped, and apps do "run for infinite amount of time", but cannot do anything while the device is in sleep mode (if an app or the user does not actively wake up the device).

edit flag offensive delete publish link

Comments

Thanks a lot! In Settings/Display/Sleep after is maximum value 10 minutes. Is there any chance to change this value higher?

neo75 ( 2019-05-11 16:37:20 +0300 )edit

@neo75 You can tweak the relevant setting from command line with mcetool e.g. select half hour delay before dimming (and shortly after that blanking) screen:

mcetool --set-dim-timeout=1800

But whether that is the thing that you'd want to do depends on what you are trying to accomplish (i.e. keeping display on just to disable cpu suspending = there are better ways to accomplish that, whereas keeping display on to stop sensorfwd from powering off sensors might even make sense in some context).

spiiroin ( 2019-05-13 07:48:07 +0300 )edit

Good. Thank you very much. Just please, how do I install "mcetool"? It gave me "command not found" in shell. I am in developer mode under devel-su logged in. I found also "GUI For Mcetool" in Storeman, but that requires mcetool itself. Thanks.

neo75 ( 2019-05-13 19:57:25 +0300 )edit

I found it now and installed sucessfully:

devel-su
pkcon refresh
pkcon install mce-tools

I will test it based on your advice. Thanks a lot for help!

neo75 ( 2019-05-13 20:42:15 +0300 )edit

Does SailfishOS suspend a running app after some time? [answered]

The question has been closed for the following reason "the question is answered, an answer was accepted" by pawel
close date 2019-05-12 09:08:25.344371

Comments

3 Answers

Comments

Comments

Question tools

Stats

Related questions

Does SailfishOS suspend a running app after some time? [answered]

The question has been closed for the following reason "the question is answered, an answer was accepted" by pawel close date 2019-05-12 09:08:25.344371

Comments

3 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "the question is answered, an answer was accepted" by pawel
close date 2019-05-12 09:08:25.344371