[4.1.0.23] Random closing of all apps

Bug Reports
,
#1

REPRODUCIBILITY (% or how often): Sometimes, once or twice a day
BUILD ID = OS VERSION (Settings > About product): 4.1.0.23 EA
HARDWARE (XA2, Xperia 10…): XperiaX
UI LANGUAGE: German
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

After update to new version, I’m recognizing random closing of all apps once in a while.
This bug is very anoing, because closed messangers, e.g. Fernschreiber, do not longer receive messages. You only know it after unlocking the phone and seeing no apps are open.

Anybody else experiencing this issue?
Is there a specific log file where I can get information what is happening?

PRECONDITIONS:

Some apps open (Browser, Fernschreiber, Whatsapp, Mail)

STEPS TO REPRODUCE:

Don’t know.

EXPECTED RESULT:

Apps are still open when phone is left untouched for some hours.

ACTUAL RESULT:

All apps are closed. Maybe homescreen is restartet.

ADDITIONAL INFORMATION:

I don’t know if homescreen is restartet completely, or out of memory causes all apps to be closed. In SysMon it looks like at least 500MB RAM are free all the time, so it should not be necessary to close all apps.
Phone is not rebooting completely, because I don’t need to enter PIN again. So it is not an Issue about bad hardware or charger.

2 Likes
Xperia 10 II + SFOS
#2

I’ve been experiencing apps being killed, very often lately, since 4.1 update. For Sailfish apps, Browser is the most occurring and noticeable one (compared to the previous OS version).
As for Android apps, it seems like the device could no longer handle more than 2 (Heavy??)Android apps running at a time. In my use case, Chrome and/or Edge browsers crash within a few seconds after opening them, usually with a couple of SF apps running as well.

#3

Happened to me on XA2 today.

#4

Any journal logs from anyone?

3 Likes
#5

It happens also to me, 1 or 2 times since the last update. But it was always possible to restart the closed apps and proceed using them. No further crashes or data loss occured & no reboot necessary.

#6

In the same state we left them running?
Some timer applications, some GPS logging, …
and especially annoying (to me) running long time shell commands (never happened on 1GB Jolla1!) like compilation, logging, analyzing scripts, etc.

These OOM killers are killing user experience!

#7

I have uploaded the journal.txt file here.

Only Settings App, Whatsapp and Microsoft edge running in the foreground. After a few minutes of usage, the edge crashed.

Probable suspect:

May 24 19:44:54 XperiaXA2-DualSIM init: Untracked pid 5239 exited with status 0
May 24 19:44:54 XperiaXA2-DualSIM kernel: binder: release 24938:24939 transaction 30247174 in, still active
May 24 19:44:54 XperiaXA2-DualSIM kernel: binder: send failed reply for transaction 30247174 to 27166:27166
May 24 19:44:54 XperiaXA2-DualSIM init: Service ‘mediadrm’ (pid 4926) received signal 6
May 24 19:44:54 XperiaXA2-DualSIM init: Sending signal 9 to service ‘mediadrm’ (pid 4926) process group…
May 24 19:44:54 XperiaXA2-DualSIM libprocessgroup: Successfully killed process cgroup uid 1013 pid 4926 in 14ms
May 24 19:44:54 XperiaXA2-DualSIM init: Untracked pid 5241 exited with status 0
May 24 19:44:54 XperiaXA2-DualSIM init: starting service ‘mediadrm’…

PS: It will be good if the occurrences of the following log are reduced :wink:

May 24 19:44:54 XperiaXA2-DualSIM kernel: binder: 16509 RLIMIT_NICE not set

2 Likes
#8

The log you provided is not full log and might be missing relevant information, please try with “journalctl -b --no-pager | grep -v RLIMIT_NICE” (the last part if to remove some of the useless repeating messages). Do the app covers disappear completely from the homescreen or do they just become grey?

1 Like
#9

It was minimized GPSinfo that crashed, so no loss of any data.
After restarting GPSinfo, app was working again and the app was not damaged by the crash.

What is an OOM killer?

#10

I have uploaded the journal.txt file that got created using no-pager option here. Kindly check whether it’s what is being expected here.

Also, the app crashes and becomes grey on the home screen.

#11

When the available free RAM in the system becomes 0, OS tries to reclaim it by killing the running process. Ref: OOM_Killer.
Restarting the application will work, but it won’t be restored to the previous running state. For example, when the Edge browser crashed on my phone, restarting it will only reload the site. It won’t take me to the last scroll position before crash.

2 Likes
#12

If it is any help, I use this script, called from cron or a systemd timer, to get notified about OOM killer runs. It’s not perfect as it keeps repeating the same event multiple times, but it’s good enough to get an idea when it happens. Currently it just does notifications, but one would save a journal or dmesg file somewhere for debugging.

#!/bin/bash

# docs:
# https://sailfishos.org/develop/docs/nemo-qml-plugin-notifications/qml-nemo-notifications-notification.html/

expire=$(( 60 * 60 * 1000 )) # ms --> 1h
maxlines=15
# 0: low 1: normal 2: high
urgency=1

