Session/task remains open after the executable is finished

[termux]

Session/task remains open after the executable is finished

[agnostic-apollo]

phew!

[agnostic-apollo]

That's likely because you have not granted Termux app the Draw Over Apps permission and your plugin commands are in waiting until you click the notification at which point they execute and session automatically closes without the need for manual exit. A manual exit would be needed in case you click the termux launcher icon instead of the notification which opens a second session, your plugin command task would likely show in the sidebar in this case.

[xalexalex]

Hey, thanks for answering!

I have just checked and termux-app, termux-api, termux-tasker and tasker have been granted all permissions, including "Draw over other apps" (which in MIUI is called "Display over other apps").

An additional potentially useful piece of information is that termux commands do indeed execute from tasker. It does not wait for me to click on the notifications: commands normally execute and exit, but the notification remains.

[agnostic-apollo]

This is not a plugin issue directly. Sessions and tasks are handled by TermuxService so should be reported there technically. But does the notification say if any tasks or sessions are running when this happens or does it say 0?. Basically, does it go from 1 to 0 considering you are saying that commands do run, what's the flow?

[xalexalex]

The notification never displays 0 sessions and 0 tasks, but it often does not show the correct number. I've just tested, and running concurrent termux:tasker tasks results sometimes in a correct tally and sometimes in 0 sessions and 1 task regardless of the number of running tasks.

In any case, to dismiss the notification the exit button doesn't work and I have to launch and exit the termux app.

If you feel it is appropriate, I can transfer the issue to termux-app.

[agnostic-apollo]

I already tested with 50 concurrent tasks(background) and sessions(foreground) with a for loop in tasker in android 10 avd before the update was released and they worked fine. I have test again, both on android 7 and 10 and notification disappears immediately after the background or foreground tasks are complete, assuming termux was not already running. Since I cannot reproduce the issue, you will have to give more info.

1. Have you tried adding sleep command to your script, commands run pretty quickly and you won't notice the number changes. The template number 4 in the Termux Tasker Plugin Basic Templates Task does have a sleep command in it, you can test that, won't require a script but will require allow-external-apps to be true.
2. What are you exactly running in your scripts, it may be related to why the notification is staying.
3. Make sure commands are properly executed and none are missed. In tasker run a for loop on the %num variable for 1:50 items and try creating a numbered file in termux home in each run of the for loop based on index and see if all 1-50 files are created. Set Executable field to $PREFIX/bin/bash and Arguments to -c "touch %num.plugin.txt". You can remove them all with find ~/ -name '*.plugin.txt' -delete from terminal session afterwards. This may not be needed but I don't know what the issue is currently and you said that numbers are not consistent and could be device specific issue.

The issue will have to be moved eventually if its actually a issue.

[xalexalex]

Hey,

1. yes, I've tested custom commands with sleep as well as template 4 (and the other templates); the issue still happens
2. I do have some complicated scripts with forks etc, but the issue happens even with echo x; sleep 2
3. I tried this and it works perfectly (but the notification still remains after the completion of the tasks)

[agnostic-apollo]

From the looks of it updateNotification() which is triggered when commands end, is not calling stopForeground(true) before calling stopSelf() and neither is onStartCommand() when handling ACTION_STOP_SERVICE which is triggered by the exit button. This could likely be preventing the TermuxService from being destroyed and keeping the notification.

The docs state the following

To remove the service from the foreground, call stopForeground(). This method takes a boolean, which indicates whether to remove the status bar notification as well. Note that the service continues to run.
If you stop the service while it's running in the foreground, its notification is removed.

This may be why the exit button works to destroy the service without a call to stopForeground() if a session is running in foreground but requires the call if the service is being signalled to stop from the background with stopSelf(). Just a reasonable guess, although other devices would have been affected by this as well. Currently, termux-app is not doing any logging so checking logcat might not be useful and a custom build with logging would be required to confirm this, and since it's not happening in avd, it will require an affected device. However, maybe android logs something about not stopping the service in logcat, so check that. I'll try sending a custom build soon, but busy with something else at the moment, likely for a few days. I also have to fix a few other exceptions and bugs in termux-app which are also going to be time consuming so not wise to switch immediately to this. Maybe someone else can take this up if its time sensitive.

[xalexalex]

Hey,
I am in fact running a self-built termux environment, so I can add some Log.d's here and there.
A quick logcat check before editing the code and recompiling, clicking on the Exit notification action gives
01-16 11:56:55.182 1953 2531 W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService

