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.

[AyserJamshidi]

Device model: iPhone Xs
Jailbreak : Unc0ver 5.3.1
iOS Version: 13.5
How you installed the app: Cydia, deb
SMServer version: 0.3.7, 0.3.2

To contribute (maybe?), my crash logs weren't showing anything significant so I just tried grep with SMServer to capture as much as possible. Mine is pretty rapid, within 10-30 seconds of my phone's display being off, it kills SMServer. This is with the latest version (0.31 libsmserver, 0.37 smserver) on twickd. I've tried with libsmserver 0.3 (cydia downgrade) and 0.3.2 (.deb file) with the same outcome. I tried downloading the libsmserver dev versions from twickd but they're no longer hosted.

To avoid a giant block of text in Git, I've put the logs in pastebin: https://pastebin.com/V3vM3cp6

Possible significant lines are: 9, 10, 27, 35, 38, 50, 65, 70

[itsjunetime]

@AyserJamshidi Thank you so much for posting this. I had seen most of those lines before, but line 70 (specifically, the part that says Background entitlement: NO) made me remember that I had removed some background entitlements a while ago from the app that I thought were unnecessary. I added those entitlements back, and I think it somewhat fixed the problem.

Before, the app would get killed after about ~30 seconds of the screen being locked, and you would have to restart the app upon unlock to get the server working again. Now, however, the app is not killed, but rather stays alive in the background even when the screen is locked; however, the server still stops responding after ~30 seconds. Right when you unlock the phone, though, the server starts responding again. This appears to be somewhat better (at least, in my experience) than it was before. I'll update if I make more progress on this issue.

[MyDimeIsUp]

@AyserJamshidi Thank you so much for posting this. I had seen most of those lines before, but line 70 (specifically, the part that says Background entitlement: NO) made me remember that I had removed some background entitlements a while ago from the app that I thought were unnecessary. I added those entitlements back, and I think it somewhat fixed the problem.

Before, the app would get killed after about ~30 seconds of the screen being locked, and you would have to restart the app upon unlock to get the server working again. Now, however, the app is not killed, but rather stays alive in the background even when the screen is locked; however, the server still stops responding after ~30 seconds. Right when you unlock the phone, though, the server starts responding again. This appears to be somewhat better (at least, in my experience) than it was before. I'll update if I make more progress on this issue.

Awesome thanks. I noticed this too after about 30 seconds the server dies.

[AyserJamshidi]

@iandwelker Out of curiosity, what version of iOS are you using to test the app? I have no idea how iOS/xcode app development works but I did stumble upon this stackoverflow post about iOS 13.5.1 (and maybe higher? but was fixed at 13.6 according to one of the comments) not suspending apps in the background, which may be why users who are stuck before that version (OP and I, iOS 13.5) are getting the background issues.

Some more food for thought, there was a similar issue that happened on this react-native issue thread. It seems the problem lied within either the info.plist or one of their commits that messed around with backgrounding.

Aside from that, the logs don't seem to spit anything of importance but the app still crashes (e.g. when I unlock my phone, the app does not appear, I have to reopen it and press start again) but I can supply you with something similar to the previous one I've given. This happens the moment the crash happens: https://pastebin.com/yiJdr9Z7

[itsjunetime]

I'm testing on iOS 13.4.1, so I don't think that's the issue. And I'm also running into the same issues, so I think it's just something that's happening for everyone.

But I actually think I may have found a solution, now, thankfully (after like 3 weeks of looking). I edited the Info.plist file of the app to add another item under the heading Required background modes with the value of continuous (found this under the Info.plist file of CTCarrierSpaceAuth.app). I installed the app with this new Info file, and the app has (at the time of writing) been running in the background with the screen locked for ~6 minutes while showing no signs of errors. I'd like to do some more testing before releasing this to the public, but I think we may have found the solution.

Edit: Currently it appears to only keep unlimited background time when I'm debugging the app. When I try to build it and package it as a .deb (for distribution), it still crashes in the background, so it may take a while to actually get this feature pushed out.

[itsjunetime]

Version 0.4.0 is out now. Unlimited backgrounding time works perfectly fine for me on this version; could you all try it out to let me know if it works for you as well?

[AyserJamshidi]

Version 0.4.0 is out now. Unlimited backgrounding time works perfectly fine for me on this version; could you all try it out to let me know if it works for you as well?

v0.4 solved all background issues for me, great job on hunting down this nasty bug!

[itsjunetime]

Thank you! I'll give others who have commented on this issue some time to respond as well in case they're still seeing issues, and close this if nobody appears to be running into issues.

[blimeybloke]

Yes, all good for me as well. Awesome work and huge appreciation!

[itsjunetime]

All right, I'll close this then. If someone else still happens to be running into issues, they can feel free to reopen this, but I'm closing it until then.