search

NeoApplications / Neo-Backup

backup manager for android
GNU Affero General Public License v3.0
2.52k stars 124 forks source link

Syncthing and AFWall+ background services killed even when blacklisted. #777

Closed erahhal closed 8 months ago

erahhal commented 1 year ago

Description Syncthing and AFWall+ background services crash during backup, even though they are blacklisted from backup.

Steps To Reproduce

  1. Install Syncthing and AFWall+ and set them up so their background services are running.
  2. Setup a backup in Neobackup. Settings I'm using:
    • Blacklist - Add AFWall+ and Syncthing
    • App type: Only select "User Apps"
    • Backup types: Select everything
    • Launchable: Select "All Apps"
    • Updated: Select "All Apps"
    • Latest Backup : Select "All App"
    • Enabled: Select "All Apps"
  3. Click "Start now"
  4. Note that both Syncthing and AFWall+ services crashed, with the UI in Syncthing reflecting the service is not running, and AFWall+ giving the error Error applying iptables rules when trying to restart. Killing both apps and restarting them fixes the issue after each backup.

Expected behavior Backups shouldn't kill background services, especially when the apps are black listed

System Information(please complete the following information):

hg42 commented 1 year ago

NB does not kill anything on backup, only on restore (if enabled, which is the default).

Instead, in case "backupPauseApps" preference is enabled, NB uses the unix STOP signal on all processes that have files open in the app directories about to be backed up.

This does not kill the processes but only pause their execution until the backup of this app is finished. After the backup, NB uses the CONT signal to continue the stopped processes.

STOP and CONT should generally work without problems (unless NB is also using those processes, which would give a dead lock, but that's handled by other means). System processes are excluded. And as far as I remember, the handling is also limited to processes belonging to the app user of the app currently backed up. So only sub-processes (and similar) of the backup app should be affected.

There is an additional "backupSupendApps" preference (that is only active when "backupPauseApps" is also enabled), that would also suspend the app (via pm suspend). This should not affect the other apps in any way.

If you are unsure, disable "backupPauseApps", then NB only does the backup without any handling of processes.

Note, at least at this lower level, it's not easy to find the apps belonging to a process, and check if they are excluded. And it doesn't matter, because if they have files open in the app directory they need to be stopped, otherwise they would write files that are currently archived. If backupPauseApps is active, you expect that files are not changed while storing. If you disable this, you take this possibility into account (e.g. eventually getting inconsistent backups). Though, it doesn't seem to be a high risk in practice (concluding from the kind of reports we get).

Not sure, why your services are crashing (btw. are they really? there are several ways how they could "crash" or look like that).

It may be possible, that a service is observing signals and instead of ignoring those it do not want, it may crash instead (e.g. because it's an unexpected signal). Java libraries are heavily exception based, so it is a very common problem, that developers overlook a possible exception (or miss catching all), but that's not NB's fault. A similar situation could be, if the service has certain expectations, that are no more true, if the service is paused for some time. Again, the unexpected situation could cause an exception and if it is not catched/handled, the whole service is terminated.

erahhal commented 1 year ago

Amazing explanation, thank you. Based on your response, I looked at what files Syncthing and AFWall might be accessing that are also accesses by other apps. I removed one share and blacklisted one app for Syncthing, and blacklisted the AFWall Unlock Key app, which is almost certainly accessed by AFWall, and what do you know? It worked, neither app fails now!

Thank you!

Edit: i spoke too soon. The manual run i did worked out but the scheduled run that just finished still resulted in the same failures. Not sure if it was random luck or there's something different about scheduled runs.

hg42 commented 1 year ago

I don't think a schedule is much different, when looking at the program logic.

However, a schedule is a service itself, and it is usually run in a much different system state. E.g. the doze mode of Android pauses all services for some time and then wakes up all the sleeping services at once. So, it might be a lot more probable that another service is active at the same time.

During the backup, I would

erahhal commented 8 months ago

I think this was an issue with the particular build of LineageOS I was using, After a couple updates the problem went away. Feel free to close this if you wish.