Server stopping when backgrounded

[londondev77]

Device model: iPad 2017
Jailbreak (e.g. checkra1n, unc0ver, Chimera, etc): Unc0ver 5.3.1
iOS Version: 13.5
How you installed the app: Using DEB
SMServer version: 0.3.4

I find that after a certain amount of time being backgrounded, the server stops running - even if I just leave the iPad and don't run other apps. If I do run a number of other apps, this time period is shorter. The app doesn't seem to crash, it's just the server that stops.

Before I try restoring my iPad to see if this helps, I wanted to see if this was a common issue. I've removed all tweaks to try to minimise any memory usage. I've also tried SSHing in to keep an eye on the logs but annoyingly, for some reason, the SSH session drops quite regularly (this is what makes me think maybe restoring the iPad would help).

Would it make more sense if the server was run as a daemon as it's my understanding that these run in the background correctly?

[itsjunetime]

So I've only had one other person so far tell me that they were running into a similar issue, so it could be widespread but I think it may just be a few isolated cases. You could try restoring your iPad, I guess, but (obviously) there's no guarantee that'll help. Listening to logs would definitely help though, so if you're ever able to get some when the server dies, send them over.

You're right, it would definitely be better to run this as a daemon, but the solution that I currently have implemented seemed to work just fine for me. However, if it seems that the current backgrounding solution isn't working well for a lot of people, I could look into enabling this app to run as a daemon.

[londondev77]

I've restored RootFS and reinstalled SMServer and now, having opened up every app possible, the server continues to run. Can you keep this issue open for a few more days in case it starts happening again and then add to this thread?

(Annoyingly, SSH still continues to keep dropping, no idea why!)

[itsjunetime]

Yeah, I'll leave it open for a week or so; like you said, please update if it happens again. I'll also update if the other person who ran into this has an update.

[MyDimeIsUp]

I'm having this problem too. I think now the app is crashing even when I send a msg.

[itsjunetime]

@MyDimeIsUp Does the app crash if you leave it open & in the foreground when sending the text? And does it consistently crash or is it only occasionally?

[MyDimeIsUp]

@MyDimeIsUp Does the app crash if you leave it open & in the foreground when sending the text? And does it consistently crash or is it only occasionally?

Crashes when sending a text on the webpanel when the app is open in the background. Let me check about foreground.

[londondev77]

I'm still having the server stop even when I just leave my iPad for some time. Unfortuantely, I've been unable to capture any logs which I realise doesn't help. Let me know if there's anything I can do to generate something meaningful.

[londondev77]

I had to completely wipe my router for completely unrelated reasons but now my SSH isn't dropping every couple of minutes so it stays up when the server closes. Unfortuantely, I don't think the log is revealing much:

Aug 26 18:41:25 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: Got past adding all the handlers.
Aug 26 18:41:25 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: Started websocket successfully.
Aug 26 18:41:25 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: Successfully started server and launched MobileSMS
Aug 26 18:42:50 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: sceneDidEnterBackground, starting background task
Aug 26 18:42:50 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: started background task...
Aug 26 18:43:16 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1168] <Debug>: SMServer_app: relaunching app...
Aug 26 18:43:16 AL-iPad SpringBoard[331] <Notice>: LibSMServer_app: called relaunchSMServer
Aug 26 19:01:28 AL-iPad SMServer(com.ianwelker.smserver.debugging)[1218] <Debug>: SMServer_app: Could not load custom css file

[itsjunetime]

No, this could actually be pretty informative. Assuming this happened all at the time that the timestamps state (between 18:41 and 19:01), did you manually restart the app any time in these logs, or did this all appear while the app was in the background? Also, were there any other logs that appeared after this first one or is this the complete record of logs that appeared after 18:41:25?

[londondev77]

No, I didn't restart during the log capturing. Those are all the logs that appeared after 18:41:25. I can share the log for the entire time the server was running if it helps although I'll have to do some scrubbing of personal info first...

[itsjunetime]

No, it's all good, this is enough.

So, the way that the app keeps in the background is that whenever the app enters the background, a background task is started. Then, when the system tries to kill & clean up the background task, it tells libsmserver to restart the app SMServer in the background. It then creates a new background task, then the system tries to kill it, etc. Normally, in my testing, libsmserver is able to re-launch SMServer before the system totally kills it, so the app never actually dies. But it appears that your system is actually killing the app, and then it is being restarted by libsmserver. You can tell this based on your last line, Could not load custom css file, which only appears when the app is being reopened after being completely killed.

I'll look into this, but since I'm using a pretty hacky/unusual method to keep it alive, I may have to find a new way to keep it alive in the background, which may take a while. I'll update this task if I make any progress on it, though.

[itsjunetime]

Update: The current backgrounding method broke for me today; didn't change anything but it's just not working anymore, so this'll be a top priority and I'll hopefully have it fixed by the next update.

[blanxd]

If the ssh session drops as well, it means the device is just going to sleep, this is something that started with iOS13, earlier it was possible to get around this, there were tweaks like iNoSleep et al, which don't work any more (I'm involved in another project that relies on background stuff that's why I'm familiar with this). A simple backgroundTask mangling doesn't really help since iOS 11.something, although it was possible to still make stuff work (re-run the task etc) on 11/12 with the official APIs.
It "goes to sleep" and pretty much everything stops until the OS decides to "do" something like check for some background fetch stuff or so, there isn't much one can do about it. Even things like "background daemons" aren't actually operational until the OS briefly wakes itself, which may happen at some very random intervals, 5-20 minutes usually, depends on what apps are installed etc. Just leave a ping running on your computer and see how often the iOS device responds. Afaik the only thing that remains operational at all times is the Push Notification system, which is always able to receive messages from the iCloud servers (search for the connections to port 5223 on your router if you can (the remote IP is some Apple IP), these remain even when the device doesn't respond to ping).
(yes, tricks do exist... I remain obscure here, please do forgive me)

[itsjunetime]

@blanxd sorry to disagree, but the reason I'm using this method is that it was actually working fine for me up until very recently. I tested multiple times, and was able to get the server running for as long as I wanted even when the screen was off by simply re-opening the app after the system tried to kill the background task. However, I've been testing out old versions of SMServer to see if I can determine exactly when it stopped working, and I think it was sometime around 0.3.0, which leads me to believe that it's something about the web framework I'm using (since I switched to a new framework in 0.3.0).

I'll keep poking around in that area, but if you happen to know any other way to keep things running in the background (e.g. any classes/methods to hook to prevent app termination), I'd love to hear about them. It would make things much easier and cleaner than the current method.