> >> 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. > > > > I'm under the impression that mount points have to be empty > directories... > > No (at least not under Linux) : >
Right, I've used this trick for a long time. I use a file called unmounted.txt, which scripts look for to test whether the nfs mount is mounted on the local directory. If unmounted.txt does not exist, the remote fs is mounted. The idea of having a loop in the script that waits for the directory to be mounted sounds problematic to me. We have 75 instances of tomcat, so 75 startup scripts. Even though they all start with S96, I assume the system picks one to start with, so that's the one that would spin waiting for the NFS mount. Then the others would run quickly after that. Still, if something bad happens with NFS, the script might never emerge from the loop. I guess I could put a timeout in there, but then it's back to a guessing game as to how long to wait. What if we create the expected directory structure under the unmounted directory so that when tomcat starts, its sees the directories it is looking for regardless of whether the NFS mount is complete yet? Then the web context would not fail and the XML file would not get deleted. When the NFS mount finally completes, from tomcat's perspective the directory suddenly gets populated with files. Would that cause a problem for either tomcat or NFS? In other words, would tomcat have a handle to the local file system that would keep the NFS mount from succeeding? On the other hand, when I add a new instance (which I do all the time) then I would not be able to create the expected directories on the unmounted FS because the NFS mount is in production. Sigh. Maybe the loop with the timeout is the best idea after all. I think I will explore the service dependency possibilities that Andrew mentioned. --Eric Disclaimer - March 23, 2011 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org