sleep from terminal

Probably not, as sleep depends on code external to the UNIX kernel.

AppleScript is your friend:

osascript -e 'tell application "Finder" to sleep'

This make not work if the user you're logged in as isn't logged into the GUI.

Darwinports has got a sleepnow package.

-Andre

Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel. Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics, external faulty code that the UNIX kernel cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

Looking at 'man launchd' and 'man init', launchd is used as the root process with PID = 1, and at the end of the boot process, it launches init, which would be the normal root process under BSD. The UNIX kernel (Mach under Mac OS X), does however itself not launch any programs or processes: only a process can launch another process. The kernel just keeps track of these processes, scheduling them, making sure they do not do anything illegal. So all processes end up on a parent-child tree, depending how processes (parents) launch other processes (children).

Then the UNIX kernel cannot go to sleep by itself. So Apple must have installed some other code, first called at boot. Probably launchd links the UNIX kernel to this other code at boot, though I do not see exactly how. But the result is not only the ability to go to sleep, but the inability to handle certain code, kernel panics.

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

osacript is a way of running AppleScripts in the shell,

and the flag -e says that the script to run is the bit in quotes. If you had saved a script, as scriptname then

osascript fullpathtoscriptname

would run the script.

That's Applescript's syntax:

Tell application.app
do this, that, and everything
end tell

Well, sort of. The OS X kernel is actually an odd combination of Mach code and kernel code borrowed from various BSD systems.

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX kernel extensions, as it affects reliability, for example.

The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.

For Mac OS X, it seems that one has added a mini-OS, by which the FreeBSD and its Mach kernel run within.

But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself. Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

Previously, ZnU wrote:

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

Come to think of it, my version of the instructions was

tell "System Events" to sleep

That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.

The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.

No, 'sleep' is a menu item in the Apple Menu, which is shared by all applications.

Huh? *No* code executes while the computer is sleeping. The CPU isn't even powered. And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

There *is* nothing in OS X which occurs outside of the *nix environment.

Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

Once again, there is no separate UNIX environment in OS X. OS X is a *nix operating system. All the Mac-like stuff runs *within* this environment.

It sounds logical. But there has something that brings it back to life. An interrupt of some kind.

And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

It can take minutes before the kernel is loading, though.

Previously, ZnU wrote:

There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs *on top* of this kernel.

So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads). So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Sure, but it's not part of the operating system, or any other software. It's a hardware feature.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

momentum:/ znu$ ls -l mach_kernel
-rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.

So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Mach *is* a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.

The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.

There's a decent high-level overview at:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

Previously, ZnU wrote:

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

momentum:/ znu$ ls -l mach_kernel
-rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

Yeah, this confused me for a while, too. I think he is thinking of some of the maintenance tasks early in startup.

The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.

If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.

The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.

There's a decent high-level overview at:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

Thanks for the link. But does not seem to address the kernel structure issue.

Thank you. So it is the PMU one should get rid of. :-)

When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.

Try:
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

Right, but they should load early on.

Previously, ZnU wrote:

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

That is better. As for kernel vs. microkernel, there is probably a considerable flux as how to term what is what; see:
http://en.wikipedia.org/wiki/Kernel_%28computer_science%29 http://en.wikipedia.org/wiki/Microkernel

Sure, daemons will typically load during the bit of the boot sequence where the progress bar is displayed. You can hold down command-v (which switches to verbose boot mode) to see some of this.