Re: [Vserver] Re: Re: Re: Re: Re: Re: java crash in vserver...
Hello, > I made a package of my guest 'gis' (about 465 MB): > /etc/vservers/gis (config of the image) > /vservers/gis (home of the guest images) > > http://www.archit.uni-karlsruhe.de/geoserver/vserver.tar.bz2 ok, i've tried it. The problem is caused by running out of space on /tmp. You mount that on tmpfs, specified in fstab in the vserver-config dir: none /tmptmpfs size=16m,mode=1777 0 0 If you remove or comment-out this line (or increase the size), it works. Jan pgpXCaBaYGobH.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Re: Re: Re: Re: java crash in vserver...
Hello, > Perhaps is anybody out there who has debian etch in a vserver with suns > java deb package and could test if installation fails too or not? > > It's quiet easy to install and can easily removed after it: > 1. get http://downloads.sourceforge.net/geoserver/geoserver-1.5.0-bin.zip > 2. unzip it into /usr/local/geoserver > 3. execute 'GEOSERVER_HOME=/usr/local/geoserver > JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/jre > /usr/local/geoserver/bin/startup.sh' it's working fine for me: >>> 1512 [INFO] org.geotools.referencing.factory.epsg.HSQLDataSource - Creating cached EPSG database. It may take a few minutes. 17611 [main] INFO org.springframework.web.context.ContextLoader - Using context class [org.springframework.web.context.support.XmlWebApplicationContext] for root WebApplicationContext 17611 [main] INFO org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization completed in 16212 ms >>> >>> vserver:~# cat /etc/issue Debian GNU/Linux 4.0 vserver:~# java -version java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode) host:~# uname -r 2.6.20.11-vs2.2.0.k7-smp-070502 >>> Jan pgptWoFgu7RH4.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] fcntl on NFS still broken on vs1.20
[...] > there should be _no_ warning or error in the process > of patching both kernels, otherwise we have different > kernels (which would be interesting) yup, no warnings or errors. I compiled both kernels again, and (as expected) the behavior is just reversed, which means 2.4.22ctx-17c+net01 has broken fcntl and 2.4.22-vs1.00+net01 is working fine. [...] > I'll look for it, and make some simple patches, to > test ... maybe you can pay a visit on the irc channel? On my way. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] fcntl on NFS still broken on vs1.20
> > I just tested vs1.20 and it appears that fcntl locking on NFS shares
> > mounted inside a vserver is still broken, as I reported some time ago
> > (04.11.2003). I quote from my other posts:
> >
> > The share is mounted like this in the vserver startup script:
> >
> > /usr/sbin/chbind --ip 192.168.1.145 --bcast 192.168.1.255 mount -t nfs
> > fileserver:/home /var/lib/vservers/$2/home
> >
> > Script to reproduce error:
> >
> >
> > #!/usr/bin/perl
> >
> > use Fcntl;
> >
> > open FH, ">locktest.lock" or die "Cannot open $fn: $!";
> > print "Testing fcntl...\n";
> > @list = (F_WRLCK,0,0,0,0); # exclusive write lock, entire file
> > $struct = pack("SSLLL",@list);
> > fcntl(FH,&F_SETLKW,$struct) or die("cannot lock because: $!\n");
> >
> > # With vs1.00 and vs1.20 I don't get here
> >
> > print FH "blabla";
> >
> > close FH;
> >
> >
> > Symptoms: NFS Share stops responding, all processes go to state D.
> >
> > Because of this problem nearly all of my machines are stuck at
> > 2.4.22ctx-17c.
2.4.22ctx-17c: works, no problem
2.4.22-vs1.00: does not work, fcntl broken
2.4.23-vs1.20: does not work, fcntl broken
> hmm, so this _is_ working with 2.4.22ctx-17c?
yep
> which patch of vs1.20 did you try, the one for 2.4.22
> and the 2.4.22 source or the one for 2.4.23?
> did you use the _same_ config file as for the
> 2.4.22ctx-17c?
yep, i just checked, i used exactly the same config for 2.4.22-vs1.00 and
2.4.22ctx-17c.
> I will try to reproduce ...
> there should be no difference in behaviour between
> 2.4.22ctx-17c and vs1.00 ...
Well, maybe it should, but it isn't ;)
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] fcntl on NFS still broken on vs1.20
Hello List!
I just tested vs1.20 and it appears that fcntl locking on NFS shares mounted
inside a vserver is still broken, as I reported some time ago (04.11.2003). I
quote from my other posts:
The share is mounted like this in the vserver startup script:
/usr/sbin/chbind --ip 192.168.1.145 --bcast 192.168.1.255 mount -t nfs
fileserver:/home /var/lib/vservers/$2/home
Script to reproduce error:
#!/usr/bin/perl
use Fcntl;
open FH, ">locktest.lock" or die "Cannot open $fn: $!";
print "Testing fcntl...\n";
@list = (F_WRLCK,0,0,0,0); # exclusive write lock, entire file
$struct = pack("SSLLL",@list);
fcntl(FH,&F_SETLKW,$struct) or die("cannot lock because: $!\n");
# With vs1.00 and vs1.20 I don't get here
print FH "blabla";
close FH;
Symptoms: NFS Share stops responding, all processes go to state D.
Because of this problem nearly all of my machines are stuck at 2.4.22ctx-17c.
Is there anything I can do to get this bug fixed?
Thank you,
Jan
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] NFS problems with vs1.00
> > There seems to be a problem with using nfs shares in a vserver with
> > vs1.00. It appears that it is related to file locking.
> >
> > The share is mounted like this in the vserver startup script:
> >
> > /usr/sbin/chbind --ip 192.168.1.145 --bcast 192.168.1.255 mount
> > -t nfs fileserver:/home /var/lib/vservers/$2/home
> >
> > After mounting the share it seems to work correctly (cd/ls/touch showing
> > no problems).
> >
> > When I start a process (in my case it's eclipse in jvm 1.4.1) which tries
> > to lock a file on that nfs share, it goes to state D ('uninterruptible
> > sleep') and cannot be killed. Any other process which tries to access the
> > share goes to state D as well.
>
> hmm, could you try to reproduce this without eclipse/jvm?
> (some small C programm or perl script will do)
I could track down the problem to the fcntl64 syscall.
Strace output:
10:36:19 fcntl64(3, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0,
len=0}
I attached a small perl script to reproduce this.
After that syscall the process goes to state D and if the lock would be
granted by the nfs server (if it is not locked already), there is no further
access possible to that nfs share, even umount -f does not work.
As far as I can tell, if the file is already locked by another process, it
just waits, as I would expect.
> > This problem does not appear in ctx-17c (the last version I tried
> > before), although the first three syslog messages appear as well.
>
> maybe the patch isn't the only variable in this game,
> maybe you patched another (newer?) kernel with v1.00?
(sorry I forgot to include the versions):
Both 2.4.22, same .config, just the vserver patch is different.
Host is debian stable/woody, vserver is debian unstable/sid.
Thank you,
Jan
--
#!/usr/bin/perl
use Fcntl;
open FH, ">locktest.lock" or die "Cannot open $fn: $!";
flock FH, 2;
print "flock works...\n";
print "Testing fcntl...\n";
@list = (F_WRLCK,0,0,0,0); # exclusive write lock, entire file
$struct = pack("SSLLL",@list);
fcntl(FH,&F_SETLKW,$struct) or die("cannot lock because: $!\n");
# With vs1.00 I don't get here
print FH "blabla";
close FH;
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] NFS problems with vs1.00
Hello list!
There seems to be a problem with using nfs shares in a vserver with vs1.00.
It appears that it is related to file locking.
The share is mounted like this in the vserver startup script:
/usr/sbin/chbind --ip 192.168.1.145 --bcast 192.168.1.255 mount -t nfs
fileserver:/home /var/lib/vservers/$2/home
After mounting the share it seems to work correctly (cd/ls/touch showing no
problems).
When I start a process (in my case it's eclipse in jvm 1.4.1) which tries to
lock a file on that nfs share, it goes to state D ('uninterruptible sleep')
and cannot be killed. Any other process which tries to access the share goes
to state D as well.
Syslog on the Host says:
Nov 4 11:57:04 galateia rpc.statd[233]: Call to statd from non-local host
192.168.1.145
Nov 4 11:57:04 galateia rpc.statd[233]: STAT_FAIL to galateia for SM_MON of
192.168.1.69
Nov 4 11:57:04 galateia kernel: lockd: cannot monitor 192.168.1.69
Nov 4 11:57:05 galateia kernel: nfs: server fileserver not responding, still
trying
This problem does not appear in ctx-17c (the last version I tried before),
although the first three syslog messages appear as well.
Jan
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
