This content has been marked as final. Show 11 replies
Bump. Hoping that new week means someone is willing to help out.
First question, is your question related to an Endeca Information Discovery application or a different Endeca product? I just ask because usually new EID applications are created with the latest version of the MDEX which does not utilize the AppConfig scripts you're working with. You might try a different forum if this is not for EID. That said, I've seen this problem before.
I’ve seen the ConfigManager.updateWsConfig(); line fail many times, but I’m not sure I’ve seen it caused by a missing perl executable. I can think of 2 ideas:
1) Is the perl file executable? It may be there but if it’s not executable, it probably won’t work. chmod +x perl Try running the perl executable alone at a command line prompt. Does it work? perl --help or something
2) Do you even need workbench integration? Usually when I’d run into this error, I’d just strip out the workbench stuff from AppConfig.xml. I didn’t needed it for many of the projects I worked on. In fact, I've never needed it for an EID application. Don’t spend time debugging a problem that you don’t need to fix.
Firstly, unless something has changed recently, Ubuntu is not a supported platform, so you may wish to change to a supported platform to get things working.
Your symptoms can sometimes occur due to missing 32-bit libraries on the machine. Your Forge executable, and the shipped Perl it calls are typically 32-bit applications running on a 64-bit server, and if the 32-bit libraries are missing, Perl can't launch. If this is the issue, you can try using apt-get to install the ia32-libs package.
Note that even if you get this working, you are on an unsupported platform for production and development use, and it's recommended that you change to use a supported-platform (see docs).
Thanks Dave and Brett for trying to help me out on this one. I know that Ubuntu is not an officially supported OS but I did have this working without issue on Ubuntu 11.04 -- so I am sure that it will work. The only difference between my current config and my old one was that 11.04 was the full client not just the stripped down server OS. I suspect that like Brett has suggested, some package just isn't installed by default where as it is with the desktop version.
- I checked my ENDECA_ROOT and it is correctly set to /usr/local/endeca/PlatformServices/6.1.0
- I navigated to the perl directory and it is executable and owned by my user. perl -version responded so that should eliminate that possible issue
- I installed the ia32-libs package but I am still seeing the issue
Unfortunately the logs are not terribly useful for this error. Do you guys know of any other libs that could cause this problem when they are missing?
Sometimes I could get better error message when I tried to run the underlying utility directly rather than running it through the EAC. I happen to know that the updateWsConfig() simply execs a call equivalent to $ENDECA_ROOT/bin/emgr_update.sh. (I don't remember what the args are supposed to be for that utility at the moment, but you should be able to find it in the docs or maybe with --help). Maybe you'll get better insight into your error after trying this.
But, it could be something else causing your problem. The source code for the EACToolkit used to ship in YOUR_PROJECT/config/lib/java/eacToolkit.jar. Not sure if that's the case anymore. The ConfigManager code is actually in eacComponents.jar. If you're really stuck, you could look at this code to find out what is really going on and try running individual operations from a command line. For the updateWsConfig() method, for example, the CleanDirUtility is used, which uses perl. I don't remember how that works though.
One more thought. Anything that the EAC runs in your AppConfig.xml script is run by the account that owns the EAC service. It could be the case that the EAC is running under an "endeca" user or something, which does not have permissions to see the perl executable.
You are correct in that I don't TECHNICALLY need web studio for my implementation as it is a Latitude project. I don't like the idea of just turning it off, but I did as you suggested to move the ball forward. In the AppConfig.xml I set the flag for webStudioEnabled to false. That allowed me to get past the initialize_services script and the load_baseline_data scripts, but when I run a baseline_update, I get a similar error --
Setting flag 'baseline_data_ready' in the EAC.
[07.24.12 15:26:55] INFO: Checking definition from AppConfig.xml against existing EAC provisioning.
[07.24.12 15:26:56] INFO: Definition has not changed.
[07.24.12 15:26:56] INFO: Starting baseline update script.
[07.24.12 15:26:56] INFO: Acquired lock 'update_lock'.
[07.24.12 15:26:56] INFO: Retrieving Dev Studio configuration.
[07.24.12 15:26:56] INFO: [ITLHost] Starting copy utility 'fetch_dev_studio_config'.
[07.24.12 15:26:57] INFO: [ITLHost] Starting shell utility 'cleanDir_processing'.
[07.24.12 15:26:57] SEVERE: Utility 'cleanDir_processing' failed. Refer to utility logs in [ENDECA_CONF]/logs/shell on host ITLHost.
Occurred while executing line 17 of valid BeanShell script:
16| // clean directories
[07.24.12 15:26:57] SEVERE: Caught an exception while invoking method 'run' on object 'BaselineUpdate'. Releasing locks.
Caused by java.lang.reflect.InvocationTargetException
sun.reflect.NativeMethodAccessorImpl invoke0 - null
Caused by com.endeca.soleng.eac.toolkit.exception.AppControlException
com.endeca.soleng.eac.toolkit.script.Script runBeanShellScript - Error executing valid BeanShell script.
Caused by com.endeca.soleng.eac.toolkit.exception.EacComponentControlException
com.endeca.soleng.eac.toolkit.utility.Utility run - Utility 'cleanDir_processing' failed. Refer to utility logs in [ENDECA_CONF]/logs/shell on host ITLHost.
[07.24.12 15:26:57] INFO: Released lock 'update_lock'.
The log file does contain something a little more useful this time though --
Can't locate strict.pm in @INC (@INC contains: /tmp/original_perl_build_dir/lib/5.8.3/i686-linux /tmp/original_perl_build_dir/lib/5.8.3 /tmp/original_perl_build_dir/lib/site_perl/5.8.3/i686-linux /tmp/original_perl_build_dir/lib/site_perl/5.8.3 /tmp/original_perl_build_dir/lib/site_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
I checked in /usr/local/endeca/PlatformServices/6.1.0/perl/lib/5.8.3 and I do see the strict.pm file there so I'm not sure I understand what the issue is.
Huh. I'm not really strong with Perl but it looks like perl in your environment is looking for modules in some other non-Endeca perl locations. Maybe you've got to set the PERL5LIB environment variable to point at /usr/local/endeca/PlatformServices/6.1.0/perl/lib/5.8.3?
I didn't even have that environment variable set. I added it as you suggested and the baseline_update ran. I'm going to try to re-enable studio tonight to see it that will work now as well. I'll report back what I find.
I tried it again last night with the environment variable set. Top to bottom everything worked.
Thanks again for the help.
No problem. I haven't paid too much attention to the PERL5LIB setting in the past. It must be set during the installation process. Maybe it's one of those things that doesn't get set correctly on some unsupported platforms. FYI, I've got PERLLIB set as well. You've got everything working at this point, but this is what I have on my PC that still has 6.x installed on it.
Check for access write on folder whether allowed to clean that folder