Question: What is the mechanism of killing processes in Termux

[mitnk]

I was running crond with Termux in another phone work very well. I recently switched to a new phone, the battery optimizer may have issues, and causing the crond process killed randomly.

the pss here is: ps ax | sed 's|/data.*/||'

Note that the crond is killed, but the shell process (pid 2717) is not.

I want to understand how these things happen in the background. Where could I find more clues on how this crond is killed. I've locked this app, and acquired the wake lock. I've set the OS NOT to do any battery optimization on app Termux and Termux-API.

$ termux-info
Application version:
0.110
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://termux.org/packages/ stable main
# game-repo (sources.list.d/game.list)
deb https://grimler.se/game-packages-24 games stable
# science-repo (sources.list.d/science.list)
deb https://grimler.se/science-packages-24 science stable
Updatable packages:
All packages up to date
Android version:
11
Kernel build information:
Linux localhost 5.4.61-qgki-01148-g376d4ad #1 SMP PREEMPT Sat Apr 17 03:38:45 CST 2021 aarch64 Android
Device manufacturer:
OnePlus
Device model:
LE2110

I've tried v0.108, same issue in this phone. I know the main issue must be due to this phone. But I want to know if there is anything we can do in termux side. (e.g. Does the OS have the ability of killing only one of processes in Termux? etc)

[agnostic-apollo]

Does the OS have the ability of killing only one of processes in Termux? etc)

Usually the activity and services running in app's main process should be all or nothing. Check here and here. But empty processes that are not linked to a component may get killed too, as per this. A related issue to yours is posted in termux/termux-boot#5 and the solution is to use termux-job-scheduler implemented in termux/termux-api-package#42.

[mitnk]

Thanks @agnostic-apollo, I've tried termux-job-scheduler. It is much stable than crond, but has the issue of mix interval is 15 minutes. I'll check other resources you posted.

[agnostic-apollo]

Welcome. From a "quick look" the min interval of 15mins is a limitation of android JobScheduler setPeriodic() used by termux-api and probably doesn't work in doze mode. I guess AlarmManager can be implemented instead to provide shorter intervals. It can be looked into in future.

[mitnk]

Some follow up: I found it is one specific service who killed sshd (same logic of killing crond):

$ adb logcat | grep sshd
06-13 12:57:20.255  1722  1722 E OPLUS_KEVENT_RECORD: OPLUS_KEVENT payload:10348,path@@/data/data/com.termux/files/usr/bin/sshd
06-13 12:57:20.274 28862 28862 I sshd    : Server listening on :: port 8022.
06-13 12:57:20.274 28862 28862 I sshd    : Server listening on 0.0.0.0 port 8022.
...
06-13 12:57:58.269 29371 29371 I sshd    : Starting session: shell on pts/1 for u0_a348 from 192.168.0.105 port 49231 id 0

06-13 13:00:12.184  8930 10124 I Athena  : OppoClearSystemService : K [28862][10348]sshd(0), reason: 71
06-13 13:00:12.184  2087  2826 E AthenaKillerManagerService: o-kill [28862] sshd
06-13 13:00:19.069  8930 10124 I Athena  : OppoClearSystemService : K [29371][10348]sshd(0), reason: 71
06-13 13:00:19.070  2087  9518 E AthenaKillerManagerService: o-kill [29371] sshd

Seems I need to fill up a bug-report for the phone vendor or find a way to disable this "Athena" service.

[agnostic-apollo]

Disabling system services itself would likely require root. You could try a less aggressive custom ROM if you are willing to root. Or try adding termux to exemptions in your phone's killer app. Check https://dontkillmyapp.com/oneplus

[mitnk]

Thanks. I won't try rooting the system. I've try every thing adjusting the settings (most items listed in this page). Nothing works.

[mitnk]

@agnostic-apollo Do you know the differences between the shell process (e.g. bash) and the background job (e.g. sshd, crond) in Termux? I mean why sshd got killed but not the shell process?

[agnostic-apollo]

Exempting termux from app killer would reduce chances of com.termux app process from being killed but not demonized processes like sshd due to empty process issue as described above. Probably the only way to reduce empty process from being killed is OS/kernel level modification. Even without app killers, Android Low Memory Killer (LKM) would kill app or empty processes under memory pressure. So exemption would need to be made in ActivityManager or adjustment of minfree values. For more info on LKM and OOM, check here, here, here and here.

Do you know the differences between the shell process (e.g. bash) and the background job (e.g. sshd, crond) in Termux? I mean why sshd got killed but not the shell process?

The difference is as per below. The bash shell process is the child process of com.termux app process, so still attached to a component. Whereas sshd has been demonized and not attached to com.termux and inherited by init. So bash shell would get killed when and if termux app process is killed. For sshd, you can run run it with sshd -D so its not demonized and leave it running in a separate termux session, this way sshd would be child process of bash shell process and hopefully won't be killed. If you already have sshd running, then kill it first with pkill sshd otherwise running command again won't start it since port would already be taken. You can confirm this with sshd -D -dd. You can also run it with nohup sshd -D &>/dev/null & so it runs in background, (not daemon) if you don't want a separate session for it.

