This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
This might be a question without an answer, but I thought it would
be worth asking nevertheless. I've got two applications A and B
where A requires JRE 5 and B requires JRE 7 (these come with
windows and linux versions). However the application that
requires JRE 5 will not run against JRE 7. How can I run
both without having to tweak the PATH environment
variable to point to the correct java program
prior to running each of A and B based on
which of the two I need to run?
Seems like there must be a way to set application-specific PATH
variables/JREorJDK pointers.
Thanks,
Jason Posit
Two options: Either call the java engine from the full path depending on which one you want eg for Java 5:
c:\jdk5\bin\java.exe | /usr/bin/java5/java MyJava5Class
change the path accordingly for java 7.
Or you can set up Java5_Home and Java7_Home environment variables to point to the root install directory of those locations (or if you're lazy like me straight into bin\java.exe) and call the java engine using them:
%Java5_Home%\bin\java.exe Java5Class
or
$Java7_Home/bin/java MyShinyNewJava7Class
You can set the JAVA_HOME in your server startup script specific to java version you are using
This is a bit tricky, if you are trying to deploy the applications on the same server then you have to modify the start up script to take the JAVA_HOME value at startup then set the JAVA_HOME accordingly.
for JBOSS you can set the JAVA_HOME in JBOSS_HOME/bin/run.conf
for tomcat you can set the JAVA_HOME in CATALINA_HOME/bin/setEnv.cmd
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I created one service in C# and created installer for that.Installer is working fine and service is installed properly on server. But here is one problem. When server restarts the program connected to service automatically getting deleted from C:\ProgrameFiles location, but service is still there and when restarting this service. I am getting prompt like "windows can not find specified program path". Can somebody help me what I am missing here or what is potential cause for this problem?
I know the the scope of this question is too broad to answer but still I want some hints or any solution to resolve this issue. I tried to searching many forums but unfortuanatly no luck. please consider while vote to closing this question. I can edit more to clarify this scenario.
Thanks.
What kind of server is this? Terminal server?
UPDATE: It isn't a virtual machine is it? If so, are the disks set fully persistent? See 9.
If you run repair on the MSI in question, does the file come back?
What happens if you check the file directly with your malware scanner?
If you shut down the service manually, is the file still there? (just to be sure). Try repeatedly stopping and starting the service a few times.
Did you verify that the service runs from where you expect after installation? (have to ask)
Do you install per-machine or per-user?
Debugging
Check the event viewer and the MSI log files:
MSI Logging: Installsite: MSI log "how-to" and / or More MSI logging information.
Event Viewer: Hold down Windows Key, tap R, type eventvwr.msc and press Enter. Go to Windows Logs => Applications. Look for MsiInstaller events. Check the other logs too (Security, System, Configuration).
Deployment Mnemonic: And a "deployment mnemonic" (yellow section) - some heuristics to think about deployment problems.
Some Ideas
Loose Cannon: While we wait for feedback from you, let's fire off a list of suggestions shooting from the hip. Some of these are bad or
eliminated as causes, let's just list all to remember the bad ones
too:
1) Quarantined malware? (real or false positive, doesn't matter which). The file gets quarantined on every reboot? Upload file(s) to virustotal.com to check binaries that are missing. Do an administrative installation if you need to get hold of the files.
2) Upgrade Problem? (not the cause in this case, but MSI major upgrade can cause this kind of problem - for example when you attempt to downgrade a file to a lower version).
3) System policies? Not really familiar with what policies that could delete files - if any at all. Just mentioning that a lot of policies can affect Windows in general. Check the event logs. Some registry keys are periodically overwritten for example with defined AD settings.
4) Cleanup Scripts? Anything is possible here, but it would be strange to delete a pinpointed executable? Check what runs on boot? Autoruns. Run that tool and have a look at auto-starting binaries - there are a lot on most systems.
5) System Restore? Not relevant here as far as I can tell, but system restore can do VERY strange things such as delete single files from somewhere unexpected out of the blue. Yes, I have seen it (not a fanboyism - I was there - in the fires of mount Doom - it really happened).
6) Recovery hardware? Some computers have hardware devices that restore the system to earlier states on reboot with various options to allow some persistence here and there. No idea how prevailing these are now, but I expect their use for quick malware recovery and stuff like that. Talk to your system administrators?
7) Permissions? Does the package apply ACL permissions to the folder in question? It shouldn't cause this problem, but maybe check it. The service should never be able to start at all if permissioning is wrong.
8) Disk Corruption? An issue that one must always check for.
9) Virtual Machine? One issue that came to mind is whether this server is running as a virtual machine and if so whether the disk setup is one of full persistence? Not sure what is technically possible here at the current day and time.
10) Hidden Icons? One more issue - added in a hurry - some icons can be hidden in the Windows start menu from Windows 8 upwards (I believe, details fuzzy). I suppose this can yield the impression that a product has been uninstalled, when it is just hidden. Almost certainly not relevant for your situation.
Questions
PendingFileRenameOperations: After installation, are there entries in PendingFileRenameOperations? Check BEFORE installation as well.
Are there pending operations waiting for a reboot?
Location: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
Rollback: Even more obscure, is rollback disabled for Windows Installer? I can't see how that would cause this problem, but it is possible to do and what it triggers and makes possible I am not sure of.
Bitness Confusion: It is possible that people just think that files are missing, because they are looking in the wrong folder (x86 instead of x64 or vice versa). Not relevant here (then the service would start - unless there is something else wrong), but listed to remember it for other, similar cases.
"Out There": This is C:\Program Files\ right? Not C:\ProgramData\? Are there any mounted disks on the NTFS partition? Any symbolic links? Roaming profiles? Do you install per-machine or per-user?
I know that in Windows I don't have to do so.
For example, ./dir/file.ext and dir/file.ext are equivalent.
Are these two forms possibly different on any other OS, e.g., Linux?
Or is it possibly application-dependent, in which case they might be treated differently even on Windows?
I am asking because I keep bumping into the usage of ./ at the beginning of path names (mostly but not only in NodeJS), and I would like to be sure that I can omit it safely (i.e., avoid turning my code platform-dependent).
The ./ you're referring to is specific to UNIX-like operating systems (OSX and Linux are the major examples) and not program specific. On those platforms, it is used to execute the file being referred to, while in Windows merely typing an executable's filename will execute it. I don't know if the code you're referring to determines which OS you're on, but if it's true that Windows ignores the period, then this is a useful cross-platform method to execute an executable.
I'm pretty new to Informix and I'm trying to run a screen with sperform, but it's just seg faulting when I try to query. So far I have:
installed Ubuntu server 12 (64bit)
installed the Dev suite and runtime 7.50
installed the Informix engine 12.10
verified it was all up and running; can connect with dbaccess
created an example database & table and inserted a couple rows
generated a form using isql from the table
ran the generated form with sperform
As soon as I attempt to query with the form, I get a "Segmentation fault (core dumped)" and it exits. Can anyone help me understand why? Isn't this as basic as it gets?
Preliminary answer
Yes; that is as basic as it gets. No; it should not crash. There are essentially no circumstances under which that sequence should crash. You should probably file a bug report with IBM.
The only thing that might conceivably be an issue is that ISQL may have been built with an older version of the CSDK than the server installs and there may be an unexpected incompatibility. It should work, but occasionally flaws creep in. If you want to explore how to prove this possibility, say so. It is a little fiddly, but may get you up and running while the problem is resolved formally.
Extended answer
YES! I'd love to try to fix this.
The first step, it seems to me, is to see whether ISQL (Informix SQL) runs correctly when installed on its own — rather than when mixed with the Informix server code. It should work in both environments, but it is possible that the new server code has changed something that is causing the older tools code to break.
So, reinstall Informix SQL (and the other dev tools if you want, but you could save those until you've got a POC with just ISQL) into a new directory. Let's suppose your server is installed in /opt/informix; you could install your tools in /opt/isql instead. (No need to uninstall the tools from under /opt/informix yet.)
Copy the server sqlhosts file (from /opt/informix/etc/sqlhosts) to the new /opt/isql/etc/sqlhosts.
Change INFORMIXDIR=/opt/isql.
Add the new value to the front of your path (PATH=$INFORMIXDIR/bin:$PATH).
Worry about the setting of LD_LIBRARY_PATH — you want to pick up libraries from under /opt/isql/lib in preference to those under /opt/informix/lib.
Leave INFORMIXSERVER unchanged; you'll still be talking to the same database server.
You should now try to (re)generate the form file and run it. With a small modicum of luck, it will work now.
OK, that works! Don't know if that's a good thing or not, but we're going to try to get that change into production.
It gets you going; that's good. It's also a relief to me that the fundamentals of the QA process for the tools release didn't break down. The product works when run in the environment it was developed for.
It's a nuisance that a later release of the server changed something so that the older build of the tools no longer works with the newer server. It is supposed to be OK. However, running with separate INFORMIXDIR values for tools and server is not unheard of. If the server was on a separate machine, the segregation would be inevitable — the tools would use a separate INFORMIXDIR from the one used by the server (ignoring NFS file systems, etc)
Is it possible that there's some aspect to my steps that cause something to be overwritten?
No. The classic 'Rule of TEN (Tools, Engine, Network)' — install tools before the server (before the network-enabled version of the server) more or less applies and is what you did. The separate network-enabled version of the server ceased to be relevant about 20 years ago, but tools before engine (the 'Rule of TE' just doesn't cut it) is normally correct.
Since the workaround works, we need to look ahead a bit: what does it mean for you?
You have a solution that will work pro tem.
You will need to be careful with environment setting when you run programs.
Programs using the tools (Informix 4GL, Informix SQL) will be run with INFORMIXDIR=/opt/isql and consequential environment settings.
Programs installed by the server (DB-Export, DB-Import, ON-Stat, etc) will be run with INFORMIXDIR=/opt/informix and consequential environment settings.
If you wish, you can set up scripts in /opt/isql/bin for the programs from /opt/informix/bin that you want developers or users to use.
The scripts in /opt/isql/bin will set the environment correctly for the server and then exec the server program.
The scripts in /opt/informix/bin will similarly set the environment correctly for the tools and then exec the tools program.
In each directory, assuming you're careful, you have a single script that actually sets the environment and runs the other program; the program names are simply (symbolic?) links to the master script.
You have two separate master scripts — one to set the server environment, one to set the tools environment.
You should report the problem to IBM (Informix) Technical Support. You can outline what you've had to do to work around the problem. The fact that you have a workaround will lower the urgency, but it is still a problem that should, ideally, be fixed. (The world isn't ideal though, just in case you hadn't noticed; it may take time for the fix to be delivered.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
EDIT:
NO LONGER RELEVANT. Due to difficulties with Installshield including not only this issue but also issues with getting it to build with the project in Visual Studio and its inability to replace one of the old files that needs to be replaced I am now coding an installer in C#. I should have done this earlier because I'd be done by now. Thank you Christopher Painter and Michael Urman for trying to guide me though this issue. Unfortunately I did not get anywhere further with it.
ORIGINAL POST BELOW
Honestly, this has been like pulling teeth. I hope that I'm missing something blatantly obvious. I have been trying to get Installshield to let me set the INSTALLDIR to an environmental variable. This is necessary because of the way the company does things. I know I can set it outside of the installer via a batch file which calls the MSI and passes the folder via an argument, but that solution ended up with an unfriendly MSI. If anyone has any internal solutions please let me know.
Windows Installer has the Environment table that is exposed by InstallShield in the environment view and component | advanced settings | environment view.
Setting Environment Variables
Windows Installer allows you to refer to environment variables using a variant of property notation. I would suggest an approach similar to RobertDickau's, where you use a set-property custom action early to set INSTALLDIR from [%SOMEVAR]. Only run the custom action if INSTALLDIR isn't already defined, so that people can override INSTALLDIR at the command line. Note that this must be run before costing, or you will have to find a different condition and use a set-directory action (like Robert mentions) instead.
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.