Bernhard Auzinger posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 09 Feb 2006 20:09:41 +0100:
> It's funny, Duncan. On the one side you are saving every byte of > cpu-cache. On the other side, you are happy by having forked bashes in > your main memory. But how do you take control about that? I mean, how do > you get the code of your forked bashes away from your cpu cache to have > it free for kernel code? Actually, not all of them fork. I hadn't mentioned it, but most of the single-liners use "exec", so fork the single-line bash script off of my invoking session (so it doesn't close when the command is finished) when I initiate it, then use that same bash script process to run whatever the bash script calls. Similarly, because I initiate X/KDE from the command line rather than using kdm/xdm/whatever, I'd normally have the initiating VC bash instance hanging around, but run a script that starts X/KDE in the background, sleeps for 30 seconds, then disowns everything and exits. (I do it this way rather than executing a forkless exec, for troubleshooting purposes, in case X can't start, and because at some point, I discovered that if the session didn't stick around for a bit, X would stop with it, regardless of the disown.) Likewise, when I sudo from my restricted normal user to my "admin user" (which isn't root, but has unrestricted sudo abilities) I source a script (thereby running the script in my existing user bash process) that execs the sudo, such that I end up without any stacked idle processes taking up resources behind my admin session. When the admin session exits, it either logs me out entirely (at a VC) or closes that konsole tab (if I'm in X and using konsole). That brings up an entirely different layer I have as well. In addition to /l/bin (also available in the traditional /usr/local/bin location, courtesy of a symlink) and /l/sbin, I have /l/sudobin, which contains stub-scripts for most of the ea* and similar root-required scriptlets (naturally ep* doesn't require that, as emerge --pretend doesn't require root), that simply exec sudo their /l/sbin counterparts. That way, for commonly issued emerge and other admin commands, I don't have to directly sudo them from the admin user, only invoke them as I would directly as root. At the same time, I retain protection against an errant rm -rf .* or the like (keeping in mind the consequences of such, due to the .. parent dir entry) as the admin user, and while sudo rm -rf .* would certainly do it, I know that every time I stick sudo in front, as the book "Running Linux" advises, "Sit on your hands a moment and make *VERY* sure the command is what you /think/ it is, and will do what you /expect/ it to and no more, before you hit that enter key." Naturally, these stub-scripts use the source command or exec as well, the result being that sometimes there's a /whole/ /series/ of separate commands operating serially as the same system process, no forking. Of course, Linux' COW (copy on write) memory management scheme ensures that the bash instruction code would remain shared anyway, as Kevin Quinn mentions, but there's still the unique session data to contend with, and in any case, I don't like seeing those stacked processes that are of no further use, hanging around in top/ps/ksysguard/etc, so where possible I eliminate them. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
