tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: tomcat6 still deleting XML files from Catalina/localhost when the system is booted
Date Wed, 23 Mar 2011 10:07:02 GMT
Robinson, Eric wrote:
>> Eric Robinson
>>> #!/bin/bash
>>> #
>>> # httpd        Startup script for the Apache HTTP Server
>>> #
>>> # chkconfig: - 85 15
>>> # description: Apache is a World Wide Web server.  It is 
>> used to serve 
>>> \
>>> #              HTML files and CGI.
>>> # processname: httpd
>>> # config: /etc/httpd/conf/httpd.conf
>>> # config: /etc/sysconfig/httpd
>>> # pidfile: /var/run/
>>> See the line with chkconfig - S## E##?
>>> Put those in your config before doing a chkconfig add, and it will 
>>> cause them to start in that order. Make sure they start 
>> after nfs and 
>>> die before nfs and you should be golden.
> Hmmm... all of my tomcat scripts in /etc/rc.d/rc5.d start with S96. How
> do I ensure that they start after the NFS mount is available? The only
> NFS-related scripts that I see are S14nfslock and K20nfs. It looks like
> those are already starting well before the tomcat scripts.
I think that there are several issues here.
One issue (the one discussed so far above), is the order in which the system startup 
scripts are started and/or run.
Obviously in this case, since your Tomcats depend on some NFS mounts being available, you

want to make sure that the startup actions which make these mounts available, are run 
before you start the Tomcats.
Traditionally on Unix-like systems, this was achieved by the numbering scheme in the 
startup scripts links /etc/rcX.d/SnnScriptname.
More recently, other schemes have emerged, based on a kind of "registry", which allows to

specify dependencies between the various startup scripts.
I think that this is what Jason earlier alluded to.
But I believe that the details of these schemes vary between Linux distributions, and are

not necessarily portable.

But anyway, that is not enough, because the mere fact that these mounts-related startup 
scripts are run before the Tomcat-startup scripts are run, still does not guarantee that 
the NFS mounts themselves are available.  As far as I know, NFS mounts may be 
asynchronous, namely the "mount" instruction itself is run and has returned, but the real

NFS mount is still ongoing, and the system does not "see" the distant directory yet, it 
still sees the local mountpoint directory.

So what you really want to do for example, is something like this :
Suppose one of your local system's mountpoints is "/mnt/nfs01", and suppose that what you

want to mount there, is the exported NFS filesystem "server01:/some/exported/fs".
If you place a small file "not.yet.mounted" inside of the /mnt/nfs01 local directory, it 
will be visible, as long as the mount has not yet really happened.
And as soon as the mount has really happened, it will no longer be visible, because its 
parent directory "/mnt/fs01", will be "hidden" by the contents of 
Conversely, if you place a file "now.its.mounted" inside of the remote directory 
"server01:/some/exported/fs", it will not be visible locally in "/mnt/fs01", until the 
mount has really happened.
So what you could do in your Tomcat startup scripts, is having a small loop which waits 
until either of the above conditions above is verified, before letting the real Tomcat 
startup take place.
(Under Linux, there is also a nifty little program called "mountpoint" that can help you 
there, but that may be less portable).
The drawback of this, is that if something happens to the NFS server or that share, and 
you reboot your system or run a Tomcat startup script, it may appear to "hang" for quite a

while instead of just failing. But that may be a small price to pay versus starting a 
Tomcat without its needed files.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message