if [[ $( dmesg -t | grep -c oom_reaper ) -ne 0 ]]; then
        line=$( dmesg | grep -m 1 oom_reaper )
        id=$( echo $line | cut -d" " -f1 | sed 's/[][\.]//g' )
        time=$( dmesg --time-format ctime  | cut -d " " -f 2-4 )
        body=$( echo $line | cut -d " " -f2- | sed -e 's/process.*(\([^)]*\)),.*$/\1/' )
        lbody=$(dmesg -t | grep -B1 -m 1 oom_reaper | sed -e 's/process.*(\(.*\))/\1/g')
        echo OOM killer run found
        title="OOM: $time: $body"
        notificationtool -o update --application=OOMNotifier --id=$id --urgency=$urgency --icon=icon-locked-warning --hint="x-nemo-max-content-lines $maxlines" --hint="expire_timeout $expire" --hint="x-nemo-feedback general_warning" --hint="sound-name dialog-warning" --hint="x-nemo-display-on true" "$title $body" "$lbody" "$title" "$body"
fi

Systemd timer files:
.config/systemd/user/check-oom.timer

[Unit]
Description=OOM Checker timer

[Timer]
#OnBootSec=5min
#OnUnitActiveSec=5min
#OnCalendar=*-*-* 08..19:00,10,20,30,40,50
# I am too stupid to express this more elegantly:
OnCalendar=Mon-Sun 06,07,08,09,10,11,12,13,13,15,16,17,18,19,20,21,23:00,05,10,15,20,25,30,35,40,45,50,55
Persistent=false
WakeSystem=false

[Install]
WantedBy=timers.target

.config/systemd/user/check-oom.service

[Unit]
Description=OOM Checker
After=lipstick.service

[Service]
Type=simple
ExecStart=/bin/bash /home/nemo/bin/sys_check-oom.sh

#[Install]
#WantedBy=user-session.target
3 Likes
#13

Hello again,
it happend last night again, so I was able to grab the journal and provided it to jovirkku.

I don’t think this issue is caused by OOM. I recognized, that Patchmanager window appears when it happens (There are no patches active or working). If only apps got killed, this won’t appear.
Also OOM would kill only some apps not all together at the same time. Another hint to find the cause: The screen turns on when it happens.
So it is not going on in the background, but looks like a restart of window manager.

1 Like
#14

Hi - i did not log anything right now. But i looked at System Monitor - and RAM usage did not go over 2200MB (X10 i). Which does not look like 99% percent to me.
I have the app Takeoff which starts apps after boot.
My crash has been while using an android app, phone want black and after some seconds it was possible to turn the screen back an (not shure if had to enter the code) and Takeoff started all my windows - like a after a fresh start.

#15

I’m on 4.1.0.24 and it’s happened to me multiple times where all apps shut down at once - similar to a home screen restart.

A lot more frequently too now is that applications like the native browser will stay open, but the process has shut down - and when I click on the window the program has to start back up again.

1 Like
#16

also happened to me couple of times… yeah, might not be thee oom, apps completely gone from the home screen, not greyed out

1 Like
#17

For me this has been an issue much longer. It is usually the standard internet browser that is the reason to it. It is very annoying why all running apps has to be stopped when only one app is the reason. It is not what you expect from a true multitasking linux based OS and bring memories back to early Microsoft Windows.

1 Like
#18

Yeah OOM killer seems to be pretty damn annoying. I “updated” from Xperia X to X10-2 and it has four gigs of ram which should be quite enough for normal use. Still some programs are being killed all the time in the background and they’re not even memoryhogs so something else is happening. First think probably is that this is aarch64 platform so programs do eat more ram by nature (remember using Windoze 64bit with 2 or 4 gigs of ram? :slight_smile:

Now i tried to adjust the behaviour of the oomkiller and “echo 2 > /proc/sys/vm/overcommit_memory” was not a good idea it seems. Note that this is a trinary value: 0 = “estimate if we have enough RAM”, 1 = “Always say yes”, 2 = “say no if we don’t have the memory”). That killed lipstick (UI) right away and i was left with a black screen unable to do anything, but still sfos was running there. Apparently UI doesn’t cope well if denied any ram (why would it ask too much?)

Wouldn’t dare to disable oomkiller completely (Put vm.oom-kill = 0 in /etc/sysctl.conf) because such irrational behaviour.

Now “echo 1 > /proc/sys/vm/oom_kill_allocating_task” seems most straightforward way and in some sense it does even work! So if application tries to allocate too much memory oomkiller should kill that task instead of the little ones that are helplessly running in the background. So having my daily programs running nicely i try to start web Browser and that dies instantly. Good. Trying second time it starts and i can use it normally and nothing got killed in the background. Funny how browser knew not to ask too much ram the second time it’s run :wink:

/proc/sys/vm/overcommit_ratio seems to be 50 now. There was a good discussion about that in the old forums. [Discussion] Oom Killer fine tuning (overcommit_ratio value) - together.jolla.com
Tried adjusting that but reaper keeps on reaping.

Anything else one can try to save the little ones?

2 Likes
#19

Updated yesterday to 4.4.0.64 (Vanha Rauma). Situation has not improved.

1 Like
#20

Please also check this thread about lowmemorykiller (or lmkd):

Short version: /sys/module/lowmemorykiller/parameters/minfree contains ridiculously high free memory limits (and setting a higher swappiness helps a bit too).

@jovirkku There are logs and a logging command, too.

1 Like