Are you drunk? I mean
Did you consider that all processes need to be stopped in order to unmount any filesystems? Otherwise if you don't stop them, files be left open, the system won't be able to unmount, corrupt filesystem. The stopping of all the deamons give them a chance cleaning everything up, like committing pending transactions (for example writing entries to the logs). And not stopping netfs, are your high? I mean, what if I got some write data in my cache on the local computer? Don't you want it synced with the server? Why don't you just pull the plug... fastest shutdown I've ever seen. ctmlinux wrote: > Hello all, > > Just throwing something out there for discussion. I am wondering > perhaps if there would be a better restart and or shutdown method that > would prove faster. I don't tend to reboot any of my systems very often > but i tdid occur to me that although it is good to have certain daemons > starting after being called in /etc/rc.conf, it is not really necessary > from what I can tell to wait for them to stop upon shutdown or reboot. > For example: mpd, network, netfs, gdm (always gives errors saying it > can't find the pid anyway), dbus, hal, cron, cups, etc etc. I know this > would not make a massive difference in restart or shutdown times, but it > may help to optimize things in terms of speed on older machines or when > services hang at restart or shutdown. The only thing I can see as being > really important to do at shutdown or reboot is the unmounting of > filesystems, other than that, what else is really necessary. > > I took a look at the script /etc/rc.shutdown and from what I can > tell with my rudimentory skills at interpreting code of any kind, it > seems to call *anything at all* that was started within /etc/rc.d/ > > Thoughts? If I am way off in left field on this, please educate on > the reason. > > Thanks, > > CtM > > > ------------------------------------------------------------------------ > > _______________________________________________ > arch mailing list > [email protected] > http://www.archlinux.org/mailman/listinfo/arch _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
