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
Received on Wed Jan 3 00:35:40 2007