Dear all,
I have a great news: IT WORKS !!
the localhost log file from Tomcat is now OK. It now can find the java files 
expected in /Library/Tomcat/work/Catalina/localhost/base2/org/apache/jsp/
Since then the tomcat-launchd.sdtout do not output any error message with the 
"Existing PID file found during start. Existing PID file found during start"
Catalina log file looks now also fine 

using "ps -e | grep Tomcat"
I can check that Catalina process is running with the right options:
-Xmx1G -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false -Djava.awt.headless=true

No more windowed application named org.apache.catalina.startup.Bootstrap that 

On the Activity monitor, the java and sh processes owned by _appserver  keeps 
the same PID number (which was not the case before
/Library/Tomcat/catalina_pid.txt contains the java PID number

How did I get up to that stage. 
First I changed the owner of the /Library/Tomcat/work/Catalina directory: sudo 
chown -R _appserver /Library/Tomcat/work/Catalina
and removed its contained directories rm -f /Library/Tomcat/work/Catalina/*

Since I did not have any /Library/Tomcat/logs/ file I created a link 
to the catalina one: ln -s  /Library/Tomcat/catalina_pid.txt 
I then follow up Jari's idea from his script:
Using the Activity Moniteur  I killed the java process from _appserver (it 
restarted a second after) and then the one from the shell also owned by 
This one took almost a minute to restart.
I could then check that the 
/Library/Tomcat/work/Catalina/localhost/base2/org/apache/jsp/ was built up.

And now from the browser, I can login from the webpage localhost:8080/base2
I can do it both on the server or from an other computer

It looks like now I can go on, creating the user accounts, etc…
Hope this summery will be helpful if some one else meets similar problems 

Thank you very much  to Jari and Nicklas for their patient help and deep 
I just hope not to have any other questions from now…


Le 13 sept. 2013 à 16:42, Jari Häkkinen <> a écrit :

> On 2013-09-13 13:08, Laurent Troxler wrote:
>> I noticed what could be an interesting point. In the
>> /Library/Tomcat/bin/ file is setted the following line as
>> recommended: CATALINA_OPTS="-Xmx1G
>> -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
>> -Djava.awt.headless=true"
>> but when I type ps -e | grep Tomcat, it gives the following: 14952
>> ttys000    5:31.03 /Library/Java/Home/bin/java
>> -Djava.util.logging.config.file=/Library/Tomcat/conf/
>> -Xms512m -Xmx1G
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> -Xms512m -Xmx1G
>> -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
>> -Djava.endorsed.dirs=/Library/Tomcat/endorsed -classpath
>> /Library/Tomcat/bin/bootstrap.jar -Dcatalina.base=/Library/Tomcat
>> -Dcatalina.home=/Library/Tomcat
>> org.apache.catalina.startup.Bootstrap start 16845 ttys000    0:00.00
>> grep Tomcat
>> Thus the -Djava.awt.headless=true setting does not appear here. Would
>> it mean that the setting comes from somewhere else then the
>> /Library/Tomcat/bin/ file ?
> It is important that the headless option is set. One test is to print the 
> variable at different points in the script to examine where it 
> changes.
>> If I do a modification on the /Library/Tomcat/bin/ file,
>> at what stage should I rester the installation procedure ? Just
>> restart Tomcat (/Library/Tomcat/bin/ and then
>> /Library/Tomcat/bin/ ? The other thing I noticed,
>> confirming that the Djava.awt.headless option is not taken in account
>> is that I get a windowed application named
>> org.apache.catalina.startup.Bootstrap that remains as mentioned by
>> Jari.
> I think this is the krux of your issue. When this is resolved you should be 
> good to go. Assuming that you did all steps in the BASE installation already 
> there is no restart once you resolved the tomcat issues. Just log in to BASE 
> and get started ;-)
> The Apache/tomcat connector mentioned in the installation documents is not 
> critical and is really useful for servers with heavy load.
>> What surprises me is that when I type the command :
>> /Library/Tomcat/bin/ I get the following output:
>> Using CATALINA_BASE:   /Library/Tomcat Using CATALINA_HOME:
>> /Library/Tomcat Using CATALINA_TMPDIR: /Library/Tomcat/temp Using
>> JRE_HOME:        /Library/Java/Home Using CLASSPATH:
>> /Library/Tomcat/bin/bootstrap.jar Using CATALINA_PID:
>> /Library/Tomcat/catalina_pid.txt PID file found but no matching
>> process was found. Stop aborted.
>> And the Java process is still running…
> Your observations above are exactly what I have seen on my system. There
> are two environment variables affecting the behaviour of the startup and
> shutdown of tomcat. I have attached my tomcat startup script to this
> mail. Since I am only testing BASE on my machine I created script to
> start and stop tomcat manually. The script is run like
> action
> where action is start, stop, status, restart.
> Examine the environment variables in the script. I have three variables;
> JAVA_OPTS, CATALINA_OPTS, and CATALINA_PID. The two OPTS can probably be
> merged into JAVA_OPTS only but I haven't bothered to do that.
> The important thing is that the shutdown script provided by
> tomcat/macports does not use CATALINA_OPTS at all but uses JAVA_OPTS.
> Therefore I place the headless option in JAVA_OPTS. The startup script
> provided by tomcat/macports uses both JAVA_OPTS and CATALINA_OPTS.
> The use of PID within the different scripts provided by tomcat/macports
> on my system is not consistent. I notes that script tomcatctl provided
> by tomcat/macports expects to be the PID-file i defined in variable
> CATALINA_PID. That is why I set the CATALINA_PID and pass it on to the
> startup and shutdown scripts. The different scripts will now rely on the
> same PID-file and work consistently.
> I created my script since I want to avoid changing system scripts since
> the system script may be replaced during upgrades. Of course, my script
> may fail later on but I have one script to fix in that case.
> Use the ideas from my script and you should soon be accessing your BASE
> server.
>> Other informations:
>> Both /Library/Tomcat/work/Catalina/localhost/base2 and
>> /Library/Tomcat/work/Catalina/localhost/_/ directories are empty
> Once you stop the tomcat server it is safe to remove the files and 
> directories from /Library/Tomcat/work/Catalina and down, i.e.,
>  rm -f /Library/Tomcat/work/Catalina
> and then restart. This forces tomcat to recompile the webapps. Startup takes 
> some additional time but you get a fresh compile. Once everything works there 
> is no need to clean up the work directory.
>> I have set the owner of /Library/Tomcat/work directory and inner
>> files to _appserver user and _appserveradm group as defined for the
>> tomcat process. The other odd thing I am just discovering is that
>> when typing the command line 'ps auxw | grep tomcat' I only get one
>> time out of three the shell process
>> /Library/Tomcat/bin/ And each time it has an other
>> pid. Is it supposed to be so ? That would explain why when I want to
>> shutdown the Tomcat process it is aborted.
> I don't know why you have this and have not seen this behaviour. Maybe it is 
> related to or 
> hopefully it goes away once the above issue is resolved :-)
> Cheers,
> Jari
> <>------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> The BASE general discussion mailing list
> unsubscribe: send a mail with subject "unsubscribe" to

LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
The BASE general discussion mailing list
unsubscribe: send a mail with subject "unsubscribe" to

Reply via email to