Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Load and unload kernel extensions without restarting System

To me, an installer's request that I please close everything and reboot is like my office supply store saying "Please clear everything off your desk to use your new legal pad." However, it turns out that it is possible to avoid reboots even after installing new kernel extensions! (I'll leave higher-level cop-outs, like manually launching startup items, as an exercise to the reader.)

As with any process requiring root privileges, there's plenty of room to hose your system to the point of needing a forced reboot (or maybe worse if you're creative), so use discretion, keep backups, and don't blame me. If you know what you're doing, though, this can save you a lot of reboots.

By way of example, I'll use my recent upgrade from v2.1 to v3.1 of the MS IntelliPoint driver:

  1. Save all your open stuff in case you blow your machine away.

  2. Quit any programs that are likely to be using the old version of the kernel extension. For instance, I used ProcessViewer and the kill command to quit MicrosoftMouseHelper.

  3. Become the root user, and unload the old kernel extension. If you don't have the root account enabled, you probably shouldn't be trying this anyway.
     % su
    % kextunload MicrosoftMouse.kext/
  4. Run the MS IntelliPoint installer (or the installer you're dealing with).

  5. Load the new version of the kernel extension which the installer just plopped into your /System -> Library -> Extensions folder:
     % kextload MicrosoftMouse.kext/
  6. Don't reboot! Enjoy your new extension! :-)
[Editor's note: I'm fairly wimpy when it comes to reboots; if an installer wants me to, I do. But if you'd like to try an upgrade without a reboot, you'll need to use this technique.]
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)

Load and unload kernel extensions without restarting | 7 comments | Create New Account
Click here to return to the 'Load and unload kernel extensions without restarting' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Interesting, but...
Authored by: Krioni on Oct 25, '02 12:24:40PM

Interesting, but what if the installer does a Quit-All before it runs? Does anyone have a hint on the best way to block that? I'm guessing it sends an Apple Event to Quit to every app, but maybe there's more.

I don't load kernel extensions much, but I've seen plenty of poorly-configured installers that want to quit the 15+ apps I've got busy doing other things.

[ Reply to This | # ]
Interesting, but...
Authored by: DavidRavenMoon on Oct 25, '02 08:53:38PM
It's safer to quit apps because some might be writing to files the installer needs to modify, or you might have open files in general.

Also I just don't get what's the big deal about rebooting. It's a computer, not an uptime contest. People don't leave their TV or stereo on when they aren't using it, and unless your computer is a file server, there's no point in leaving it on. The 40 seconds my G4 takes to boot is not a big deal.

[ Reply to This | # ]

Interesting, but...
Authored by: aaronfaby on Oct 26, '02 01:19:58AM

Actually, shutting down all programs may have been a good thing to do with OS 9, however it's not even necessary with OS X. The only exception would be if you are upgrading an app that is already running, you would quit that particular application, not all apps. Unless the installer is updating frameworks or shared libraries, there are no conflicts.

It's just inconvenient when I have all my applications that I frequently use open, and the installer says I have to shut them all down. Then waste a few minutes rebooting when it's not even necessary, or even any safer.

[ Reply to This | # ]
My use for dynamic extensions
Authored by: wfolta on Oct 25, '02 12:52:13PM

In 10.0.X and 10.1.X I encountered a problem using Final Cut Pro where the Firewire driver would get screwed up and I couldn't get video out of the machine. This is my recipe for fixing it:

1. Turn off all Firewire DV devices attached. Wait 10 seconds or so.

2. In the Terminal:

sudo kmodunload -v -n

Should see something like:

kmodunload: found kmod, id 62.
kmodunload: kmod id 62 successfully stopped.
kmodunload: kmod id 62 successfully unloaded.

If you see something like this:

kmodunload: found kmod, id 91.
kmodunload: kmod_control(stop) failed: (null)

the VTR isn't turned off.

3. Turn the Firewire DV devices back on, which should reload the driver. You can check with:

sudo kmodstat | grep FireWireDV

where you should see an entry for the Firewire DV device.

This may not be necessary any more, but it illustrates the point. Note that you can't unload an extension that's in use. That's why, in my example, you had to turn off all Firewire devices first.

[ Reply to This | # ]
For those in Jaguar
Authored by: SJT on Oct 25, '02 06:58:26PM

For those in jaguar the commands are:

kextload(8) - loads, validates, and generates symbols for a kernel extension (kext)
kextstat(8) - display status of dynamically loaded kernel extensions
kextunload(8) - terminates objects and unloads code associated with a kernel extension

[ Reply to This | # ]
Interesting but two quibbles
Authored by: babbage on Oct 25, '02 06:51:34PM
  1. I have yet to hear a convincing argument in favor of enabling the root account on an OSX box [or for that matter on any other *nix where you have sudo available]. It is *far* better to issue commands that require escalated priviliges with the sudo command rather than mucking around with no safety net in a root shell. Sudo is smart enough to generate an audit log of everything you do, and while this can be attacked in various ways, it's a hell of a lot better than not having it at all. So, please please don't encourage anyone to enable root frivolously -- all the steps of this hint should be doable exactly the same way by just prefixing them all with sudo.
  2. There are a lot of annoying installers out there, but please be aware that you're getting into intimate juju when messing with hot-swapping of kernel extensions. The microkernel design of Mach/Darwin does make it possible to do this safely, but it's a pretty cutting edge thing for a system to do, and you could end up seeing problems with some software. This isn't to say that it can't be done safely (cf. also BeOS & the way it allowed you to restart the various sytem server processes, so you could change video & network settings on the fly without rebooting), but it really is a good habit to do a reboot after such system modifications. If you want to use this hack to avoid an immediate reboot, that's fine, but if you're just trying to show off your impressive uptime figures, get over it. It's probably safer to use this as a tactic for delaying reboots, not avoiding them. Even the OS of the Future needs to sleep once in a while :-)

[ Reply to This | # ]
Re: Interesting but two quibbles
Authored by: thornrag on Feb 27, '04 11:47:02AM

It's only "cutting edge" to the Mac crowd. On many Unix and Linux systems, nothing short of an actual modification to the kernel itself -- a recompiled kernel binary -- requires a reboot.

Of course, it's true that a middle manager with an iBook doesn't need to maximize the uptime, but it does hurt to wipe away 100 days or more of uptime just because a cocky or sloppy installer didn't finish the job. The situation might be slightly elevated on a production server, in which case hopefully you have all your kernel modules installed before going online. But even if it's not...

There's just no reason to require a reboot for the installation of new software. Only incomplete installers and misguided developers make the mistake of requiring users to reboot. HP's printer drivers for the mac are the worst, quitting all your applications and then requiring a restart. There's nothing that it does that requires this. In fact it should be prohibited somehow that any one application could be allowed to quit all your other running applications. Why doesn't this scare the bejeezus out of anyone? How draconian is that? That's from the dark ages, people.

For the *real* cutting edge, we need to be screaming at developers who force us to put up with this, not baby hand-holding users who will reboot their computers "for good measure" anyway. It'll take time and pressure, but our Macs simply do not need to be rebooted for the sake of any installer.

And if there's no way around it, we need to be demanding better. If printer drivers don't work unless the printer is connected when the system starts up, that is a crappy HP printer, and we need to demand better.

Come on, people... the Mac's cutting edge is what liberates us from oppressive installers! End the cycle of blithe complacency!

I call on everyone who digs into this buried year-old thread to RISE UP!!!!

[ Reply to This | # ]