Re: [5.0] Procrun problems / New loader
Remy Maucherat wrote: Hi, I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#-Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? I believe this is correct, and using the test mode sort of works (except that the console output doesn't get redirected). Trying to run the service doesn't work at all, and looking in the registry, it doesn't seem to have the needed parameters (so I wonder how the test mode does work). Also, Procrun doesn't seem to be designed to handle Tomcat in service mode (that is, where Tomcat doesn't block and wait for a shutdown command). Mladen, I think I need some help :) Other that that, there are now too many ways to start Tomcat in standalone mode: - Bootstrap - The launcher - JMX I think the most compelling is to use the launcher + JMX (and allow JMX only also). Basically, in the Windows distribution, there are some incosistencies, as the scripts use the launcher, while the service uses direct invocation of Bootstrap. I can't do those changes alone. Comments ? Java code of daemon: jakarta-commons-sandbox/daemon/src/java/org/apache/commons/daemon Java code of launcher: jakarta-commons-sandbox/daemon/src/java/org/apache/commons/launcher C code of procrun: jakarta-commons-sandbox/daemon/src/native/nt/procrun C code of daemon: jakarta-commons-sandbox/daemon/src/native (except nt/procrun) I am using daemon to start Tomcat as normal user but listening on port 80 on Linux. I am also using daemon (with cygwin) to run Tomcat on windoze but I am thinking to change to procrun for that platfrom. For the moment I have not enough time to look to launcher nor JMX. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
jean-frederic clere wrote: Remy Maucherat wrote: Hi, I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#-Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? It's an Ant token, so it gets replaced before invoking NSIS anyway. The service parameters now gets populated correctly (I looked at the source code to find out where they were going), but: - err and out redirection doesn't seem to work (the console stays blank, as do the logs, and all output goes into the console) - procrunw still flashes a console when it's used; I thought it was supposed not to - WorkingPath doesn't seem to do anything - JavaOptions doesn't either :-( If I call the test service mode from the right directory (the Catalina home), then it works ok. Additionally, it seems that the daemon must block until stop is called to work. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 9:38 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader jean-frederic clere wrote: Remy Maucherat wrote: I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#- Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? It's an Ant token, so it gets replaced before invoking NSIS anyway. The service parameters now gets populated correctly (I looked at the source code to find out where they were going), but: - err and out redirection doesn't seem to work (the console stays blank, as do the logs, and all output goes into the console) Those can be used only if you redirect onother process. Try with -Java java. Dunno how to redirect the console of the current process. Setting handles doesn't help. The only thing that can be used is API Hooking, but that's too much for now. I was using -Java auto. I thought it was supposed to be the same. - procrunw still flashes a console when it's used; I thought it was supposed not to It shouldn't. But the problem is that I made the wrong binaries using devcpp. Try with the lates build. - WorkingPath doesn't seem to do anything Not when using JVM. For redirected app it sets the Working Directory when calling the CreateProcess. That seems to be a plausible explanation. I had looked at the source, and it seemed to be making the CreateProcess call using the right paramter. - JavaOptions doesn't either :-( Here is how it works for me: procrunw //IS//Tomcat4 --DisplayName Tomcat 4.1.19 --Description Tomcat 4.1.19 LE JDK 1.4 http://jakarta.apache.org; --ImagePath c:\devtools\tomcat\41\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Dcatalina.home=c:\devtools\tomcat\41#-Xmx128M#-Dtomcat.home=c:\devtools \tomcat\41 Perhaps you exceeded the command line length. Try using the Procrunw //IS//Tomcat minimum params (ServiceName, DisplayName, ImagePath, and Install). Then Procrunw //US//Tomcat extra params (update service changing or adding params.) Well, I checked with the registry, and everything gets registered ok with one single call. Update also works good. You can call the //US as many times as you wish. Also check if some installation params that NSIS process have emedded spaces. In that case you'll need to quote that params. --JavaOptions needs the next argument as single string so it need to be quoted. --Dcatalina.home=\some location\#etc... Yes, I sort of figured that out. I tried hacking the value in the registry without much success. How and are the params set correctly, can be seen in the registry: HKLM\\SOFTWARE\\Apache Software Foundation\\Process Runner 1.0\\ServiceName\\Parameters. The JavaOptions is MULTI_SZ, and you can check the params there. Yes, I had already found out everything was there. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 11:28 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader [EMAIL PROTECTED] wrote: Those can be used only if you redirect onother process. Try with -Java java. Ok, it's the magic parameter indeed :) Rereading the readme.txt, it looks like it's supposed to be equivalent to auto. Another question: Can I use procrun on 9x ? There's a duplication of functionality between procrun and the laucher. Should procrun call the laucher, which then calls the launcher ? It seems like a waste of resources, so maybe procrun should go directly to Tomcat ;-) It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. That's doable. I don't know if it's really useful, though. Or we decide we should stop caring about Win 9x for the installer. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. That's doable. I don't know if it's really useful, though. Or we decide we should stop caring about Win 9x for the installer. +1. One who is enthusiast enough to use the TC on DOS box is certainly capable of setting that up ;-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 11:28 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader [EMAIL PROTECTED] wrote: Those can be used only if you redirect onother process. Try with -Java java. Ok, it's the magic parameter indeed :) Rereading the readme.txt, it looks like it's supposed to be equivalent to auto. Another question: Can I use procrun on 9x ? There's a duplication of functionality between procrun and the laucher. Should procrun call the laucher, which then calls the launcher ? It seems like a waste of resources, so maybe procrun should go directly to Tomcat ;-) It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. That is what instmain.c is doing. +++ if (isWindowsNT()) done = InstallSvcNT(szExePath); else done = InstallSvc(szExePath); +++ And +++ if (isWindowsNT()) done = RemoveSvcNT(); else done = RemoveSvc(); +++ I do not have update_service for 9x. Everthing else should work as is, so you are wellcome to copy that from instmain. I will do it ASAP... MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. All that sounds great :) There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Try running in console mode: procrun.exe //TS//Tomcat5. That's with the GT option. Does that make a difference ? I'll check it more (but right after I fix a minor bug in the mapper). If that's OK then it's a security issue thought. Also what Java and OS? Mine is Sun's 1.4.1 and WIN2K Server. 1.4.1 + XP I'm running TC 4.1.20 and web.xml has set: init-param param-namedevelopment/param-name param-valuefalse/param-value /init-param I'm using the fork init-param to fix it: init-param param-namefork/param-name param-valuefalse/param-value /init-param The error page is the one you get when the compiler is not found. For each jsp I see that the javac is launched under SYSTEM account. So it works. Didn't test with 5.0 but I think that there isn't much difference for that case. There is other problem with the running TC using redirected Java, and that is the lack of gracefull shutdown option. I'm working on that right now. It will enable JVM invocation of Bootstrap with (stop or stopd) in that case if enabled. It's ok if it just sends a term signal to the VM (there's a shutdown hook). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Try running in console mode: procrun.exe //TS//Tomcat5. If that's OK then it's a security issue thought. Also what Java and OS? Mine is Sun's 1.4.1 and WIN2K Server. TS does the same as GT. (ie, it fails with fork being true, which is the default, and works with fork being false). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. All that sounds great :) I have just committed the support for win9x but I have not tested it yet. There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
