[bug] [4.3.0.12] Running apps disappearing from the homescreen

REPRODUCIBILITY (% or how often): >daily
BUILD ID = OS VERSION (Settings > About product): 4.3.0.12
HARDWARE (XA2, X10, X10 II, …): XA2 Plus dual sim
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): No(?)

DESCRIPTION:

TL;DR: Multiple times a day, running apps go missing from the home screen. It doesn’t appear to have anything to do with OOM killer. Work-around reduces the problem.

A few days ago I upgraded to 4.3.0.12 (I was travelling, and couldn’t afford new quirks while I was relying on the phone). Since then apps have slowly been disappearing from the home screen. I’m a long time, full time, sailfish user, and don’t remember seeing this behaviour before. It shouldn’t be confused with OOM killer greying out apps, where the app is killed but holds its place. - I don’t think this has anything to do with OOM killer.

Some observations:

  • I’ve only noticed android apps loosing their tile. Native apps appear immune.
  • When I restart them, they start almost instantly, and almost always in the state that I left them. (As opposed to when they start from scratch where they take several seconds to load since the app containers were introduced a few versions ago, and back to their startup state.)
  • Some apps will disappear, while others remain.
  • It happens to a random running app. Eg sometimes facebook messenger, sometimes whatsapp, sometimes reddit, discord etc. It’s not consistently the same app.
  • I have not noticed whether it happens to a single app at a time, or multiple. But it’s certainly not all.
    • Every time I’ve noticed it, there are have been multiple missing. But I don’t know if I simply hadn’t noticed yet because I hadn’t needed them or the ones below them yet, or if they all disappeared in the same event.

This bug is important for me because I have trouble recognising things visually, and therefore use their position.

PRECONDITIONS:

  • Time: Less than a day results in multiple missing apps.

STEPS TO REPRODUCE:

  1. Start apps.
  2. Time passes.
  3. Not all of the apps are still on the homescreen, but they are still running.

EXPECTED RESULT:

Apps keep their tile position on the home screen until closed or the device is rebooted.

ACTUAL RESULT:

Apps still running, but not visible until tapping on their icon in the app drawer.

ADDITIONAL INFORMATION:

Any suggestions for what to capture? I haven’t found any way to get logs out of lipstick. Is lipstick what I should be looking at? I’ve tried:

Edits:

  • 2021-01-14: Clarified observations.
1 Like

An interesting datapoint

This has not happened, even once, since I filed the bug report yesterday. The only change that I have made in the time window before then to now is that I:

  1. Enabled debugging.
  2. systemctl --user restart lipstick
  3. Deleted the file I created when enabling debugging.
  4. systemctl --user restart lipstick

I have just rebooted the phone, and expect to see the problem again. Whether I do or not will be the next data point, so I’ll report back (probably tomorrow).

Theories

  • I’m thinking that there might be an ordering/timing bug in the startup of lipstick. Eg when I manually restart lipstick, android support is now fully running.
  • Maybe one of the patches that I’m running is breaking something. So I’ll test that after testing the restarting of the service (see test plan below).

Test plan

Test name When Progress Result Expected result
Enable debugging. 2021-01-12 Done Failed to get useful info directly. Reverted.
Restart lipstick service via SSH. 2021-01-12 Done Problem disappeared.
Reboot. 2021-01-13 Done Problem recurred late in the day. Problem.
Disable all patches, and reboot. 2021-01-14 Done Problem recurred. But only one app disappeared in the whole day. Going to repeat in case it was user-error (eg I closed the app.). Problem.
Reboot with patches enabled, and 1 updated, and 1 obsolete patch removed. (control) 2021-01-15 Done Problem recurred mid afternoon. Problem.
Disable all patches, and reboot. (repeat) 2022-01-16 Done Problem recurred late in the afternoon. Problem.
Restart lipstick service immediately after reboot via SSH. (My normal patches enabled.) 2022-01-17 Done Problem recurred overnight without interaction. Problem.
Restart lipstick service after one android app has been started via SSH. (My normal patches enabled.) 2022-01-17 FAIL Lipstick crashed. This is not something I usually see. Will repeat. Don’t know. Probably no problem.
Restart lipstick service after one android app has been started via SSH. (My normal patches enabled.) 2022-01-17 Done Day 1, no recurrance, so I extended the test to another day. Day 2, no recurrance. Day 3, one app dissapeared. Going to do another control, and then repeat, but via a local terminal. Don’t know. Probably no problem.
Restart lipstick service after “all” android apps have been started via SSH. ? Skip for now. No problem.
Divide and conquer through patches (will take a while) ? Skip for now. Don’t know.
Reboot with patches enabled.(control) 2021-01-19 Done Problem recurred. Problem.
Restart lipstick service via terminal app after 1 android app has been started. 2022-01-20 - 24 Done No problem. I ran the test for a few days. It was absolutely solid. No problem.

Possible work-around

  1. Unlock the phone.
  2. Start at least one android app. (It takes 2 tries for it to work for me. No amount of waiting gets it started.)
  3. Restart lipstick normally without devel-su:
    systemctl --user restart lipstick
    Via SSH (and probably via the terminal app works as well. That’s my next test.)
  4. Start your apps normally.

