I was planning on writing a small daemon that detected whether another app crashed, thinking all the while that the system would send an NSWorkspaceDidTerminateApplicationNotification, but this is not the case.
Assuming that I do not want to create a launchd process to simply re-launch the crashed application, can I detect the crash any other way?
Perhaps I could monitor the system log? That seems unduly burdensome.
How about watching for if/when the /usr/sbin/spindump process starts up?
Turns out what worked best as a crash monitor was reading the FSEventStream for Crash Logs.
Related
I've written a launch daemon for macOS. (It's written in C++.)
The daemon works in most cases, except that once in a while I see that it receives the SIGABRT signal from the own process. (I can see it in a log.)
Because this happens at some random moments, I can't attach a debugger to it.
I'm new to development for macOS. Most of my experience comes from Windows. Thus, I'm wondering if it's possible to generate a crash dump when my daemon receives SIGABRT? And if so, would Xcode allow me to analyze that crash dump file later?
PS. In general how do you guys do it on a macOS?
i have no ideal for initialization code c++ before windows shutdown. For protect algorithm of my code when running. Any ideal here?
I am not sorry to report you cannot do this reliably. You can handle WM_QUERYENDSESSION or WM_ENDSESSION Windows messages, but that really traps logoff not shutdown. Alternately you could try a Windows service and react to the stop signal. But that is exactly that, your service being stopped.
HOWEVER; none of this happens reliably. If you have some defenses best broken by the shutdown code not running, somebody who wants to break them will just power the machine off. If I thought you were writing software that needed to be fault tolerant I would now advise you on crash-only software.
To make a backing store that can survive being powered off without being corrupted, the cheapest way is to use sqlite.
I think you should create an object of your own class and write something inside the destructor (or ~YourClass()).
If an app is brought to the background what happens to the UI Thread which was running this app?
Will it sleep or get killed?
When the app is back to foreground will the same thread be notified or a new thread will created and associated with the app instance?
I don't know specifically, but you should always program with the possibility that your Activity may be killed at any time that it is not in the foreground. Whether that involves killing the thread every time it enters the background, or causing the thread to sleep and then killing it if the Activity is killed, I don't know. In any case, you must assume it can and will happen, and program accordingly.
It depends on the memory situation. When your application goes into the background, it generally stays running initially. Android does not sleep your thread. It is up to you to stop updating your UI and performing calculations in on onPause.
However in low memory situations Android might kill application when it's the background (especially if you haven't been nice and are using up a load of resources). For this reason you should always save any persistant data in onPause.
Is there any way to suspend an application execution, store its process image to a file, and restore it later (keeping the application as it was at the moment of suspension)?
What I want to do is something like an "hibernate" for applications on WinXP.
Is there any application capable of doing this?
What I have so far, is a virtualized system using vmware, where I can suspend and resume applications, but to accomplish the task, I have to suspend the whole virtualized system.
Thank you in advance.
I could imagine if you had an object that would maintain the state of your application and always base the UI on that state object.
When your application is closing, that state object could be serialized/saved. When the application starts back up, it would load/de-serialize your state object and bring your UI back to where you left it.
I can only think of one example when this is done. Unfortunately, it's not done under favourable conditions! You can set up the operating system to create a memory dump whenever a process crashes. This crash dump can then be loaded into a debugger, which can see the exact state of every variable in the process at the time it crashed. I presume you want something similar, but without the process crashing? ;-)
Have you looked at VMWare ThinApp? It sounds like it does what you're trying to achieve...
What I want
I'm developing a little app to force me to only work at certain times of day - I need something to force me to stop working in the evenings so I can be more effective in the day.
The option within OS X to shut down my machine at a certain time is too easy to cancel. And you can always log back in afterwards.
I want my app to quit all applications whether they have unsaved work or not.
What I've tried
I thought of killing the loginwindow process, but I've read that this can cause data corruption.
I've come across the shutdown command - I'm using sudo shutdown -h +0 to shutdown immediately. This appears to be just the ticket, but I'm worried that it might cause data corruption if, say, Disk Utility is doing some kind of scan.
Is the shutdown command safe?
Can the shutdown command cause corruption? Or is it safe to use? Is there a better way of forcing shutdown safely?
Use AppleScript to tell application "System Events" to shut down.
The shutdown command sends running processes a signal to terminate, giving them a chance to do clean up work, if needed. So generally, when an application receives this signal (SIGTERM(inate)) it should wrap up and exit.
IIRC in Snow Leopard (10.6) Apple added something called fast-shutdown (or similar) which will send processes that have been flagged as being ok with it a SIGKILL signal, shutting them down without chance for cleanup work. This is supposed to make shutdown faster. The default is that applications still get SIGTERM and have to opt-in for SIGKILL; and they can mark themselves as "dirty", i. e. having unsaved work and do not want to be killed forcibly.
So while shutting down in the middle of a disk utility run will abort whatever disk utility is doing, IMHO it would not cause data corruption in general. However depending on the operation you are currently running, you could end up with an incomplete disk image or a half-formatted partition. Maybe you want to refrain from using it when you know the end of your configured work time is coming close.
Using cron to schedule the shutdown is a viable option if you want it to happen at a specified time. If you want it to happen after a certain amount of time after you log in, you could use the number parameter to shutdown to specify say 8 hours from now.
If you want to lose unsaved work then shutdown -h is your only answer.
However, anyone who has debugged a full-screen app on OS X knows that is it very easy (some say too easy) for an app to capture the screen and render the computer essentially useless (without SSHing from another computer to kill the process.) That's another alternative.
the recommended way to schedule a shutdown of your computer on a regular basis is in the system preferences -> Energy Saver panel. Click on the "schedule" button in the lower right hand corner. the rest is self explanatory...
Forcing your computer to shut down (and discard any unsaved work) doesn't sound like a good idea to me. Wouldn't it be easier and safer to just set an alarm clock to remind yourself when you should stop working, and walk away from your computer when it rings? (That's what I do.)
Edit: That might have come across as a bit rude, which was not my intention at all. (I had no intention of making fun of your question or anything like that.) I just think that this would be a better solution to this problem :)
Maybe cron is installed on your computer? It's wonderful =)