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/httpd.pid
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.
Right.
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
"server01:/some/exported/fs".
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
