applicationShouldTerminate: not called when system restarts - macos

I have to run some code when the app is about to terminate. applicationShouldTerminate: runs when quit is selected from the menu or when I press Cmd Q but not when I restart the mac.
Is there a way to force applicationShouldTerminate when a user tries to restart the mac? Or is it another function being called in this scenario?

Your app might have Sudden Termination enabled.
macOS 10.6 and later includes a mechanism that allows the system to log out or shut down more quickly by, whenever possible, killing applications instead of requesting that they quit themselves.
...
Debugging tip
You can determine the value of the sudden termination using the following LLDB command.
print (long)[[NSClassFromString(#"NSProcessInfo") processInfo] _suddenTerminationDisablingCount]

Related

Erlang wxWidgets app - Closing the beam.smp file once app finished

got a weird question which I haven't been able to find an answer to online so I'm trying my luck here.
I have a normal erlang application using wxWidgets, once I try to shut down my application I get the event that the wxServer has indeed entered the event which is connected to the window closing, I get a message that it is in the process of exiting, and my window does indeed close, but as shown in the picture below, the beam.smp on my toolbar doesn't close at all, I have to manually force the closing of the beam.smp file which sends a SIGTERM to the erlang terminal which also shuts down my erlang VM (which I have to reboot it later).
long story short, what am I missing on my close window event so that everything shuts down nicely without it crashing my erlang VM? I was able to read that wxWidgets behaves differently on macOS but I haven't been able to find how to correctly close the application.
handle_event(#wx{event = #wxClose{}},State = #state{frame = Frame,panel = Panel}) ->
io:format("Exiting~n"),
wxFrame:close(Frame),
wxFrame:destroy(Frame),
wx:destroy(),
{stop,normal,State};
You can close the emulator from code with init:stop/0,1
Also, if your application is started as permanent, it should suffice with terminating that application. Check the behaviour in erlang:application

Run a Applescript on a locked Mac by keypress or alternative options

I have an Applescript written for a specific purpose that launches an application and performs a couple of tasks. I would like to be able to run this script by pressing a key on my keyboard, however, while the Mac is locked. (Note: Mac is only locked, not "asleep")
I'm open to alternative options, if such (or more efficient) options exist.
The above scenario is my "ideal" configuration, the only thing I don't have flexibility on, is that the mac must stay locked for this process.
I have full administrative access to the Mac.
I would suggest you use ssh to "get into" your Mac while the screen is locked and then run your script from the shell. You would probably use osascript for that if it is Applescript, by the way.
In order to do this, you will need to ensure the sshd is running on your Mac by going to the Apple Menu, then System Preferences then Sharing and check the box beside Remote Login.
In order to ssh into your Mac, you could use another Mac, or a PC or the free iPhone/iPad app called Terminus which is brilliant for remotely controlling machines via ssh.
Rather than have to run a command when you log in, a technique which I often use is to have a user who can only execute a specific function and the very act of logging in does that function and then logs the user out again. So, for example, if I wanted a login that can reboot a machine, I would create a new user called reboot and instead of that user having bash in /etc/passwd as his shell, he would have /sbin/reboot as his shell. Just a thought - YMMV.
I've tried this same thing and when the Mac becomes locked, normal processing will not occur but slow to a crawl, so I had to turn my screens off instead of locking my Mac. There is no way around it.

How does Steam prompt me to delete game data when I delete the app?

I recently tried delete Steam.app from Mac OS X 10.10.5. As soon as I hit Command-Backspace to remove the application, this dialog appeared:
The text reads:
Steam still has some game content stored at /Users/apaidnerd/Application Support/Steam/SteamApps. Do you want to delete the game content as well?
[Leave files] [Reveal in Finder] [Delete files]
How did the Steam application cause this to happen? If I'm developing an app for Mac OS X, where is this documented?
You were close. It looks to me like the launch agent "com.valvesoftware.steamclean" is responsible for this. Unloading the "com.valvesoftware.steam.ipctool" agent/service may effectively disable the other one.
The steamclean agent's description plist file is in ~/Library/LaunchAgents. It doesn't poll. It has a WatchPaths key, which asks launchd to run it when that path changes. launchd uses file system notification techniques to monitor that, which also don't rely on polling.
When that happens, the agent runs the program ~/Library/Application Support/Steam/SteamApps/steamclean, which is not in the Steam.app bundle. It couldn't be, because the app bundle has been moved or renamed, so launchd would not be able to find the program for the agent. steamclean is what shows the dialog. You can confirm this by reproducing the dialog and leaving it open. Then, use Activity Monitor to list the processes and filter for "steam".
Figured it out. Steam has a launchctl agent that runs (com.valvesoftware.steam.ipctool) out of the /Applications/Steam.app/ directory. If I stop the daemon and remove the Steam.app, no dialog appears.
It must poll to see if its executable path still exists and prompts the user if goes missing. Also, the inactive-looking title bar implies that this dialog is indeed coming from some sort of background process.

Forgotten where I left an automatic shutdown script on Mac OSX

I let me Parallels Desktop running Windows XP to start automatically during mac log-in. And to start Windows upon launch to let my dad use his WinXP by just pressing the power button, bypassing the Mac login window and desktop completely. When he shuts down Windows, Parallels closes.
I seem to remember I have a trigger to shut down mac as soon as Parallels closes. But I don't remember where... I have an AppleScript that tells Finder to shut down. I understand that. But now the problem is Mac shuts down AS SOON AS it boots up every time! I can't figure out what's triggering the shutdown... And I've run out of places to look.
It seems like a normal shut down rather than a fatal error. Seems like someone has chosen the 'Shut Down' command as soon as Mac starts up. So could mac gurus suggest places I should look -- what might have triggered this -- I'm pretty sure it's Parallels-related. Maybe there is something in the Package Contents linked to the shutdown script??
You added the Applescript (that shut down the mac) to login items

Console windows that cannot be killed by closing or via Task Manager

When I run a test harness through the Visual Studio 2005 debugger, it creates a console window every time I run it.
In the past, the console window would close automatically when the test harness process terminated, but now I'm finding that the console window is hanging around afterwards.
After the test harness terminates:
I cannot close the console window by clicking the close (x) button on the top-right
The test harness process doesn't exist anymore in Task Manager
So I cannot seem to kill these console windows.
Does anyone know:
How these console windows can exist without a managing process?
How can I can kill these console windows?
Rebooting is obviously an option, but there must be another way.
It's a known bug in windows, introduced with KB978037 security patch.
You can find out more here
http://blogs.msdn.com/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx
and here
http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/e6d4a4f5-7002-401a-90e1-6174d7f9e3ca
In Windows, "Administrator" is not the highest level user. Some processes/files/directories are only accessible by the "SYSTEM" user.
See: http://hackspc.com/how-to-become-the-system-user-in-windows-xp/
This may be the reason why it is unkillable.

Resources