>How about this.. >divert /etc/init.d/rc to use a mosix-run script instead of mosrun. This >can check /etc/default/mosix, and skip mosrun -h on an init.d script if >it has been set to migrate with say: >
How about modifying start-stop-daemon to have a default of stay, and ask it to made a policy requirement? That would also allow packages to provide some 'start-stop-daemon property' and conflict with each other when they all provide a modified version... >> So for a load balancing webserver config you could prepend "mosrun -l" >> to the server startup in /etc/init.d/apache. Am I wrong in thinking >> that this is a confile and the packagemanagement system won't stomp >> changes without asking? You're right on that. I wrote a few /etc/init.d scripts yesterday (figures my old luck is back...) and such entries "should" be treated as config files. Once again, that just might be a new entry for the policy (change 'should' to 'must') >Again, its not a good idea modifying files in /etc/init.d.. and to >prevent modification of files in /etc/init.d is exactly what we were >trying to achieve. As far as packages are concerned. In case of clusters, and in case of /etc/init.d modifications in general, the end-administrator will have the knowledge to play with that anyway. Point being, we might have to impose on the admin to select what daemons he wants migratable, and which does he NOT want. ---- Related, how do we deal with user-level processes? (Haven't looked deeply in MOSIX just yet) How is migratabilty handled for end-users? Christian Lavoie [EMAIL PROTECTED] [EMAIL PROTECTED] 0