Which seems like a MIUI bug because I have in fact disabled battery restrictions for termux and done everything dontkillmyapp says. There seem to be some potential workarounds and other chinese phones seem to be affected.

[xalexalex]

This is a logcat of running a task ($PREFIX/bin/bash args: -c ls) without any extra debug logs.

01-16 12:29:37.424 14317 14317 I termux-tasker: FireReceiver received execution intent
01-16 12:29:37.456  1945  4378 W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService
01-16 12:29:37.453 17961 17961 W com.termux: type=1400 audit(0.0:6139): avc: granted { execute } for name="bash" dev="dm-2" ino=1708460 scontext=u:r:untrusted_app_27:s0:c175,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c175,c256,c512,c768 tclass=file
01-16 12:29:37.453 17961 17961 W com.termux: type=1400 audit(0.0:6140): avc: granted { execute_no_trans } for path="/data/data/com.termux/files/usr/bin/bash" dev="dm-2" ino=1708460 scontext=u:r:untrusted_app_27:s0:c175,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c175,c256,c512,c768 tclass=file
01-16 12:29:37.453 17961 17961 W bash    : type=1400 audit(0.0:6141): avc: granted { execute } for path="/data/data/com.termux/files/usr/bin/bash" dev="dm-2" ino=1708460 scontext=u:r:untrusted_app_27:s0:c175,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c175,c256,c512,c768 tclass=file
01-16 12:29:37.464 14225 17963 I termux-task: [17961] starting: [/data/data/com.termux/files/usr/bin/bash, -c, ls]
01-16 12:29:37.463 17961 17961 W bash    : type=1400 audit(0.0:6142): avc: granted { execute } for path="/data/data/com.termux/files/usr/lib/libncursesw.so.6.2" dev="dm-2" ino=1719745 scontext=u:r:untrusted_app_27:s0:c175,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c175,c256,c512,c768 tclass=file
01-16 12:29:37.463 17961 17961 W bash    : type=1400 audit(0.0:6143): avc: granted { execute } for path="/data/data/com.termux/files/usr/lib/libiconv.so" dev="dm-2" ino=1704666 scontext=u:r:untrusted_app_27:s0:c175,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c175,c256,c512,c768 tclass=file
01-16 12:29:37.495 14225 17963 I termux-task: [17961] stdout: bin
01-16 12:29:37.495 14225 17963 I termux-task: [17961] stdout: code
01-16 12:29:37.495 14225 17963 I termux-task: [17961] stdout: storage
01-16 12:29:37.496 14225 17963 I termux-task: [17961] exited normally
01-16 12:29:37.517 14352 17965 I termux-tasker: PluginResultsService received execution result from TermuxService
01-16 12:29:37.518 14352 17965 I termux-tasker: Sending pending result to plugin host app. %err: success (-1)
01-16 12:29:37.590  2183  2183 D StatusBar: onNotificationPosted key=0|com.termux|1337|null|10175 isUpdate=false
01-16 12:29:37.603  2183  2183 D StatusBar: No peeking: unimportant notification: 0|com.termux|1337|null|10175
01-16 12:29:37.700  2183  2183 D StatusBar: No peeking: unimportant notification: 0|com.termux|1337|null|10175

and this is me clicking in vain on the Exit notification button after the task finished but the notification was still there

01-16 12:29:40.888  1945  3501 W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService
01-16 12:29:41.246  1945  3498 W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService
01-16 12:29:41.642  1945  3501 W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService

[agnostic-apollo]

Hey,
So basically the execution happens but the notification stays. Could be a device specific bug and should probably be fixable by manually calling stopForeground(true) before stopSelf() to cancel the notification. However, there seems to be a secondary issue as well which may not occur if the first one gets solved. Clicking the notification to stop the service using a PendingIntent set in the notification action should not result in Service.startForeground() not allowed due to bg restriction warnings since a user is clicking a notification to start a service, notification is in the foreground. Moreover, the warning suggests that the service has already stopped since only then the onCreate() would have been called to run startForeground(). If service was already running, onCreate() wouldn't be called and only onStartCommand() would be called which doesn't call startForeground(). So seems like Termux service stops after execution but only the notification remains.

1. So confirm this by running adb shell dumpsys activity services | grep -E 'ServiceRecord\{.*com\.termux\/.*\.app\.TermuxService\}' command when you get into that stuck notification state after execution, without starting the termux app and see if a ServiceRecord output is shown or not.
2. Secondly, if your phone is throwing bg restriction warnings despite Draw over other apps granted and Background Settings > No restrictions set under battery/power management for termux, then maybe try allowing RUN_IN_BACKGROUND with adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow and see if it changes anything.