$ sshd
$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
u0_a449  10309 30676  5 12:09 ?        00:00:10 com.termux
u0_a449  10361 10309  0 12:09 pts/0    00:00:00 /data/data/com.termux/files/usr/bin/bash -l
u0_a449  10920     1  0 12:12 ?        00:00:00 sshd
u0_a449  10930 10361  3 12:12 pts/0    00:00:00 ps -ef

Without daemon

$ pkill sshd
$ nohup sshd -D &>/dev/null &
[1] 26275
$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
u0_a449  17590 30676  1 12:52 ?        00:00:26 com.termux
u0_a449  22888 17590  0 13:04 pts/1    00:00:00 /data/data/com.termux/files/usr/bin/bash -l
u0_a449  26275 22888  1 13:25 pts/1    00:00:00 sshd -D
u0_a449  26287 22888  3 13:25 pts/1    00:00:00 ps -ef

[mitnk]

This detailed info make a lot of sense to me. And the nohup ... & tip works (far more stable). Thanks a ton!

[agnostic-apollo]

You are welcome a megaton!

[agnostic-apollo]

@mitnk btw you can run crond in foreground too with -n flag, like nohup crond -n &>/dev/null & so that bash shell process is the parent process and crond doesn't get killed due to empty process issue.

Setup job with crontab -e and add * * * * * date >> ~/cron.log. Can later edit the job from file under /data/data/com.termux/files/usr/var/spool/cron and restart crond after pkill crond. Would require wakelock though.

[mitnk]

Got it. Thanks @agnostic-apollo!

[agnostic-apollo]

Welcome!

[ghost]

Seems I need to fill up a bug-report for the phone vendor or find a way to disable this "Athena" service.

@mitnk

I had the same issue regarding Athena service killing some background processes. apparently it can be disabled using adb:

adb shell pm uninstall -k --user 0 com.coloros.athena

this should atleast disable athena service and it wouldn't kill background processes in any way

[agnostic-apollo]

Yeah, that's the usual route if an app is being used to kill other apps instead of the android framework. Hopefully, nothing else breaks because of it, some other system app might be relying on it and may cause battery drain. Check logcat or BetterBatteryStats, etc. If everything is fine, then great.

[mitnk]

Thanks @wmcb-tech, I uninstalled it, and the background jobs are now quite stable. adb rocks :)

Update after ~6 days:
The battery life do reduce significantly after uninstalling com.coloros.athena (like from 2d to 1d?). But all things keep stable indeed. It's a worthy tradeoff for me.

[TREYWANGCQU]

Exempting termux from app killer would reduce chances of com.termux app process from being killed but not demonized processes like sshd due to empty process issue as described above. Probably the only way to reduce empty process from being killed is OS/kernel level modification. Even without app killers, Android Low Memory Killer (LKM) would kill app or empty processes under memory pressure. So exemption would need to be made in ActivityManager or adjustment of minfree values. For more info on LKM and OOM, check here, here, here and here.

Do you know the differences between the shell process (e.g. bash) and the background job (e.g. sshd, crond) in Termux? I mean why sshd got killed but not the shell process?

The difference is as per below. The bash shell process is the child process of com.termux app process, so still attached to a component. Whereas sshd has been demonized and not attached to com.termux and inherited by init. So bash shell would get killed when and if termux app process is killed. For sshd, you can run run it with sshd -D so its not demonized and leave it running in a separate termux session, this way sshd would be child process of bash shell process and hopefully won't be killed. If you already have sshd running, then kill it first with pkill sshd otherwise running command again won't start it since port would already be taken. You can confirm this with sshd -D -dd. You can also run it with nohup sshd -D &>/dev/null & so it runs in background, (not daemon) if you don't want a separate session for it.

$ sshd
$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
u0_a449  10309 30676  5 12:09 ?        00:00:10 com.termux
u0_a449  10361 10309  0 12:09 pts/0    00:00:00 /data/data/com.termux/files/usr/bin/bash -l
u0_a449  10920     1  0 12:12 ?        00:00:00 sshd
u0_a449  10930 10361  3 12:12 pts/0    00:00:00 ps -ef

Without daemon

$ pkill sshd
$ nohup sshd -D &>/dev/null &
[1] 26275
$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
u0_a449  17590 30676  1 12:52 ?        00:00:26 com.termux
u0_a449  22888 17590  0 13:04 pts/1    00:00:00 /data/data/com.termux/files/usr/bin/bash -l
u0_a449  26275 22888  1 13:25 pts/1    00:00:00 sshd -D
u0_a449  26287 22888  3 13:25 pts/1    00:00:00 ps -ef

GOOD JOB.
THANKS A LOT.

It just can't stop phone os from killing services by setting battery mode.