How to force quit everything in one go ?
 

How can I force quit everything ? A quick simple way to get apps closed and free some memory .. I was in terminal with top and knocked something off that force quit everything,, BUt i think it was a bug,, anyway, I would love it as an app instead if anyone knows of such ..

Not a good idea, sending a kill -9 to an app will prevent the app from nicely asking whether you want to save that document which is still open.

Instead, [option]-tab through the running programs and [option]-q those you no longer want, nice and fast method.

You probably did something really unfriendly such as

sudo kill -9 0

which kills the kernel task, at which point, out of solidarity, all its child processes die a horrible death and the system stops altogether.
Really don't do that at home, trust me...

Force-quitting an application should ONLY be done when there's a problem with the application itself. Killing/force-quitting doesn't allow the application to do any cleanup it might be programmed to do (without the source, you don't know WHAT it's programmed to do), doesn't close files properly, etc.

eh, all is still final and well I rather save docs constantly anyways..

I did kill 1182 which said it was a tar file since I had three tiny files trying to unzip for two minutes and knocking off finder does nothing.. So I did that and it kicked EVRYTHINg.. but this is something I always wanted before anyway..

That and dashboard in the command tab switcher..

1. You probably killed loginwindow by accident. That's bad, unless loginwindow was having problems that required a kill signal.

2. It's not about "saving constantly". You have no idea what the program needs to do when it quits, because you cannot see the source code.

When an application quits, there is more than just "quit". It posts notifications to the system and the application's delegate checks a few notifications that get posted inside the application. When you force quit something or "kill" it, those notifications are not posted. The application is dumped violently from memory.

Do. Not. Force. Quit. Applications. Unless. You. Cannot. Quit. Them. Normally.

If you don't believe me, go read the documentation for the NSApplication class and check out -applicationShouldTerminate: and other related delegate methods. The "quitting" of an application is more complex than you seem to think.

You should stop using the kill command until you understand the full implications of doing so.

This approach has two flaws.

If one of the quit tasks of an application is to release memory, and you force-quit, you might bypass the normal memory release procedure, leaving memory in a weird state, thereby defeating your own purpose.

The OS manages memory as efficiently as it can. Most user attempts to manually "reclaim" memory are shortsighted and aren't taking all of the variables into account, such as caching for performance. It's like if you decide the ketchup bottle is cluttering up the picnic table so you put it back in the ice chest. Now you have several people angry with you because you didn't realize that other people are still putting their burgers together.

Just to set the record straight:

1. What does the ketchup bottle in the ice chest to begin with ;) ?
2. If a process dies, for whatever reason, the kernel cleans up after it and frees all the memory ever allocated to that process. The app just doesn't get a chance to clean out temp files, ask for docs to save etc.

So force quitting is still a bad idea, but for other reasons.
Often applications leak memory (Safari is sadly famous for this, even though they made some progress). Quitting, then relaunchig such leaky apps helps quite a bit.

It's easy enough to write an AppleScript applet that simply quits all visible user processes.

That shouldn't hurt too much.

In fact, here's the code:

There is already an OS X menu item that closes all apps--two of them, in fact:

Log Out
Shut Down

They both free up your memory too!

Seriously, trip dragon, not only is your idea a bad one, but the reason you put forth to do it is a bad one. There is no need to "free some memory." In a modern OS like this, the OS handles memory management. There is no reason to think that you need to take any action on your own to manage memory. That's old school thinking that's not applicable any more.

Chris