I cannot reproduce your issues on android 10 avd or Xiaomi 10T Lite. Notifications clear themselves and don't see any warnings in logcat after granting permissions and disabling optimizations. However, I'll still attempt to fix the notification cancellation on your device.

[xalexalex]

Hey there, sorry for the delay.

1. a ServiceRecord is shown while the task is actually running, but not when the task is over and the notification remains.
2. I granted RUN_IN_BACKGROUND to com.termux, com.termux.api, com.termux.tasker and net.dinglisch.android.taskerm, but the bug is still reproducible. Clicking on the exit button in the zombie termux notification still gives W ActivityManager: Service.startForeground() not allowed due to bg restriction: service com.termux/.app.TermuxService

[xalexalex]

also, for some reason, adding stopForeground(true) before each stopSelf() still doesn't fix the bug.

diff --git a/app/src/main/java/com/termux/app/TermuxService.java b/app/src/main/java/com/termux/app/TermuxService.java
index 955ce86..9c173fc 100644
--- a/app/src/main/java/com/termux/app/TermuxService.java
+++ b/app/src/main/java/com/termux/app/TermuxService.java
@@ -102,6 +102,7 @@ public final class TermuxService extends Service implements SessionChangedCallba
             mWantsToStop = true;
             for (int i = 0; i < mTerminalSessions.size(); i++)
                 mTerminalSessions.get(i).finishIfRunning();
+            stopForeground(true);
             stopSelf();
         } else if (ACTION_LOCK_WAKE.equals(action)) {
             if (mWakeLock == null) {
@@ -193,6 +194,7 @@ public final class TermuxService extends Service implements SessionChangedCallba
     void updateNotification() {
         if (mWakeLock == null && mTerminalSessions.isEmpty() && mBackgroundTasks.isEmpty()) {
             // Exit if we are updating after the user disabled all locks with no sessions or tasks running.
+            stopForeground(true);
             stopSelf();
         } else {
             ((NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE)).notify(NOTIFICATION_ID, buildNotification());
@@ -333,6 +335,7 @@ public final class TermuxService extends Service implements SessionChangedCallba
         if (mTerminalSessions.isEmpty() && mWakeLock == null) {
             // Finish if there are no sessions left and the wake lock is not held, otherwise keep the service alive if
             // holding wake lock since there may be daemon processes (e.g. sshd) running.
+            stopForeground(true);
             stopSelf();
         } else {
             updateNotification();

[agnostic-apollo]

a ServiceRecord is shown while the task is actually running, but not when the task is over and the notification remains.

Thanks for the confirmation. At least we know that service is actually stopping fine.

also, for some reason, adding stopForeground(true) before each stopSelf() still doesn't fix the bug.

Well, that just sucks. Basically you are saying that the notification still stays after execution with your updated code, right?

But considering that the service is actually stopping properly and we basically need to solve the device specific bug of the notification not being cleared, you can try cancelling it manually before each stopForeground(). The secondary issue/warning won't be there if there is no notification to trigger it.

NotificationManager notificationManager = (NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE);
if (notificationManager != null) {
    notificationManager.cancel(NOTIFICATION_ID);
}

[xalexalex]

Update: received a system (MIUI) update today and the problem got fixed. It was not termux's fault at all!

[xalexalex]

Closing. Thank you very much for your patience and assistance!

[agnostic-apollo]

welcome.

[MR-Diamond]

Sorry for the necrobump, but I'm facing the exact same issue:

after running an executable from Tasker, the notification with the running session (if run in terminal) or task (if run as a task) remains active indefinitely. Clicking on the exit button does nothing

The script which I execute from Tasker using Termux plugin is simple: it move file from a directory to another; I also added exit at the end of the script, but doesn't help.

I granted "Draw Over Apps" to Termux but also this doesn't help.
I am on MIUI 12.5.6.0; is an hopeless situation which will be maybe fixed by Xiaomi as happened for @xalexalex ?

[denisidoro]

Same issue here. MIUI 12.5.2.0

[agnostic-apollo]

Once issue occurs, run adb logcat -d > logcat.txt from pc or inside termux with adb from android-tools package and upload the file.

[xalexalex]

Just for the record, the issue came back for me. Whatever xiaomi had done to fix it has been reverted :/

[agnostic-apollo]

Did you report to xiaomi, which android version?

[xalexalex]

MIUI global 12.5.1.0(QFGEUXM), Android 10 QKQ1.190910.002; I'm going to report it to xiaomi right now, but I doubt they'll do anything