Re: [Vserver] Re: Re: Re: Re: Re: Re: java crash in vserver...

2007-05-12 Thread Jan Zuchhold
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...

2007-05-08 Thread Jan Zuchhold
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


[Vserver] fcntl on NFS still broken on vs1.20

2003-12-08 Thread Jan Zuchhold
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

2003-11-05 Thread Jan Zuchhold
  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