To be clear -- Except the batch file's path reference stops at \bin and the registry key goes all the way down to the jvm.dll. That's the only difference.
Thanks, -JDHood On Tue, Apr 2, 2013 at 9:24 AM, JD Hood <hood...@gmail.com> wrote: > I wish it was just that simple... > > I've been living in that registry key for the past few work days... It's > the same exact path (copied and pasted) from the batch file. > > > On Tue, Apr 2, 2013 at 9:06 AM, Longwing, Lj <llongw...@usgs.gov> wrote: > >> ** >> JD, >> If you check in the registry you will find all of the parameters that are >> utilized by the service when running as a service vs running via the >> command line, you may find your answer in the java path in the registry. >> >> >> On Tue, Apr 2, 2013 at 6:58 AM, JD Hood <hood...@gmail.com> wrote: >> >>> ** >>> I've since tried 64-bit & 32-bit JVM paths - no luck >>> I've tried adding all involved paths to the windows PATH statement - no >>> luck >>> I've tried adding an LD_LIBRARY_PATH env-var with all the library paths >>> - no luck >>> I've tried copying all the libraries/jars into the \AREmail directory - >>> no luck >>> I've tried running the service as a variety of users from local to >>> domain admin - no luck >>> I've compared the service registry entries to a known good working >>> system - can't spot a difference other than server names and paths >>> >>> The command-line email engine runs just fine with a different set of >>> libraries in the **same paths** (I've compared these to a known-good system >>> and it's normal) and it runs as the currently logged-in local admin >>> account. >>> >>> The service, set to run as the same local admin account, fails to >>> start-up enough to write to a log. If the windows event log is to be >>> trusted, it seems to indicate the JVM didn't start because it couldn't find >>> a file in the LoadLibrary statement. >>> >>> I am well and truly stumped! >>> >>> At this point, I'm wondering about the differences between running as a >>> service vs command line and if some group-policy or other security setting >>> is causing the issue. If I ever stumble across the resolution, I'll post it. >>> >>> Thanks for the suggestions, >>> -JDHood >>> >>> >>> >>> On Mon, Apr 1, 2013 at 7:14 PM, Thad Esser <thad.es...@gmail.com> wrote: >>> >>>> ** >>>> Yeah, I was really happy when I found that tool suite. Process >>>> Explorer is nice (similar to "top") and TCPView (netstat) too. >>>> >>>> Thad >>>> >>>> >>>> On Mon, Apr 1, 2013 at 3:58 PM, John Sundberg < >>>> john.sundb...@kineticdata.com> wrote: >>>> >>>>> ** >>>>> Great tool Thad… >>>>> >>>>> I used to use something like that in the Linux world all the time -- >>>>> you would see a program try to read a file -- then die right after that -- >>>>> but never give a good message. >>>>> >>>>> Then -- you would change the permissions - so it could see the file - >>>>> then bingo - it works. >>>>> >>>>> I did not know such a Window util existed. >>>>> >>>>> Thanks, >>>>> >>>>> -John >>>>> >>>>> >>>>> >>>>> On Mon, Apr 1, 2013 at 5:36 PM, Thad Esser <thad.es...@gmail.com>wrote: >>>>> >>>>>> ** >>>>>> I used the Sysinternals "Process Monitor" ( >>>>>> http://technet.microsoft.com/en-us/sysinternals/bb896645) utility to >>>>>> watch what was happening during the service startup. That let me see >>>>>> that >>>>>> it was searching for a particular file (mscvr100.dll) in a bunch of >>>>>> folders. It just so happened that the list of folders was the exact same >>>>>> list in the "Path" environment variable, in the same order. That *.dll >>>>>> is >>>>>> part of the java install and is located in the bin folder. Adding the >>>>>> bin >>>>>> folder to the Path was really all it was. At any rate, it sounds like >>>>>> you >>>>>> are up against something different, so I wanted to suggest taking a look >>>>>> at >>>>>> Process Monitor to see if that helped. >>>>>> >>>>>> Thad >>>>>> >>>>>> >>>>>> On Mon, Apr 1, 2013 at 1:43 PM, JD Hood <hood...@gmail.com> wrote: >>>>>> >>>>>>> ** >>>>>>> I'll check it again, but I've gone through all the (even >>>>>>> semi-related) KB entries. I loaded the path up with the java \bin, \lib >>>>>>> and >>>>>>> \aremail paths for good measure as one of my troubleshooting steps, >>>>>>> checked >>>>>>> permissions, re-installed java, removed & re-added the service, used >>>>>>> several different users and service accounts, and on and on. As soon >>>>>>> as I >>>>>>> regain connectivity, I'm going to try setting the LD_LIBRARY_PATH >>>>>>> manually >>>>>>> and see if that does the trick. >>>>>>> >>>>>>> Thanks, >>>>>>> -JDHood >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 1, 2013 at 4:21 PM, Thad Esser <thad.es...@gmail.com>wrote: >>>>>>> >>>>>>>> ** >>>>>>>> JD, >>>>>>>> >>>>>>>> I had this exact same issue, you'll probably find that flashboards >>>>>>>> isn't starting up either. The issue was that the java bin directory >>>>>>>> was >>>>>>>> not added to the PATH environment variable. BMC Support insisted that >>>>>>>> the >>>>>>>> java install would do that, but it didn't happen in any of my >>>>>>>> environments. >>>>>>>> Once I added that to the PATH variable, all was good. The reason >>>>>>>> that it >>>>>>>> works from the command line is that the batch file sets the path. >>>>>>>> >>>>>>>> Hope that helps, >>>>>>>> Thad >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Apr 1, 2013 at 12:51 PM, JD Hood <hood...@gmail.com> wrote: >>>>>>>> >>>>>>>>> ** >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Environment: v8.1 ARS/ITSM on Windows >>>>>>>>> >>>>>>>>> Has anyone encountered a situation where outbound email is >>>>>>>>> configured for simple, unassuming, plain-jane SMTP (no user or pass >>>>>>>>> needed) >>>>>>>>> and the email service (installed out of the box) will not start? >>>>>>>>> >>>>>>>>> I've tried setting the service to run as a domain user account >>>>>>>>> (permissioned for MAPI), a local admin account and as a domain admin >>>>>>>>> account. It still won't start. >>>>>>>>> >>>>>>>>> The weird part: I can switch to command line mode and it works >>>>>>>>> just fine with the same outbound settings. From the command line, it >>>>>>>>> starts-up, stays-up and happily processes mail until you stop it. >>>>>>>>> >>>>>>>>> Logging: >>>>>>>>> No email logs or java logs are produced when you try to start the >>>>>>>>> service. I don't think it gets far enough to even start a log. >>>>>>>>> >>>>>>>>> Windows event Application logs shows three events with the >>>>>>>>> following info: >>>>>>>>> 1. BMC Remedy Email Engine - MyServerName >>>>>>>>> 2. Could not load the Java Virtual Machine >>>>>>>>> 3. LoadLibrary The system cannot find the file specified >>>>>>>>> >>>>>>>>> I've checked the registry entries for the service and compared it >>>>>>>>> to the java paths used with the command line batch file and the paths >>>>>>>>> are >>>>>>>>> all correct, down to the jvm.dll for the service. >>>>>>>>> >>>>>>>>> Right now, all I have to go on is that, for some unknown reason >>>>>>>>> the service can't start a JVM. However running it from the command >>>>>>>>> line, it >>>>>>>>> can crank the JVM right up! >>>>>>>>> >>>>>>>>> I'm currently stumped. >>>>>>>>> >>>>>>>>> If anyone has encountered this before, I'd love to hear how you >>>>>>>>> resolved it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> -JDHood >>>>>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>>>>> >>>>>>>> >>>>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>>>>> >>>>>>> >>>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>>>> >>>>>> >>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *John Sundberg* >>>>> Kinetic Data, Inc. >>>>> "Your Business. Your Process." >>>>> >>>>> 651-556-0930 I john.sundb...@kineticdata.com >>>>> www.kineticdata.com I community.kineticdata.com >>>>> >>>>> >>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>>> >>>> >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