Edits

  • 2021-01-14:
    • Add test results.
    • Format results for easier reading.
    • Clarified the first day of testing.
  • 2021-01-15:
    • Add test results.
  • 2021-01-16:
    • Add test results.
  • 2021-01-17:
    • Add test results.
    • Restarting lipstick with one android app running: Android support still declared that it was starting just like it does for a fresh reboot. I suspect the problem is going to recur.
  • 2021-01-17:
    • Repeating test after lipstick crash.
  • 2021-01-19:
    • Add test results.
    • Update possible work-around.
    • Clean up table to make it more readable.
    • Add more tests to gain certainty.
  • 2021-01-24:
    • Add test results.

I’ve run out of endurance for this line of testing, and am confident in the results that I have. So I’m giving this a rest. But if anyone has anything particular things they want to me to check or test, please let me know.

In the mean time, I have a reliable work-around, and some results:

Work around (confirmed)

  1. Unlock the phone.
  2. Start at least one android app. (It takes 2 tries for and app to start for me. No amount of waiting gets it started.)
  3. Restart lipstick normally without devel-su:
    systemctl --user restart lipstick
    Via SSH or terminal app.
    This will take several seconds to finish restarting. But once it does, you’re done.
  4. Start your apps normally.

Results

  • Whether I have patches loaded via patchmanager or not does not affect the outcome.
  • Restarting lipstick after at least one android app has been started since boot makes it run stably.
    • Restarting without having started any android apps does not help.
  • The problem usually takes many hours to manifest, but always happened within 24 hours during my testing.
    • However, I only extended tests beyond a day when it looked interesting to do so. Eg when there had been no occurrence of the bug yet.
  • Sometimes multiple apps disappear, sometimes only one.
  • It’s always android apps.

Thoughts

This feels, to me, like a race-condition where something hasn’t started in time. But without logging, I’m shooting in the dark. If you know where I could find logging for lipstick, that would be very helpful.

The day after I posted the work-around, the bug recurred with the work-around having been applied a few days earlier. So it appears to only slow down the problem by a few days, but not eliminate it.

No change in 4.3.0.15. The work-around still delays the problem by up to a day, but doesn’t solve it.

Thanks for your bug report @ksandom, and for all of the useful follow-up information as well. I’ve created an internal bug report about this and so have also tagged it as “tracked”.

Can I please check: are you still experiencing this on Sailfish OS 4.4.0?

I am frequently running into this with 4.4.0.68 on X10III. The worst example was when I restarted my phone, started the Email app, and it just vanished (no animations) from existence when I clicked an email to open it.

(I still believe this is OOM killer gone wrong, it could explain why my X10III screen sometimes freezes mid-use, but SSH remains active, and I can gracefully reboot the device.)

I have this as well on X10 III 4.4.0.68, maybe 3 or 4 timrs a week, and usually its the web browser or emsil client that disappears. This always happens when you try to do something (open new web page, start new email, update email, etc), never when the app is just sitting there.

1 Like

+1, E-Mail and Browser disappear sometimes, no scheme recognizable (4.4.0.68, Xperia 10 III).

Hi @flypig ,

Thanks for getting back to me.

I’d love to, but the charging port on my device has died and I’m only able to trickle charge it when it’s turned off. So an upgrade would be quite risky. I’ll see if I can find a solution to this, and get back to you if I do. The catch is that it would take a random amount of time to manifest, which could be longer than I can currently keep the device on for. So even if I get it upgraded, I won’t be able to be confident that it is fixed if I don’t see the problem before I have to turn it off. But reproducing the problem would still be useful.

It’s interesting to hear @direc85 and @Steve_Everett 's experiences there. If I remember correctly, the email and browser are both native apps. Correct? When ever I was watching for it, I only ever saw the issue on Android apps. But it’s definitely possible that it happened with native apps as well, and I just didn’t notice. (I used the Android apps much more, so I kept those in predictable positions. So it would have been much easier to spot those disappearing.)

Scratch that. After posting that comment, I thought “stuff it, I’m not using the phone anyway because of the charging issue, and I have everything backed up”. Soooo:

  • I’ve upgraded all the way to 4.4.0.68.
  • I’ll turn off the phone to charge it each night. Hopefully I can reproduce the problem before that, but if I don’t; we won’t have absolute confidence that the problem is no longer there.
  • I’ll try to mimic my old behaviour with the device (whatsapp is now on another device, but otherwise it should be pretty do-able.)

I notice that the Android apps are now back to starting up really quickly after boot. Awesome!

It’s amazing how much Sailfish feels like home when you turn on the device for the first time in a while. It really is a lovely system to use.

Sorry for the late reply. I wrote that just before going on holiday. I did some testing, but didn’t get a chance to write it up.

I tried to replicate my normal usage, but ultimately some things are hard to replicate without moving over to it as my daily driver again. (I need to be able to rely on it taking a charge, but the phone is physically broken so is unreliable.)

The biggest differences between my testing and how I would use it if I was legitimately using it as my daily driver are Whatsapp, and running it for several days without rebooting.

On at least one night (but I think two) I had enough charge a the end of the day to keep it running over night, and continued the test on the next day, like I would if I was daily driving it. Usually the problem manifests itself in a single day, but sometimes it needed 2 or 3 days.

In my testing, I did not reproduce the problem on 4.4.0.68. That’s not to say that the problem is no longer there, but in about 4-5 days of testing, I did not reproduce it.

If someone is still having this problem, an interesting data point could be:

  • Are they using whatsapp?
2 Likes