5 ms·

The Linux OOM killer (used heavily by Android as part of normal operation) does a SIGKILL. I believe iOS does this as well. So pretty sure this is totally fine

The Linux OOM killer (used heavily by Android as part of normal operation) does a SIGKILL. I believe iOS does this as well. So pretty sure this is totally fine and not a problem in the slightest, seeing as some billion devices or so are doing this on a daily basis.

gilgoomesh 13y ago
iOS may use SIGKILL when out of memory or you're killed in the background (in most cases it sends a memory warning or -[NSApplication applicationWillTerminate:] message first and gives up to 5 seconds before SIGKILL). You do need to be a little careful as an app writer. All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ.
- kllrnohj 13y ago
  > All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ. You should be doing that regardless, there's nothing special about SIGKILL in this regard. Dirty pages will still get flushed to disk, so SIGKILL is safer than, say, sudden power loss. Which isn't exactly unheard of on battery powered devices, after all.
tjohns 13y ago
Android's OOM killer won't run until after an activity's onPause() or onStop() method has been called, which gives applications a chance to save their state. A foreground activity is typically considered unkillable. Background services have weaker lifecycle guarantees, but the system can be asked to automatically restart your service and re-delivery any Intents that were being processed. It's not like the system is regularly killing apps without any recovery options. Dealing with these lifecycle events is a key part of Android development, so apps are designed to deal with them. See: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle http://developer.android.com/reference/android/app/Activity.... http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle http://developer.android.com/reference/android/app/Service.h...
- kllrnohj 13y ago
  Process is considered killable after onPause, there's no requirement that onStop is called. And, in practice, onStop/onDestroy are rarely called outside of an activity calling finish() on itself. But that call only gives that activity a chance to save state, not the process as a whole. You don't run around stopping all your services and such in onPause(). There is no SIGTERM equivalent where you can go around doing actual cleanup work for the entire process. As for Services you'll note it's considered killable at any given point, there's largely no guarantees other than it won't be killed in the middle of executing code in onStart/onStop. But during the bulk of its actual work it's totally up for random killing. And fwiw foreground processes are totally considered killable. They are the last in the queue, yes, but they are still in the queue.
  - takeda 13y ago
    The difference between SIGKILL (is Android actually using SIGKILL?) and onPause() then SIGKILL is that the process still has time to save state (the most important part) and the code itself is not resumed until onResume() is called. On standard UNIX there's no onPause() or anything similar, so the process cannot react to this in any way.
    - kllrnohj 13y ago
      The state save is important in terms of being able to rebuild the UI quickly. It's not important in the context of "heavy" resources like files, sockets, etc... None of those are ever cleaned up in onPause. The worst thing that will happen if you SIGKILL an Android app without calling onPause first is that the next time it's launched it won't resume from where you left off, it will be as if you rebooted the device. Also to be clear the onPause and SIGKILL are not tied together. You could get an onPause and it be minutes or hours or even days before you get SIGKILL'd, during which you are completely free to keep running code in the background. And depending on how your process was started there might not even have been an Activity to be onPause'd in the first place. Consider an app that started doing work in response to a broadcast or content provider query.
lazyant 13y ago
I wouldn't say it's totally fine when oom kills mysqld and corrupts tables for example when a shutdown as alternative would have been better. Unfortunately oom-killer is not that smart.
- jeltz 13y ago
  I really hope you are wrong about killing mysqld corrupting tables, because if it does then I would not want mysql near my data. Databases should use a journal for crash safety.
  - lazyant 13y ago
    Sometimes, not always but it does happen, I've seen it many times
- kllrnohj 13y ago
  Then don't use mysqld as it's obviously broken. Even SQLite doesn't have that problem.

gilgoomesh 13y ago

iOS may use SIGKILL when out of memory or you're killed in the background (in most cases it sends a memory warning or -[NSApplication applicationWillTerminate:] message first and gives up to 5 seconds before SIGKILL). You do need to be a little careful as an app writer. All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ.

kllrnohj 13y ago
> All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ. You should be doing that regardless, there's nothing special about SIGKILL in this regard. Dirty pages will still get flushed to disk, so SIGKILL is safer than, say, sudden power loss. Which isn't exactly unheard of on battery powered devices, after all.

tjohns 13y ago

Android's OOM killer won't run until after an activity's onPause() or onStop() method has been called, which gives applications a chance to save their state. A foreground activity is typically considered unkillable. Background services have weaker lifecycle guarantees, but the system can be asked to automatically restart your service and re-delivery any Intents that were being processed. It's not like the system is regularly killing apps without any recovery options. Dealing with these lifecycle events is a key part of Android development, so apps are designed to deal with them. See: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle http://developer.android.com/reference/android/app/Activity.... http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle http://developer.android.com/reference/android/app/Service.h...

kllrnohj 13y ago
Process is considered killable after onPause, there's no requirement that onStop is called. And, in practice, onStop/onDestroy are rarely called outside of an activity calling finish() on itself. But that call only gives that activity a chance to save state, not the process as a whole. You don't run around stopping all your services and such in onPause(). There is no SIGTERM equivalent where you can go around doing actual cleanup work for the entire process. As for Services you'll note it's considered killable at any given point, there's largely no guarantees other than it won't be killed in the middle of executing code in onStart/onStop. But during the bulk of its actual work it's totally up for random killing. And fwiw foreground processes are totally considered killable. They are the last in the queue, yes, but they are still in the queue.
- takeda 13y ago
  The difference between SIGKILL (is Android actually using SIGKILL?) and onPause() then SIGKILL is that the process still has time to save state (the most important part) and the code itself is not resumed until onResume() is called. On standard UNIX there's no onPause() or anything similar, so the process cannot react to this in any way.
  - kllrnohj 13y ago
    The state save is important in terms of being able to rebuild the UI quickly. It's not important in the context of "heavy" resources like files, sockets, etc... None of those are ever cleaned up in onPause. The worst thing that will happen if you SIGKILL an Android app without calling onPause first is that the next time it's launched it won't resume from where you left off, it will be as if you rebooted the device. Also to be clear the onPause and SIGKILL are not tied together. You could get an onPause and it be minutes or hours or even days before you get SIGKILL'd, during which you are completely free to keep running code in the background. And depending on how your process was started there might not even have been an Activity to be onPause'd in the first place. Consider an app that started doing work in response to a broadcast or content provider query.

lazyant 13y ago

I wouldn't say it's totally fine when oom kills mysqld and corrupts tables for example when a shutdown as alternative would have been better. Unfortunately oom-killer is not that smart.

jeltz 13y ago
I really hope you are wrong about killing mysqld corrupting tables, because if it does then I would not want mysql near my data. Databases should use a journal for crash safety.
- lazyant 13y ago
  Sometimes, not always but it does happen, I've seen it many times
kllrnohj 13y ago
Then don't use mysqld as it's obviously broken. Even SQLite doesn't have that problem.