Re: [Vserver] Host with 2 NICs
Thanks for your very fast response, Herbert. I tried what you suggested but it doesn't seem to make any difference. Btw, your approach seems to indicate that I need a static IP? Or at least that I update my firewall rules when my IP changes? On 9/4/05, Herbert Poetzl [EMAIL PROTECTED] wrote: your problem is that the guest send packets with a source IP in the private range, but the host does not SNAT them to the public IP (and masquerading does not apply to host generated packets) verify that with 'tcpdump -vvnei eth1 icmp' on the host and a 'ping -c 1 66.249.93.99' inside the guest you can fix that with an SNAT rule like this: iptables -t nat -I POSTROUTING -s A.B.C.1 -j SNAT --to X.Y.Z.W gargoyle vservers # tcpdump -vvnei eth1 icmp tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes 23:13:39.940738 xx:xx:xx:xx:xx:xx yy:yy:yy:yy:yy:yy, ethertype IPv4 (0x0800), length 98: IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) A.B.C.2 66.249.93.99: icmp 64: echo request seq 1 I get the exact same output (except for the timestamp) after adding the iptables rule. Did I do something wrong? Thanks, Hilco ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] [patch] fix sched on amd64
The attached patch fixes a bug when you use vsched on a running
vserver on amd64, in which the high 32 bits of various scheduling
parameters could be filled with garbage, causing tokens to be allocated
at vastly incorrect rates.
Patch is against -vs2.0
diff -ur linux-2.6.12.5-vs2.0.orig/include/linux/vserver/sched_def.h linux-2.6.12.5-vs2.0/include/linux/vserver/sched_def.h
--- linux-2.6.12.5-vs2.0.orig/include/linux/vserver/sched_def.h 2005-09-05 19:05:11.0 +1200
+++ linux-2.6.12.5-vs2.0/include/linux/vserver/sched_def.h 2005-09-05 19:03:11.0 +1200
@@ -21,10 +21,10 @@
atomic_t tokens; /* number of CPU tokens */
spinlock_t tokens_lock; /* lock for token bucket */
- int fill_rate; /* Fill rate: add X tokens... */
- int interval; /* Divisor: per Y jiffies */
- int tokens_min; /* Limit: minimum for unhold */
- int tokens_max; /* Limit: no more than N tokens */
+ uint32_t fill_rate; /* Fill rate: add X tokens... */
+ uint32_t interval; /* Divisor: per Y jiffies */
+ uint32_t tokens_min; /* Limit: minimum for unhold */
+ uint32_t tokens_max; /* Limit: no more than N tokens */
uint32_t jiffies; /* last time accounted */
int priority_bias; /* bias offset for priority */
diff -ur linux-2.6.12.5-vs2.0.orig/kernel/vserver/sched.c linux-2.6.12.5-vs2.0/kernel/vserver/sched.c
--- linux-2.6.12.5-vs2.0.orig/kernel/vserver/sched.c 2005-09-05 19:05:11.0 +1200
+++ linux-2.6.12.5-vs2.0/kernel/vserver/sched.c 2005-09-05 18:03:45.0 +1200
@@ -30,7 +30,7 @@
*/
int vx_tokens_recalc(struct vx_info *vxi)
{
- long delta, tokens = 0;
+ uint32_t delta, tokens = 0;
if (vx_info_flags(vxi, VXF_SCHED_PAUSE, 0))
/* we are paused */
signature.asc
Description: This is a digitally signed message part
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] readonly bind mount
I mean, I can write -o ro mounted dirs!. Why? because the mainline kernel folks are lazy and Al Viro considers this a feature instead of a bug :) Thanks and I understand why. But, if so, something like this could happen, even with your BME patch. [Host] # mount -o bind,ro /etc /vserver/103/etc [Host] # vserver 103 start [103] # cat /etc/shadow you can see shadowed passes from vserver. I think a root under vserver should be like this: 1. for files under /vserver/103/* - same as real root. 2. for files bind-mounted from host / - same as normal user. your opinion is? --- Okajima, Jun. Tokyo, Japan. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] build -m rpm does not work
I tried with ready-made deb on sid, got from apt-line and same problem happened. maybe it is worse ... because vhasify binary seems not to be included. --- Okajima. Hello. I installed util-vserver-0.30.208 from tar ball and succeeded to compile it on my Debian Sarge box. And vserver start/enter and build -m debootsrap work. But, build -m rpm and vhashify does not work. Any help? Note: I dont have dietlibc and beecrypt problems which current sid has. BTW, I found that distrib/* know what is essential for each distribution. I want to know the basis of them. I mean, for example, distrib/suse91 shows aaa_base.rpm is only file to be essential, but what docs from SuSE say so? and in rh91 and fedoras? How you know which rpms are essential? --- Okajima, Jun. Tokyo, Japan. - [EMAIL PROTECTED]:/# vserver 101 build -m apt-rpm --force -- -d fc1 Renamed '/usr/local/etc/vservers/.defaults/vdirbase/101' to '/usr/local/etc/vservers/.defaults/vdirbase/101.~1125899538~' Renamed '/usr/local/etc/vservers/101' to '/usr/local/etc/vservers/101.~1125899538~' Renamed '/usr/local/etc/vservers/.defaults/vdirbase/.pkg/101' to '/usr/local/etc/vservers/.defaults/vdirbase/.pkg/101.~1125899538~' No dynamically linked rpm binary found; exiting... rm -rf /usr/local/etc/vservers/.defaults/vdirbase/101 /usr/local/etc/vservers/101 /usr/local/etc/vservers/.defaults/vdirbase/.pkg/101 [EMAIL PROTECTED]:/# vserver 102 hashify 'vserver ... suexec' is supported for running vservers only; aborting... failed to determine configfiles [EMAIL PROTECTED]:/# uname -a Linux Debian 2.6.12.4-vs2.0 #1 Sun Sep 4 05:55:19 UTC 2005 i686 GNU/Linux [EMAIL PROTECTED]:~# ldd /usr/local/lib/util-vserver/rpm-fake-resolver not a dynamic executable [EMAIL PROTECTED]:~# find /usr/local/lib/util-vserver/ | grep rpm /usr/local/lib/util-vserver/vserver-build.apt-rpm /usr/local/lib/util-vserver/vserver-build.rpm /usr/local/lib/util-vserver/vserver-build.functions.rpm /usr/local/lib/util-vserver/rpm-fake.so /usr/local/lib/util-vserver/legacy/parserpmdump /usr/local/lib/util-vserver/rpm-fake-resolver /usr/local/lib/util-vserver/vrpm-worker /usr/local/lib/util-vserver/vrpm-preload /usr/local/lib/util-vserver/distributions/defaults/rpm /usr/local/lib/util-vserver/distributions/defaults/rpm/macros /usr/local/lib/util-vserver/distributions/rh9/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc1/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc2/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc3/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc3/rpmlist.d /usr/local/lib/util-vserver/distributions/fc3/rpmlist.d/00.lst /usr/local/lib/util-vserver/distributions/fc4/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc4/rpmlist.d /usr/local/lib/util-vserver/distributions/fc4/rpmlist.d/00.lst /usr/local/lib/util-vserver/distributions/suse91/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/suse91/rpm /usr/local/lib/util-vserver/distributions/suse91/rpm/macros ___ 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
Re: [Vserver] readonly bind mount
On Mon, Sep 05, 2005 at 08:01:41PM +0900, Jun OKAJIMA wrote: I mean, I can write -o ro mounted dirs!. Why? because the mainline kernel folks are lazy and Al Viro considers this a feature instead of a bug :) Thanks and I understand why. But, if so, something like this could happen, even with your BME patch. [Host] # mount -o bind,ro /etc /vserver/103/etc [Host] # vserver 103 start [103] # cat /etc/shadow you can see shadowed passes from vserver. I think a root under vserver should be like this: 1. for files under /vserver/103/* - same as real root. 2. for files bind-mounted from host / - same as normal user. that would add additional policy to the kernel which is a) not required and b) limiting, because what if somebody wants to share a dir between two guests via --bind mounts? also do not forget that usually linux-vserver guests have a separate namespace, so --bind mounts done on the host system are not necessarily present in the guest namespace ... your opinion is? that is part of the host administration process. as admin, you should _always_ know what you are doing, and what the possible implications are ... --bind mounting the host /etc into a guest is playing with fire in any case ... so simply just don't do it unless guest root is trusted. best, Herbert --- Okajima, Jun. Tokyo, Japan. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] build -m rpm does not work
On Mon, Sep 05, 2005 at 06:22:16AM +0900, Jun OKAJIMA wrote: Hello. I installed util-vserver-0.30.208 from tar ball and succeeded to compile it on my Debian Sarge box. And vserver start/enter and build -m debootsrap work. But, build -m rpm and vhashify does not work. Any help? do you have a _working_ rpm installed? how does vhashify fail? Note: I dont have dietlibc and beecrypt problems which current sid has. so you installed them by hand? or not at all? BTW, I found that distrib/* know what is essential for each distribution. I want to know the basis of them. I mean, for example, distrib/suse91 shows aaa_base.rpm is only file to be essential, but what docs from SuSE say so? and in rh91 and fedoras? this is just trial and error, and you can replace this list by whatever list of rpms you consider 'essential' ... How you know which rpms are essential? trial and error ... if it works, and is minimal (i.e. dependancies are pulling in the 'other' packages) it's essential. (i.e. removing any package would cause it to fail somehow) HTH, Herbert --- Okajima, Jun. Tokyo, Japan. - [EMAIL PROTECTED]:/# vserver 101 build -m apt-rpm --force -- -d fc1 Renamed '/usr/local/etc/vservers/.defaults/vdirbase/101' to '/usr/local/etc/vservers/.defaults/vdirbase/101.~1125899538~' Renamed '/usr/local/etc/vservers/101' to '/usr/local/etc/vservers/101.~1125899538~' Renamed '/usr/local/etc/vservers/.defaults/vdirbase/.pkg/101' to '/usr/local/etc/vservers/.defaults/vdirbase/.pkg/101.~1125899538~' No dynamically linked rpm binary found; exiting... rm -rf /usr/local/etc/vservers/.defaults/vdirbase/101 /usr/local/etc/vservers/101 /usr/local/etc/vservers/.defaults/vdirbase/.pkg/101 [EMAIL PROTECTED]:/# vserver 102 hashify 'vserver ... suexec' is supported for running vservers only; aborting... failed to determine configfiles [EMAIL PROTECTED]:/# uname -a Linux Debian 2.6.12.4-vs2.0 #1 Sun Sep 4 05:55:19 UTC 2005 i686 GNU/Linux [EMAIL PROTECTED]:~# ldd /usr/local/lib/util-vserver/rpm-fake-resolver not a dynamic executable [EMAIL PROTECTED]:~# find /usr/local/lib/util-vserver/ | grep rpm /usr/local/lib/util-vserver/vserver-build.apt-rpm /usr/local/lib/util-vserver/vserver-build.rpm /usr/local/lib/util-vserver/vserver-build.functions.rpm /usr/local/lib/util-vserver/rpm-fake.so /usr/local/lib/util-vserver/legacy/parserpmdump /usr/local/lib/util-vserver/rpm-fake-resolver /usr/local/lib/util-vserver/vrpm-worker /usr/local/lib/util-vserver/vrpm-preload /usr/local/lib/util-vserver/distributions/defaults/rpm /usr/local/lib/util-vserver/distributions/defaults/rpm/macros /usr/local/lib/util-vserver/distributions/rh9/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc1/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc2/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc3/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc3/rpmlist.d /usr/local/lib/util-vserver/distributions/fc3/rpmlist.d/00.lst /usr/local/lib/util-vserver/distributions/fc4/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/fc4/rpmlist.d /usr/local/lib/util-vserver/distributions/fc4/rpmlist.d/00.lst /usr/local/lib/util-vserver/distributions/suse91/apt/rpmpriorities /usr/local/lib/util-vserver/distributions/suse91/rpm /usr/local/lib/util-vserver/distributions/suse91/rpm/macros ___ 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
Re: [Vserver] [patch] fix sched on amd64
On Mon, Sep 05, 2005 at 08:53:55PM +1200, Sam Vilain wrote:
The attached patch fixes a bug when you use vsched on a running
vserver on amd64, in which the high 32 bits of various scheduling
parameters could be filled with garbage, causing tokens to be allocated
at vastly incorrect rates.
how and why? any details? sounds like a
gcc bug to me (at first glance, maybe I'm wrong)
Patch is against -vs2.0
diff -ur linux-2.6.12.5-vs2.0.orig/include/linux/vserver/sched_def.h
linux-2.6.12.5-vs2.0/include/linux/vserver/sched_def.h
--- linux-2.6.12.5-vs2.0.orig/include/linux/vserver/sched_def.h
2005-09-05 19:05:11.0 +1200
+++ linux-2.6.12.5-vs2.0/include/linux/vserver/sched_def.h2005-09-05
19:03:11.0 +1200
@@ -21,10 +21,10 @@
atomic_t tokens;/* number of CPU tokens */
spinlock_t tokens_lock; /* lock for token bucket */
- int fill_rate; /* Fill rate: add X tokens... */
- int interval; /* Divisor: per Y jiffies */
- int tokens_min; /* Limit: minimum for unhold */
- int tokens_max; /* Limit: no more than N tokens */
+ uint32_t fill_rate; /* Fill rate: add X tokens... */
+ uint32_t interval; /* Divisor: per Y jiffies */
+ uint32_t tokens_min;/* Limit: minimum for unhold */
+ uint32_t tokens_max;/* Limit: no more than N tokens */
uint32_t jiffies; /* last time accounted */
ahem, that's the in-kernel structure used to
store the values, the userspace API uses
struct vcmd_set_sched_v3 {
uint32_t set_mask;
int32_t fill_rate;
int32_t interval;
int32_t tokens;
int32_t tokens_min;
int32_t tokens_max;
int32_t priority_bias;
};
so, if that affects the kernel somehow, the
issue must be somewhere else, no?
so I consider this a bandaid at most ...
will look into the code soon ...
thanks,
Herbert
int priority_bias; /* bias offset for priority */
diff -ur linux-2.6.12.5-vs2.0.orig/kernel/vserver/sched.c
linux-2.6.12.5-vs2.0/kernel/vserver/sched.c
--- linux-2.6.12.5-vs2.0.orig/kernel/vserver/sched.c 2005-09-05
19:05:11.0 +1200
+++ linux-2.6.12.5-vs2.0/kernel/vserver/sched.c 2005-09-05
18:03:45.0 +1200
@@ -30,7 +30,7 @@
*/
int vx_tokens_recalc(struct vx_info *vxi)
{
- long delta, tokens = 0;
+ uint32_t delta, tokens = 0;
if (vx_info_flags(vxi, VXF_SCHED_PAUSE, 0))
/* we are paused */
___
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
[Vserver] A few bugs on util-vserver...
Hello, all ! I noticed a few bugs when using util-vserver.208 (The Mandrake rpms): - /var/lib/run/vservers.rev is not created, so the vservers do not start - /etc/init.d/vserver-default cannot be added by chkconfig --add because the corresponding line in the script is contains - instead of 345. Is it really bugs ? -- ,, (° Nicolas Costes /|\ IUT de La Roche / Yon ( ^ ) Clé publique: http://www.keyserver.net/ ^ ^ Musique libre: http://musique-legale.info/ - http://www.jamendo.com/?s=concept pgpRfudLWz8Eg.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] build -m rpm does not work
[EMAIL PROTECTED] (Jun OKAJIMA) writes: I installed util-vserver-0.30.208 from tar ball and succeeded to compile it on my Debian Sarge box. And vserver start/enter and build -m debootsrap work. But, build -m rpm and vhashify does not work. (I assume you mean '-m apt-rpm' here as it is used below, and in the age of apt and yum there is not much need for the '-m rpm' method). BTW, I found that distrib/* know what is essential for each distribution. I want to know the basis of them. Essential means the package(s) which are essential for the functionality of the vserver. Without further information, this is only stuff like coreutils or glibc; depending on the purpose of the vserver, you can add things like httpd or samba or ... There is no need to put a full closure of the dependencies into 'rpmpriorities' or the package-lists; apt/yum will resolve the deps automatically and you will not run into problems with changed dependencies on updated packages. I mean, for example, distrib/suse91 shows aaa_base.rpm is only file to be essential, I am not familiarly with SUSE and used 'aaa_base' only as it sounds like a basic requirement. ;) No dynamically linked rpm binary found; exiting... rpm based build-methods do not work without a dynamically linked rpm binary in your $PATH. rm -rf /usr/local/etc/vservers/.defaults/vdirbase/101 /usr/local/etc/vservers/101 /usr/local/etc/vservers/.defaults/vdirbase/.pkg/101 [EMAIL PROTECTED]:/# vserver 102 hashify 'vserver ... suexec' is supported for running vservers only; aborting... failed to determine configfiles When using internal packagemanagment (this is the default with '-m debootstrap'), the vserver must be running to determine the configfiles. This is recommended for external packagemanagment also because mounted filesystems are not visible else. Enrico pgphpwdxn9c9T.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] build -m rpm does not work
On Mon, 05 Sep 2005, Jun OKAJIMA wrote: I tried with ready-made deb on sid, got from apt-line and same problem happened. maybe it is worse ... because vhasify binary seems not to be included. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319927 for why vhashify has not been included in the past, but is about to be. Micah ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Running Netatalk in a vserver
Le vendredi 2 Septembre 2005 03:06, Herbert Poetzl a écrit : I tried, it works on the host. good, that _is_ half the way ... I couldn't get Atalkd to work inside a vserver, although someone on the list or IRC seems to have succeded on Debian. Maybe this is Mandriva-related, but Atalkd (And apfd...) run fine on the host. The tcp part (afpd) works in the vserver, and the Appletalk part (Atalkd) not. So I tought of a capability issue, but giving all CAPS to the guest did not solve anything... Well, I tried writing CAP_NET_ADMIN and CAP_NET_RAW in the vserver's bcapabilities file, and this does apparently nothing. check with 'grep Cap /proc/self/status' from inside the guest ... (and don't forget to restart the guest) Well, there was nothing really interesting/understandable inside it... Well nothing I found related to CAPS. I gonna check agin. # cat /etc/vservers/filesrv/bcapabilities CAP_NET_ADMIN CAP_NET_RAW I tried too by writing there NET_ADMIN and NET_RAW, there is no error nor success. yep, but udp, tcp and special icmp are the only ones supported 'by default' ... Which means ? which means, other protocoly, other requirements (mostly capability wise) Ok, so I set ALL capabilities on that guest, and it still doesn't work :( : Nothing changes ! One has got to activate something to use another protocol ? yes, the cap stuff and it might be a problem with missing and/or too strict virtualization (but as I said, we can look into that) I'd like to help, and I've got a few hosts available. One more thing : Netatalk tries to load the appletalk kernel module on startup, which apparently fails because being inside a vserver. Anyway, the module is actually loaded when I start or stop the service ! (There is no need for it in the host server, but it appears there to. One kernel to rule the all, huh ?) yep, that's the main idea behind linux-vserver. contrary to Xen or UML you have only one kernel running on the host, no guest kernel, no guest modules jsut pure 100% userspace there ... This is good ;-) ! But what is fun, is that when /etc/init.d/atalkd is run (From inside the vserver), it fails to load the module, but actually the kernel loads it at this very moment !!! Maybe the kernel detects an access to some devices and loads the module from the host ? yes, that is possible and likely ... (maybe we have to 'restrict' this ... Well, restrict, but if that prevents hosted programs to run ;-)... Well, as I think of it, it's really a strange behaviour. Maybe something is needed to deal with programs that need a particular module to be loaded at run time... From inside a guest. The problem is, you use vservers to isolate processes, but the whole (kernel|processes)? will see a module that they do not need. Is it dangerous ? But atalkd still fails to start arguing that it cannot find any net device. maybe it needs special devices and/or capabilities don't know yet, never tried to get it working ... but we can investigate this soon, if you find some time ... I've got some, mainly at home after work, but I have access to IRC only at home. I can reach the IRC logs at work, which can be useful to make tests on other hosts. This means the appletalk module isn't working. not necessarily, but might be the cause, did you load it on the host? It is loaded and the whole thing works. Gone into production yesterdays ;-) maybe we should move that to the irc channel sooner or later :) I'm online every days after work. -- Réfléchir, c'est nier ce que l'on croit. Emile Chartier, dit Alain, Propos sur la religion pgpClfapC6ijx.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] File clash between libvserver and util-vserver: libvserver.so
util-vserver should be known well enough, libvserver is a project started by Benedikt Boehm in the time when Enrico was away. It provides an interface to the vserver-patched kernel. Homepage of libvserver: http://dev.croup.de/proj/libvserver/wiki Libvserver provides a shared object, libvserver.so.1, while util-vserver provides libvserver.so.0. Those two file have different origins, don't share code and have different APIs. We first hit a problem with the libvserver Debian package (unofficial, provided by Balint Laszlo Biller), which was not installable in parallel with the util-vserver package (the official one), since they both contained a libvserver.so symlink to the actual library (also in the same directories). So on the one hand libvserver somehow invades util-vserver's namespace, since clearly util-vserver's libvserver.so was there first. OTOH util-vserver's library isn't actually used by anything else then util-vserver AFAICS, so it could probably live in /usr/lib/util-vserver. I think this would be a nice and clean solution. Another option would be to drop libvserver.so (only the symlink, not the library itself) from the util-vserver .deb. The plain .so should only be used for building software against the library anyway, and since there is no such software AFAIK, it's useless. It stays the problem that there would be 2 libs in /usr/lib with the same name, different so-versions, but with different origin and authors. I don't think this as such a nice situation in the long run, because I think ther will be more of the problems we already have. Eg. what happens if Enrico descides (for whatever strange reason, since there are no users of the library) to increase the so-version.. Yet another thing would be to rename libvserver, I but I guess Benedikt wouldn't be too glad about this. What are your opinions on this? Cheers, Christian 'Greek0' Aichinger signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] [patch] fix sched on amd64
On Mon, 2005-09-05 at 17:15 +0200, Herbert Poetzl wrote: On Mon, Sep 05, 2005 at 08:53:55PM +1200, Sam Vilain wrote: The attached patch fixes a bug when you use vsched on a running vserver on amd64, in which the high 32 bits of various scheduling parameters could be filled with garbage, causing tokens to be allocated at vastly incorrect rates. how and why? any details? sounds like a gcc bug to me (at first glance, maybe I'm wrong) Yes, there is a lot of guesswork in the diagnosis. Here's what I was seeing. If I increased the size of the token bucket via vsched to, say, 5, and set its size to zero, then the bucket would still be instantly filled, even with a 1:100 fill rate. At various times it would could up or down for a short while, and then reset to full again, but always less than 100 from the maximum (with a 1:100 fill rate). This behaviour is consistent with what you'd expect if values were wrapping around because of unwanted bits in the upper half of the word when calculations happened, that were later truncated to 32 bits again. That was an early guess, and my change stopped the problem from re-appearing. I agree with you that that prognosis would make this a compiler bug (I'm on gcc 3.3.5), but I think it is a good idea to avoid such bugs by avoiding mixed long / int calculations where possible. so I consider this a bandaid at most ... will look into the code soon ... Sure. If you have any better idea about how to really get to the bottom of this, let me know how I can help. All the ways I can see are in a distant field of pain :). Sam. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] File clash between libvserver and util-vserver: libvserver.so
On Tuesday 06 September 2005 00:27, Christian Aichinger wrote: util-vserver should be known well enough, libvserver is a project started by Benedikt Boehm in the time when Enrico was away. It provides an interface to the vserver-patched kernel. Homepage of libvserver: http://dev.croup.de/proj/libvserver/wiki Libvserver provides a shared object, libvserver.so.1, while util-vserver provides libvserver.so.0. Those two file have different origins, don't share code and have different APIs. We first hit a problem with the libvserver Debian package (unofficial, provided by Balint Laszlo Biller), which was not installable in parallel with the util-vserver package (the official one), since they both contained a libvserver.so symlink to the actual library (also in the same directories). So on the one hand libvserver somehow invades util-vserver's namespace, since clearly util-vserver's libvserver.so was there first. OTOH util-vserver's library isn't actually used by anything else then util-vserver AFAICS, so it could probably live in /usr/lib/util-vserver. I think this would be a nice and clean solution. Another option would be to drop libvserver.so (only the symlink, not the library itself) from the util-vserver .deb. The plain .so should only be used for building software against the library anyway, and since there is no such software AFAIK, it's useless. It stays the problem that there would be 2 libs in /usr/lib with the same name, different so-versions, but with different origin and authors. I don't think this as such a nice situation in the long run, because I think ther will be more of the problems we already have. Eg. what happens if Enrico descides (for whatever strange reason, since there are no users of the library) to increase the so-version.. Yet another thing would be to rename libvserver, I but I guess Benedikt wouldn't be too glad about this. i'm not against it if someone has a _better_ name ;) What are your opinions on this? Cheers, Christian 'Greek0' Aichinger ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