Is it really that bad? I know a guy who, having discovered that force quitting apps in OS X does not crash the whole system like it often used to in OS 9, now does it all the time. Even when apps are running normally, he'll force quit them because he's too lazy to quit them normally (personally I think that'd be easier, but anyway). I did try to tell him not to do it, but I guess I wasn't terribly convincing, mainly because I wasn't really sure if it was a bad thing to do. He hasn't had any trouble so far.

I disagree.

If the issue were quitting all active user processes, then sure it would be a bad thing. But quitting visible apps every once in awhile is a good thing. (And note that the script that I posted only quits visible apps.)

I've recently seen Safari and the Finder gobble up memory (on separate occasions) for no good reason. Quitting the apps freed up the memory and set them to behaving well again.

And there are other reasons to quit user apps.

Adobe and MS apps often act weird after saving and opening a lot of files.

The Finder has been known to unepectedly push CPUs to 100%.

Whatever's going wrong, quitting and relaunching often fixes it.

And what if you're one of those users who never quits any programs? Over the course of a few days' use, you might have a heck of a lot of apps open.

Having a quick way to quit them (and thence to clean up your Dock and <Command>+<Tab> app switcher) without going through the trouble of logging out and logging in again might be useful.

[Edit]
I want to make it clear that I am advocating "quitting" and not "killing" or "force quitting."

Yes! It's really that bad.

I had a friend like yours. It was on my fourth visit to fix her drive when she revealed to me that she had been force-quitting apps instead of <Command>+Q. I went ballistic on her. I don't get how otherwise intelligent people can be that stupid.

I think Apple needs to have a big red STOP icon and a warning when people use the 3-finger solute.

It can do damage. Don't do it casually.

The script that I posted sends a Quit command instead of force-quitting or killing. It's nearly as fast and it's MUCH safer than killing the app.

The rule I live by is pretty simple, if I need to use an app again soon, I don't quit it. If I'm not going to use it again soon, I quit it. That's it.

There's no point in quitting an app you'll need again soon if your only aim is to free ram, because if you're going to work on the same docs again soon you'll merely repeat the request for the same ram amount soon and you'll be back where you started. I could see quitting an app after working on huge docs and then working on small docs. It definitely makes sense to quit apps you won't use for a while, so that their ram requests are no longer a priority.

Usually, the most pointless act is to restart the Mac to "regain" ram, because you throw out all the caching that speeds up app and doc relaunches. You slow down your machine, basically.

Of course, you can do force quits and restarts if there is a real problem or you can force quit when an app is not responding at all, but in normal use, you should continue running apps you need to keep using and quit apps you aren't going to use for a while.

I'm seriously not making this stuff up. :)

Your friend does not understand much about computers, from the sound of it. These kinds of users are detriments to the user base, because their technological ignorance bleeds out into the pool of users who also don't know what's going on. (This is not an insult. It sounds like one, but it is not.)

"He hasn't had any trouble so far." SO FAR. Have you ever wondered why people have problems and complain on message boards every time Apple releases a system update? This is one of the big reasons, people doing stupid crap and saying, "Well, I don't have any problems." He simply doesn't know if there is a problem beneath the surface that isn't causing problems right now.

Force-quitting is a violent memory dump. Applications have steps they go through when they quit, and without access to the source code, you have no way to know exactly what those steps are supposed to be. When you use an application's "quit" command, more than "quit" happens. Here is a simplified run-down (no pun intended):

1. Application is sent the -terminate: message.

2. If the -applicationShouldTerminateAfterLastWindowClosed: delegate method is implemented, it is executed and checked for its return value. If it returns NO, the application does not quit. There is typically a good reason for returning NO if it happens. If this method returns YES, we invoke the -applicationShouldTerminate: method.

3. Now we're at -applicationShouldTerminate:. This is where developers tend to put pre-quit clean-up code. Like before, if it returns NO, then the application is told not to quit. If it's returning NO, there's a good reason.

3. If -applicationShouldTerminate: returns YES, -applicationWillTerminate: is invoked from within the -terminate: method. The -terminate: method then sees that -applicationShouldTerminate: has returned YES and NSApplicationWillTerminateNotification is posted to the default notification center in -applicationWillTerminate:.

All this stuff happens when you tell a program to quit normally, before it actually vanishes from the Dock. There's more stuff that happens behind the scenes, but this gives you a general idea of how complex the quit process actually is.

An example of other behind-the-scenes stuff that happens would be the user defaults (a.k.a. preferences) system. When an application quits normally, the user defaults environment is synchronized; preferences values are written permanently to disk. A developer can make his or her program synchronize manually before quit, but it always happens at quit whether the developer does this or not. If you force quit an application, the automatic synchronization doesn't get a chance to happen.

"Kill" is for applications having problems. Otherwise, quit normally.

How lazy can you get?? If you've finished using one application and don't intend using it for some time, quitting it normally should be an automatic reaction, if not, it simply clutters up the doc and the desktop (sound like your Mom?). "Killing" it if it has no problems like stalling, is like using a hand-grenade to kill a fly!

Here is a great way to politely quit several apps at once. Press Command-Tab as if you are application switching, but as you pass each app you want to quit, without releasing Command, releast Tab and press Q. Then without releasing Command, release Q and press Tab again to move to next icon. It should only take one pass through the icons to quit whatever you want. (H hides, too.)

I have a gig of RAM in my MacBook Pro. If I don't know if I will need to use an app in the next couple of hours, I leave it running. Leaving Transmit or BBEdit open doesn't exactly drag me down. (Even when I had my G4/500.)

Try running (and using) Safari (or another app that leaks memory like there was no tomorrow) for a couple of days...

Now that the reasons not to have been thoroughly flogged, some thoughts on how to do it properly.

(first off, command-tab/command-Q is probably faster than running an app)

There are several ways to halt an application. Applescript `tell` and Terminal `kill` are well known. `kill` has several signals, some of which are safe to use. Force Quit sends SIGKILL to the process, instantly halting it. SIGTERM is much nicer. (Anyone familiar with the Applescript mechanics?) So looping through all processes with your user name and using kill -15 (SIGTERM) should let you have it both ways.

Something like :
ps -acxu | grep username | grep -v Finder | grep -v loginWindow | awk '{ print $2 }' | xargs kill -15

is a start. Filtering out background processes is your problem, and expect to have to reboot repeatedly while you test it.

I run a background application on my server that watches Filemaker and restarts it if it crashes. It also shuts it down at a certain time by sending staged quit commands. First AppleScript "tell application Filemaker Pro to
quit", if that doesn't work it gets the pid and sends kill -15, and if that doesn't work sends kill -9. If that doesn't work it reboots. I don't have a USB power relay yet :D

My rationale here is that the App should be restarted daily, and if it doesn't respond to the Applescript it should respond to a kill -15. IF there is no response to those signals, THEN I'll take it out with the 12-gauge because it's already crashed. If it's like T2 and survives the shotgun it gets nuked with a reboot. But I don't pull out the big artillery before diplomacy has had a chance to work.

To get a better appreciation of the various signals, try using the Perl script that I supplied in this old thread:
http://forums.macosxhints.com/showth...4302#post64302

AppleScript uses a completely different mechanism involving the sending of AppleEvents to the application. See: http://developer.apple.com/documenta...section_4.html

Enable the "Quit" menu in "Finder", then quit it first. After that, Cmd-Tab to bring up the app switcher, then without releasing the Cmd key, just holding down "Q" automatically cycles through and quits the remaining programmes, assuming there aren't any unsaved changes in any of them.

I'm not sure if there are benefits to quitting all apps over logging out. On the other hand, with respect to quitting specific programmes, my experience agrees with those who recommend quitting Safari (and by extension, other leaky apps). On a marginal system with low RAM and hard drive space, running Safari, as opposed to Opera, would usually leave the system with at least one more swap file. Quitting Safari and Finder would result in the almost immediate recovery of the disk space for one, sometimes two swap files, after which things speed up noticeably. I suppose the problem might not be a big deal on a system with plenty of RAM...

I'm confused. Are you advocating kill signals for non-stuck GUI apps? That's a big no-no.

Just trying to sort out your post.

Semantically, these are the same thing. You end up quitting everything under your control that isn't detached from a controlling terminal/tty when you log out. (Processes run through screen, for example, stick around through log outs.)

People complain about Safari leaking, but I have to say that I've not seen it as severe as everyone yells about. (We leave it running on machines at work for weeks at a time.) However, it does leak to some extent, so I typically recommend Camino over it. Seems to be better in that respect, and remains faster than Safari over time.

I use Camino as my principal browser all the time :) but i've kept safari on the dock for websites that use any sort of flash/animation as camino doesn't seem to support them. (unless i'm in the dark on this one? Is there a setting or mod download for camino to make it fully flash compliant?)

No Flash issues here with Camino (1.0.1 release version, not a nightly build) on two machines. (One with Flash 7/PPC and one with Flash 8/Intel.) I've not modded anything at all.

If you're having an issue, you might want to post a thread about it in Help Requests.

aha, the fact that i'm still on 0.8.4 might have something to do with it, maybe i'll upgrade soon...thanks mikey-san

I wasn't suggesting you were. I was just trying to work this out, for his sake and for mine. After all, when his computer goes down I'm probably the one who'll have to fix it. :p Thanks for the info.

I think ReStart should be the short answer to to the original question. It would safely quit all the applications and release any memory they were using.

Pull the power plug. Don't laugh. It's as smart as what you're trying to do.

Chris

I remember some of these terms scrolling up the screen on my old laptop running Ubuntu.

Something like:

--SYSTEM IS HALTING NOW!--
Setting runlevel to 0...
Sending SIGTERM to all processes...
Closing <something>
Closing <something>
... <other stuff>
Sending SIGKILL to all processes...
Power down...

I could easily make something like this, but I'm not sure how to get a PID of a process using 'do shell script'...


From the Apple Developer Guidelines: "Avoid relying on a restart to get rid of cached or temporary files that may use up disk space. Be prepared to remove these files yourself when they are no longer needed."

http://developer.apple.com/documenta...section_2.html

ASIDE: Greatest gadgets since sliced bread, fully scriptable too! :)

Untrue.
Pulling the power plug is much worse since it abruptly stops the OS as well as the applications. Since the OS keeps files buffered in RAM and only writes them to disk when convenient, a sudden power loss brings the possibility of filesystem corruption. That's much worse than merely losing some changes when an app didn't get time to save a dirty document.

[/cynicism?]

Good point.

A decently written app, GUI or not, should trap and properly process SIGTERM. But I ask with the AppleScript first. It might have a dialog up on the screen and not respond to the AppleScript so I then use SIGTERM/SIGKILL/reboot with a short wait in between. As my particular case involves a headless server I don't see too many other options, and this one doesn't have too many problems.

About the power plug - FileMaker once posted in their documentation that one way to recover from an accidental "Delete All Records" command (which is not undo-able) is to yank the plug before the program flushes to disk. As the flush cycle was only 4 seconds long you really didn't have time for a software solution. Don't have a link right now, but they did say this was a last-ditch, somewhat unreliable effort.

This technique worked in System 7 to OS 9 only if done immediately after emptying the trash or doing some other destructive task. It exploited the fact that the older OS's didn't immediately flush the drive cache. It also introduced a great risk of damaging the directories, open files and/or the OS itself. This will likely not work in OS X.