Automate stopping after many days, all power saving turned off

[David Pritchard]

After many days (I'm still trying to work out if there's a pattern to it), Automate stops working until I open the app and it resumes. A couple of days ago it happened after at least 19 days running without incident. The log for one of the flows (they all stop - I have 7 running all the time) says "resumed after restart" after a delay block to delay the flow by 4 minutes. The other flows stop at the same time, though, so it doesn't seem to be related to any particular flow. All the power saving settings I can find are disabled. The phone is a Sony Xperia, and I long ago disabled "stamina" mode. The fact that it runs for so long without incident seems to rule out any power saving setting, I would have thought. Also, my phone is rebooted automatically every weekend during the night (by an Automate flow!), so it can't be a problem of the phone's functions degrading because of system memory leaks or what have you. 

Any ideas?

[David Pritchard]

I have a couple of logs and I just noticed that "Resumed after restart" appears several times - three times in one day in one case - but normally isn't associated with any interruption to the flow at all. For example:

2019-06-04 10:22:52.750 INFO 1416118@79: Time window?

2019-06-04 10:22:52.759 INFO 1416118@80: Delay

2019-06-04 10:42:03.305 INFO 1416118@80: Resumed after restart

2019-06-04 10:42:03.352 INFO 1416118@80: Delay

2019-06-04 12:48:53.919 INFO 1416118@79: Time window?

2019-06-04 12:48:53.932 INFO 1416118@80: Delay

2019-06-04 12:55:29.373 INFO 1416118@80: Resumed after restart

2019-06-04 12:55:29.403 INFO 1416118@80: Delay

The flow continues pretty much as normal. But in the case from a couple of days ago there's a gap of about 35 hours - until I opened the Automate app manually. 

2019-06-10 21:30:17.744 INFO 1416118@82: Time window?

2019-06-10 21:30:17.744 INFO 1416118@11: Delay

2019-06-12 08:31:53.153 INFO 1416118@11: Resumed after restart

2019-06-12 08:31:53.156 INFO 1416118@11: Delay

[David Pritchard]

Is it possible that this might happen if the battery gets very low? I can't remember if the battery got very low on the day in question, but it's possible.

[Henrik "The Developer" Lindqvist]

That's a likely result of a "power save" feature. Please read:

https://llamalab.com/automate/doc/faq.html#automate_not_running

[David Pritchard]

Like I said, power saving is off as far as I can tell. I already went through the FAQ. Also, it's running OK for weeks before this happens.

[Henrik "The Developer" Lindqvist]

Did it start occurring after you update to version 1.19.0?

Do you usually remove, swipe away, Automate from the recent apps screen?

If so, try not doing so.

Android version?

[David Pritchard]

No, it's been happening for a while, before the update to 1.19.0.

I do usually swipe it away. What should I do, use the X to close it?

I'm going to run the battery below 20% and see what happens. 

[Henrik "The Developer" Lindqvist]

I removed a workaround for an Android bug which kills an app when swiped off the recent screen. Just leave it on the recent screen., to see if that's the issue.

[David Pritchard]

OK. I'm pretty sure that's not the cause.

Letting the battery drop to 15% did nothing. I'll try running it down further. 

[David Pritchard]

Sorry I missed one of your questions. The Android version is 5.0.2

[Henrik "The Developer" Lindqvist]

Then the workaround will still be used, so that's not the issue.

Maybe you have some other memory intensive app running which cause Automate to be killed.

[David Pritchard]

It's happened a couple of times in quick succession this month, so there's no obvious pattern in terms of the time between the freezes. It's also not connected to the battery level. I have a couple of logs that captured the event, but I'm not sure if they would tell you anything. I can send them if you like.
Perhaps I could also track memory usage in the log?

[Henrik "The Developer" Lindqvist]

If Automate is terminated because of a low-memory situation, or otherwise, it's logged as "resumed after restart".

[David Pritchard]

Yep, that's what the log says. 

[David Pritchard]

In the end I've applied an unorthodox solution: I use Tasker to watch Automate. If Automate stops running, Tasker restarts it.

[David Pritchard]

Turns out that my solution doesn't work. It seems as if Automate "freezes" but doesn't actually stop running as a process on the phone, so Tasker never detects that it's died. As soon as you open the app, it comes back to life and the "resumed after restart" entry appears in the log for each flow.

I'm now going to try writing the date & time to a file from one of the flows. I'll get Tasker to check the file and see if it's been a while since there was an activity. If so, it will kill Automate and restart it.

[Henrik "The Developer" Lindqvist]

"resumed after restart" means the process was killed. There's no way for apps to tell when an app is "running" so the hack Tasker use is likely just unreliable.

[David Pritchard]

On my version of Android (5.0.2) I think you actually *can* tell when other apps are running (Tasker requires the Tasker Process Running (KC) extension to do this). My phone is rooted, in any case. 

[Pete]

