On Tue, Jan 02, 2007 at 08:08:40PM +0100, Daniel Hokka Zakrisson wrote: > Herbert Poetzl wrote: > >On Tue, Jan 02, 2007 at 03:47:35AM +0100, Daniel Hokka Zakrisson wrote: > >>Herbert Poetzl wrote: > >>>On Mon, Jan 01, 2007 at 02:05:30PM +0100, william Famy wrote: > >>>>-----BEGIN PGP SIGNED MESSAGE----- > >>>>Hash: SHA1 > >>>> > >>>>To begin with Happy new year to every vserver guy. > >>>and a happy new year to you too ... > >>> > >>>>I have to extand the shmmax for my guest but I do not manage to do it. > >>>> > >>>>cat /proc/sys/kernel/shmmax > >>>>134217728 > >>>>I have tried the /etc/vserver/host/rlimits > >>>>I have tried to add bcapability > >>>>but I do not manage to go ahead with it. > >>>> > >>>>I've run under 2.6.19.1 with the last devel vserver patch under > >>>>debian etch as host. > >>>> > >>>>Could somebody tell me how to modify the guest config to execute > >>>>"echo 134217728 /proc/sys/kernel/shmmax " for my guest. > > > >>>as 2.6.19.x incorporates the mainline namespace > >>>stuff, you have to set those values from one of > >>>the early guest startup script (e.g. prepre-start) > >>>while you still have 'enough' capabilities ... > > > >>I assume this requires the IPC namespace to be created? > >>That doesn't happen until the context is created, so none of > >>the scripts would work for this particular problem. > > > >hmm, isn't the context supposed to exist in > >the post-start script? if not, please could > >you once and for all clarify which script is > >started when and in what context(s)? > > The context will exist in the post-start scripts, but they won't be run > inside the context, and the context will already have lost the extra > capabilities.
ah, but that script could actually 'enter' the context with capabilities still intact and do whatever manipulation necessary ... (but sounds too complicated) > >>Having a non-executable one that does something like > >>VSERVER_EXTRA_CMDS=( $_CHAINECHO /proc/sys/kernel/shmmax 134217728 ) > >>is probably the only way to make it happen (with current tools). > > > >okay, any plans to allow for such support? > > > >>>also using the sysctl interface instead of the > >>>deprecated procfs one (which might as well be > >>>hidden away :) is advised ... > >>> > >>>maybe special tool support will be added soon, > >>>so please double check with the tool maintainers > >>I guess some nicer way to support it would be required, > >>especially as more of these settings become available. > > > >what do you have in mind ... please share > >your thoughts, as I think those settings _might_ > >become essential for certain setups ... > > I guess something like /etc/vservers/<guest>/sysctl/<id>/{setting,value} > shouldn't be a problem, should it? sounds good to me, TIA, Herbert > >>>>Thanks for any help. > > -- > Daniel Hokka Zakrisson > GPG id: 06723412 > GPG fingerprint: A455 4DF3 990A 431F FECA 7947 6136 DDA2 0672 3412 > _______________________________________________ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver