Elasticsearch Error: Could not evaluate jvm.options - windows

So I've been trying to setup Elasticsearch using Windows for the past half a day, and after going through errors and errors, I reached an error that occurs when I try to run the program by typing in elasticsearch.exe in the command prompt, or clicking on the desktop/file explorer shortcut for Elasticsearch. I don't know how to fix this error, nor could I find a solution online. I've tried uninstalling and reinstalling but get the same problem. The error is as follows:
Can anyone provide some help on how to fix this? Been trying and searching for hours but nada. I have my Paths setup correctly as shown here:
Thank you.

I suggest the problem is that the "config" folder in your case placed at the different address.
In my case the same problem was solved by moving "Elastic" folder (with all its content) from the "C:\Program Files" folder directly to the disc "C:". In this case the "config\jvm.options" folder\file appeared directly in the "Elastic" folder. After that update the nesessary pathes: the "ES_HOME", the "ES_PATH_CONF" and created a "ES_JAVA_HOME" path as well since this is a specific path that ElasticSearch (ES) will use. In my case all pathes looked like that:
ES_HOME C:\elasticsearch-7.16.2
ES_PATH_CONF C:\elasticsearch-7.16.2\config
ES_JAVA_HOME C:\elasticsearch-7.16.2\jdk
Important: ES_PATH_HOME should be created and exist along with the JAVA_HOME path that in my case was the next:
JAVA_HOME C:\Program Files\Java\jdk-17.0.1

Related

All my Jenkins jobs and configs have disappeared after restart of my Mac

After updating macOS to Mojave (10.14.4), my Mac was restarted and upon opening Jenkins (at localhost:8080) it appeared that I've lost all my jobs and the entire system configurations.
There was only 1 user (admin) defined in my installation and my usual password was deemed invalid, when I tried to log back in. So, I tried entering another password I normally used and it was accepted. I then found that all my jobs and configs have disappeared. It looked as if I've just started Jenkins for the first time.
Looking through here on StackOverFlow, there were suggestions to check the JENKINS_HOME variable to find out where the jobs are saved on the disk, but when I typed export $JENKINS_HOME I just get an empty response. So, it looks like I've never configured it during set up.
I then dig through the hard drive and found the folders matching the names of the jobs I created under ~/.jenkins/workspace. However, the contents of all the folders are empty. I was expecting to see the usual files, e.g. build.xml, config.xml, etc.
I then did a global search for build.xml and config.xml on Mac Finder it turned up nothing.
Any idea where my jobs went and what could have caused all the contents of the folders of the jobs to be empty?
You can find your Jenkins installation directory in "Manage Jenkins" -> "configure System" --> "Home directory". Find what was the Jenkins home before you restart MAC. It looks like your home directory is either deleted by you or you are pointing to new folder now. Set it to earlier folder.
If can help,
I'm having a similar problem.
The curious part is about the new directory after the service restart ".jenkins" directory inside :
'/var/root/'.
And now, the password that Jenkins request me is not from
'/Users/username/.jenkins/secrets/initialAdministratorPassword' but from the newst one with same path pattern.
Simon

Elasticsearch failed to start - CreateJavaVM Failed

sorry if this is a trivial question, but I've been banging my head against this and I'm getting nowhere, so I thought I'd throw it up.
I'm trying to install Elasticsearch on an Windows 2008 server on Azure. It appears to have installed correctly, but I cannot get it to start.
I have looked around for similar errors and double-checked my JAVA_HOME variable - it appears to be correct, as does the config file.
I also expanded out the heap size via editing the java options files, still no luck.
Any help would be greatly appreciated
Output Log file
JAVA_HOME variable
Which version are you installing? The latest, which would be 5.5.0?
Which installation method did you use? The ZIP or the MSI file?
The last line in your Output Log file screenshot actually shows the error message: The data area passed to a system call is too small.
I'm taking a wild guess: You set Java_HOME in the user variables, but it must be set in the system variables.

Postgres "psql not recognized as an internal or external command"

For Postgres, I keep getting this error multiple times even though I have already set the location of the bin folder to the path variable in Windows 8. Is there something else I'm missing?
(I can't post pictures since I don't have enough reputation)
Just an update because I was trying it on Windows 10 you do need to set the path to the following:
;C:\Program Files\PostgreSQL\14\bin ;C:\Program Files\PostgreSQL\9.5\lib
PS : 14 is the current version, check whatever version you are on.
You can do that either through the CMD by using set PATH [the path]
or from my
computer => properties => advanced system settings=> Environment
Variables => System Variables
Then search for path.
Important: don't replace the PATHs that are already there just add one beside them as follows ;C:\Program Files\PostgreSQL\9.5\bin ;C:\Program Files\PostgreSQL\9.5\lib
Please note: On windows 10, if you follow this: computer => properties => advanced system settings=> Environment Variables => System Variables> select PATH, you actually get the option to add new row. Click Edit, add the /bin and /lib folder locations and save changes.
Then close your command prompt if it's open and then start it again
try psql --version
If it gives you an answer then you are good to go if not try echo %PATH% and see if the path you set was added or not and if it's added is it added correctly or not.
Important note:
Replace 9.5 with your current version number. As of 2021, that is 13.
For 2022 is 14.
Windows 10
It could be that your server doesn't start automatically on windows 10 and you need to start it yourself after setting your Postgresql path using the following command in cmd:
pg_ctl -D "C:\Program Files\PostgreSQL\11.4\data" start
You need to be inside "C:\Program Files\PostgreSQL\11.4\bin" directory to execute the above command.
EX:
You still need to be inside the bin directory to work with psql
Enter this path in your System environment variable.
C:\Program Files\PostgreSQL\[YOUR PG VERSION]\bin
In this case i'm using version 10. If you check the postgres folder you are going to see your current versions.
In my own case i used the following on separate lines:
C:\Program Files\PostgreSQL\10\bin
C:\Program Files\PostgreSQL\10\lib
You can follow the following steps below.
C:\Program Files\PostgreSQL\yourversion
I had your issue and got it working again (on windows 7).
My setup had actually worked at first. I installed postgres and then set up the system PATH variables with C:\Program Files\PostgreSQL\9.6\bin; C:\Program Files\PostgreSQL\9.6\lib. The psql keyword in the command line gave no errors.
I deleted the PATH variables above one at a time to test if they were both really needed. Psql continued to work after I deleted the lib path, but stopped working after I deleted the bin path. When I returned bin, it still didn't work, and the same with lib. I closed and reopened the command line between tries, and checked the path. The problem lingered even though the path was identical to how it had been when working. I re-pasted it.
I uninstalled and reinstalled postgres. The problem lingered. It finally worked after I deleted the spaces between the "; C:..." in the paths and re-saved.
Not sure if it was really the spaces that were the culprit. Maybe the environment variables just needed to be altered and refreshed after the install.
I'm also still not sure if both lib and bin paths are needed since there seems to be some kind of lingering memory for old path configurations. I don't want to test it again though.
If you tried all the answers and still spinning your heads, don't forget to change the version with your one which you downloaded.
For example, don't simply copy paste
;C:\Program Files\PostgreSQL\9.5\bin ;C:\Program Files\PostgreSQL\9.5\lib
More clearly,
;C:\Program Files\PostgreSQL\[Your Version]\bin ;C:\Program Files\PostgreSQL\[Your Version]\lib
I was spinning my heads. Hope this helps.
Make sure that the path actually leads to the executables. I'm using version 11 and it did not work until this was set as the path:
C:\Program Files\PostgreSQL\11\bin\bin
Maybe this is how version 11 is structured or I somehow botched the installation but I haven't had a problem since.
Even if it is a little bit late, i solved the PATH problem by removing every space.
;C:\Program Files\PostgreSQL\<installed version>\bin;C:\Program Files\PostgreSQL\<installed version>\lib
works for me now.
Simple solution that hasn't been mentioned on this question: restart your computer after you declare the path variable.
I always have to restart - the path never updates until I do. And when I do restart, the path always is updated.
Find your binaries file where it is saved. get the path in terminal mine is
C:\Users\LENOVO\Documents\postgresql-9.5.21-1-windows-x64-binaries (1)\pgsql\bin
then find your local user data path, it is in mostly
C:\usr\local\pgsql\data
now all we have to hit the following command in the binary terminal path:
C:\Users\LENOVO\Documents\postgresql-9.5.21-1-windows-x64-binaries (1)\pgsql\bin>pg_ctl -D "C:\usr\local\pgsql\data" start
done!
Always better to install a previous version or in the installation make sure you specify the '/data' in a separate directory folder "C:\data"
For Windows 10 and 11 users, here are the steps:
Go to Edit environment variables for your account (search for it on the start menu)
It will open the System Properties form — click the Environment Variables
Under the User variables for <username> (or you can add it in system variables), find the path variables and click edit, and add the path to your Postgres bin file address (in my case it's C:\Program Files\PostgreSQL\15\bin).
And save it and re-open the terminal.

iReport-5.6.0 is not working

I installed iReport-5.6.0 on my system. I have jadk - 1.6.0_37 installed on my machine.
When I double click on iReport icon on my desktop, initially it shows loading cursor for 1-2 seconds and then disappeares. After that there is no responce.
I am not getting exactly what happening or what do I need to configure.
I edited ireport.config file and added path "C:\Program Files\Java\jdk1.6.0_37\bin". But its giving me following message:
When I am clicking on Ok its sying need to specify userdir using command --userdir.
Can someone please help me to configure this?
I got the solution :)
I replaced installation directory from "program files/jaspersoft/" to "program files(x86)" and updated my jdk path in ireport.config. Now its working fine.

Visual Studio unknown build error. The fully qualified name must be less than 260 characters

I'm having trouble while building my WPF solution. Everytime I try to build it, I get this error message:
Unknown build error, 'The specified path, file name, or both are too
long. The fully qualified file name must be less than 260 characters,
and the directory name must be less than 248 characters.'
Someone can help me? I've already verified all the fields and their extension paths are ok. Can this be a problem with the TortoiseSVN or something like this? I recently added a folder to my solution, can be something with this?
This is a well-known restriction in the Windows win32 api. The directory in which you stored your project is nested too deep. The full path name of a file cannot contain more than 259 characters. Beyond this, lots of C code that uses MAX_PATH starts failing due to buffer overflows.
Move your solution to another directory, one that's closer to the root.
I had a similar issue where the compiler reported that there was a problem with the file ASPNETCOMPILER. The actual issue was that the solution contained a node_modules folder, and this folder can contain very lengthy paths, and it looks like the compiler can't handle this.
Windows 8.1 and 10 have an option to increase the Win32 path limit:
Open Group Policy Editor (Press Windows+R and type gpedit.msc and hit Enter)
From the Group Policy Editor window, navigate to the following node: Local Computer Policy\Computer Configuration\Administrative Templates\System\Filesystem
Doubleclick on Enable Win32 long paths option and enable it.
This may allow you to temporarily move the problem folder out of the build, which may allow you to successfully build, then you may be able to add the folder back into the solution without affecting anything.
See here for additional reference - https://www.microfocus.com/documentation/filr/filr-4/filr-desktop/t47bx2ogpfz7.html
There is registry approach which can be used at least for Windows 10:
Value of the parameter HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) should be set to 1.
You don't even need top restart anything (IDE or PC).
This problem is caused by the restriction of Windows OS about handling long path greater than length 260. The solution of this problem for VS2019 is pretty straight-forward. But, for VS2017 users, we can use a workaround to solve the problem.
VS 2019
Open run window (windows-key + r), then type regedit and hit enter.
On the address bar of Registry Editor, enter this: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
On the right side, find the key LongPathsEnabled, double click on it, and change the value from 0 to 1
Restart VS2019, clean (if needed) and build your project again. The error should be fixed.
General workaround (VS2017/VS2019)
We can create a link of the original longer path to a shorter one. Then, VS will treat the shorter path as project root and the issue will be solved.
Create a shorter root path for project, e.g. we have created "D:\project" directory
Now open cmd (Command Prompt) and Create a symbolic link using this command: mklink /D "D:\project\myProject" "YOUR_ACTUAL_LONG_PATH_PROJECT_ROOT_DIRECTORY" [You may need to open cmd as administrator if above command fails to execute]
Now, open VS project from the "D:\project\myProject" directory and it should work.
No worry....This error comes because of long path name,Suppose your project folder name is "myproject".
You Just Change location of project folder...Put your Project "myproject" to D:\myproject or or F:\myproject drive.Then You Publish again..Its work...
Happy Coding...
It is issue with build defination workspace "Build Agent Folder location"
VS adds paths example:
$(SourceDir)E:\Somedirectory\ProjectName\
Just keep $(SourceDir) in filed
I had the same problem. My checkout path was shorter than the path used on my CI server. It built OK on the CI server, and all my colleagues machines. Our paths are the same length because our company has fixed length user names. I was the only machine that could not build the solution due to long paths.
If you go to these folders:
C:\Windows\Microsoft.NET\Framework
C:\Windows\Microsoft.NET\Framework64
C:\Users\[UserName]\AppData\Local\Temp
Find the version of .NET you are using with your solution, then delete the "Temporary ASP.NET Files" folders from which ever versions you think are effecting your build.
You can delete them all, your next build of a web project might take a little bit longer as there will be no pre-compiled assemblies...
This solution worked for me on a solution containing ASP.NET projects - it wont work on WPF projects that others have mentioned in their answers, unless their solution also contains ASP.NET projects.
Searching for the error string VS gives you brought me here, so I figured it might help someone else, if not the Op with a WPF build issue.
If these fail - you can try searching your solution root recursively for files/folders with paths that are greater the 260, by performing the following:
Open Powershell
cd <path to solution root>
cmd /c dir /s /b |? {$_.length -gt 260} > output.txt
This will pipe a list of files with paths > 260 to the output.txt file which will be newly created in the root of your solution.
This will help you find files within your solution that are too long.
For this, you have to run Power Shell on Windows as an administrator, and then type:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
This solved the issue

Resources