Fyi...I have had this happen due to low memory situations a couple of times. I also use an app called KeepRunning (linked below) to enure Automate stays running. You may also find this app useful.

https://play.google.com/store/apps/details?id=de.defim.apk.keeprunning

[Frantisek Skuta]

This is happening to me as well. My phone says 1GB free out of 3GB. what? what low memory? Am I missing something? 

Dňa utorok, 1. októbra 2019 7:38:24 UTC+2 Pete napísal(-a):

[ttbb6...@gmail.com]

Hey I'm having a similar, very frustrating, problem which may be related. It seems when I have Automate running from a wide range of different times it seems to "reset". I've really noticed this due to all my settings back to default and on screen shows disclaimer just as if I just opened app for first time. I have this happen on about 6 different phones (out of 16). It's almost as if my phone rebooted or something but I'm watching the phone as it happens and out of the blue a disclaimer shows up and u have to change my settings all over again. Have you noticed if your settings were changed? Or disclaimer show up? I'm sorry this is probably proper for new post

[David Pritchard]

The update on this is that not only does KeepRunning not work, even having Tasker periodically kill Automate and then restart it seems to fail, because Tasker seems to die at the same time as Automate.

I did finally manage to catch the problem as it happened and grab the system log. This is what I found:

03-29 20:26:46.549 I/ActivityManager(  939): Force stopping com.llamalab.automate appid=10289 user=0: from pid 6065
03-29 20:26:46.550 I/ActivityManager(  939): Killing 19624:com.llamalab.automate/u0a289 (adj 2): stop com.llamalab.automate
03-29 20:26:46.597 D/WifiService(  939): Client connection lost with reason: 4
03-29 20:26:46.670 W/ActivityManager(  939): Scheduling restart of crashed service com.llamalab.automate/.AutomateService in 1000ms
03-29 20:26:46.677 I/ActivityManager(  939):   Force stopping service ServiceRecord{23ba9612 u0 com.llamalab.automate/.AutomateService}
03-29 20:26:46.683 W/ActivityManager(  939): Spurious death for ProcessRecord{8faec0d 19624:com.llamalab.automate/u0a289}, curProc for 19624: null

26 minutes before, Tasker also suffered "spurious death". 

This almost always happens on a Sunday evening a short time before 20:26. Not every Sunday, but when it happens, it's almost always at this time. I notice that Titanium Backup is scheduled to do a backup at 20:00 on Sunday, and that it's after this that many services appear in the log as suffering "spurious death" after being killed (presumably to save memory). What's odd is that even rebooting doesn't seem to fix it. Automate remains zombified until I specifically open the app.

[Henrik "The Developer" Lindqvist]

Force stopping/closing an app will keep it stopped until manually started.

The system shouldn't do that in a low-memory situation, it just temporarily kills a process.

Only an app using root, like Titanium Backup, could perform an "force close" on other apps.

[David Pritchard]

I think I've solved it. It turns out that Titanium Backup (free edition), closes apps before backing them up, whereas the Pro edition can just "pause" them. I just ran a backup and it seems that Automate is still running. 

However, I should say that most other apps (such as Whatsapp, or Withings Healthmate) seem to be able to carry on working after being killed in the same way:

03-29 20:05:02.309 I/ActivityManager(  939): Force stopping com.whatsapp appid=10284 user=0: from pid 22841

03-29 20:05:02.310 I/ActivityManager(  939): Killing 10556:com.whatsapp/u0a284 (adj 7): stop com.whatsapp

03-29 20:05:02.415 I/WindowState(  939): WIN DEATH: Window{ed8eb40 u0 com.whatsapp/com.whatsapp.HomeActivity}

03-29 20:05:02.524 W/ActivityManager(  939): Scheduling restart of crashed service com.whatsapp/.messaging.MessageService in 1000ms

03-29 20:05:02.530 I/ActivityManager(  939):   Force finishing activity ActivityRecord{29d6cb3c u0 com.whatsapp/.HomeActivity t21905}

03-29 20:05:02.537 I/ActivityManager(  939):   Force stopping service ServiceRecord{248782e3 u0 com.whatsapp/.messaging.MessageService}

03-29 20:05:02.542 W/ActivityManager(  939): Spurious death for ProcessRecord{15b3731b 10556:com.whatsapp/u0a284}, curProc for 10556: null

Healthmate (which counts steps, amongst other things) was killed but then seemed to restart and was able to count my steps after the backup. 

[Henrik "The Developer" Lindqvist]

Look like WhatsApp had an (foreground) Activity running, i.e. it wasn't just running in the background like Automate mostly do, that's probably why it was restarted.

Automate also has two processes running, one for the background service and one for the UI, that may have an impact.

[David Pritchard]

So the background and foreground processes monitor each other and each restarts the other if it dies?

[Henrik "The Developer" Lindqvist]

No. So the UI can be killed, and its memory reclaimed, without affecting the running service. It's "best practice" as suggested by Google.