8

What happens behind the scenes when a user gives a Quit or Force Quit command from outside the target application (e.g. from Activity Monitor)?

3 Answers 3

11

As a general rule, the “Quit” operation is not a signal; it is an Apple Event, which is the same type of inter-process communication used for AppleScript scripting and for opening files or URLs in already-running applications, and comes from the Mac OS lineage rather than Unix.

A process has to specifically register to receive Apple Events, and such processes are either GUI processes or at least associated with a desktop session (which, outside of Activity Monitor, is the only way they can end up being told to quit at all).

However, if you “Quit” a process from Activity Monitor and that process has not registered to receive Apple Events, it will send SIGTERM (15) instead.

4
  • What's the benefit of apple events vs signals, for quitting apps?
    – Alexander
    May 30, 2020 at 0:39
  • 1
    @Alexander-ReinstateMonica Typical Mac applications will not register signal handlers, so if they are killed with a signal, no cleanup will be done, including prompting the user to save work (for applications that do not have full autosave) or confirm cancelling tasks in progress. (The quit event also permits the application to communicate that the user answered “Cancel” to such a prompt, which will immediately abort a logout/reboot/shutdown in progress, as distinct from the app simply failing to quit and possibly needing a force quit, which has to be a timeout.)
    – Kevin Reid
    May 30, 2020 at 3:21
  • Hey Kevin, thanks for reach back (on this 8 year old post!). Interesting, I'm curious why AppKit wouldn't implicitly add a handler for SIGTERM to do all that.
    – Alexander
    May 30, 2020 at 3:41
  • @Alexander-ReinstateMonica Interesting question, and it'd require some research to get a good answer; the design decision probably existed in NeXTSTEP as well as OS X even though Apple Events didn't. I suspect that it boils down to the presumption that (a) there's a lot of communication with the window system that a proper desktop app needs to participate in, and supporting only quitting is practically worthless, and (b) it's not particularly valuable to add the compatibility signal handler you propose. Personally I would have added such a handler, but it's not the system we have…
    – Kevin Reid
    May 30, 2020 at 4:22
7

You can use dtrace to see what signals are sent to processes:

sudo dtrace -n 'proc:::signal-send /pid/ { printf("%s -%d %d", execname, args[2], args[1]->pr_pid); }'

If you force quit an application that is shown in the Dock, the signal is usually -15 (TERM). But if you force quit a background process from Activity Monitor, it is usually -9 (KILL).

2
  • Interesting. How is the distinction made between apps and background processes? Sep 29, 2012 at 0:54
  • 1
    I didn't test it with that many processes, but I meant processes that don't have a menu bar or are not shown in the Dock or the force quit window.
    – Lri
    Sep 29, 2012 at 3:05
1

You can view Force Quit events for GUI applications sent to system.log. Or, use dtrace as posted in this thread. With dtrace you get more granularity but need root privileges.

4
  • -1 (inaccurate): /var/log/system.log doesn't record signals. Apr 27, 2013 at 17:10
  • 1
    @BlacklightShining Try launching TextEdit.app and Force Quitting it via Activity Monitor.app. You should see a line like this Apr 28 13:04:21 com.apple.launchd.peruser.501[136] ([0x0-0x3e13e1].com.apple.TextEdit[5336]): Exited: Terminated: 15 It doesn't register the Quit event though.
    – 1.61803
    Apr 28, 2013 at 11:15
  • 1
    Granted, this works for GUI apps. However, if you start some other process and signal it, it will not be logged. Thus you can't, in general, “view the signals sent” in system.log. Apr 28, 2013 at 11:29
  • 1
    @BlacklightShining I emended my post to reflect your comment.
    – 1.61803
    Apr 28, 2013 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .