I think you'd just want to rename the files from S##whatever to K##whatever. That will cause init to stop those services if you change from a runlevel that had them enabled, rather than leaving the state the same.
What I did for an embedded HAL system was to turn runlevel 2 back into a non-GUI, multiuser runlevel (like it is on most non-Debian systems). I made runlevel 3 be the GUI level (again, like most non-Debian systems). This way, I can go from embedded with few services (I still need networking because I have to ssh into it for admin tasks) to full-blown GUI and back by issuing `init 3` or `init 2` commands. You should be able to do the same thing for switching between network/non-network runlevels, though I think the long list of loaded kernel modules isn't as easy to change that way. (I believe that some modules get loaded when the hardware is detected, not necessarily when some init script decides it wants to enable/use the device) A couple more thoughts on the subject: 1) It seems that network traffic causes pretty severe delays. In this context, severe means ~10 microseconds. I could see this on a system that regularly has sub-microsecond latency, but when I'm connected remotely and running something like halscope, I see big spikes quite often (multiple times per second). 2) There is a several microsecond spike every 5 seconds or so from kjournald - the ext3 journaling daemon. If you use ext2 instead, this goes away. The tradeoff there is that you no longer have a journalled filesystem, so you'd want to think about it before doing that :) - Steve Mark Wendt (Contractor) wrote: >Yep, one of the tricks I learned many, many moons ago as a budding >Unix sysadmin. That way, you keep the startup or kill files >(usually, they're soft links to the real files in the /etc/init.d >directory) in the same directory as they were originally intended to >reside, if you ever decide you want to start using them again. > >Mark >[snip] > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
