SAS Service "SAS [SASConfig-Lev1] Distributed In-Process Scheduler command-line job runner" is failing to run on Win2012 R2 server.
Its set to Automatic, failed to run on startup and fails now as I try to start it.
Only dependency is the SAS Metadata Server and that is running fine.
In the log at \Lev1\Web\Applications\SASWIPSchedulingServices9.4\dip\serviceLog, the entry reads:
STATUS | wrapper | 2017/08/29 16:51:51 | --> Wrapper Started as Service
STATUS | wrapper | 2017/08/29 16:51:51 | Launching a JVM...
FATAL | wrapper | 2017/08/29 16:51:51 | Unable to execute Java command. The system cannot find the file specified. (0x2)
FATAL | wrapper | 2017/08/29 16:51:51 | "\bin\java.exe" -Djava.system.class.loader=com.sas.app.AppClassLoader -Dsas.app.repository.path="D:\SAS\SASVersionedJarRepository\eclipse" -Dsas.app.launch.picklist="D:\SASConfig\Lev1\Web\Applications\SASWIPSchedulingServices9.4\dip/picklist" -Xmx128m -Dsas.cache.locators=rad1sas1.hps-rad.local[41415] -Dspring.profiles.active=client-locators -Dsas.gemfire.log-level=severe -Dsas.gemfire.log.file= -Djava.library.path="D:\SASConfig\Lev1\Web\Applications\SASWIPSchedulingServices9.4\dip" -classpath "D:\SAS\SASVersionedJarRepository\eclipse\plugins\JavaServiceWrapper_3.2.3\wrapper.jar;D:\SAS\SASVersionedJarRepository\eclipse\plugins\sas.launcher.jar" -Dwrapper.key="eknAd40L52PNah3_" -Dwrapper.port=32006 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=14260 -Dwrapper.version="3.2.3" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 com.sas.scheduler.api.servers.ip.engine.mq.client.JobRunnerService "D:\SASConfig\Lev1\Web\Applications\SASWIPSchedulingServices9.4\dip/DIPJobRunner.properties"
FATAL | wrapper | 2017/08/29 16:51:51 | Critical error: wait for JVM process failed
It seems DIP job uses a configuration file sitting at SASHOME
D:\SAS\wrapper.conf
As #DomPazz pointed out the java path was incomplete while assigned to key. I
included the full path and that solved the issue. Strangely, the First time I modified and restarted the box it got overwritten by a backup of the file sitting somewhere.
Contents of the wrapper.conf :
# Java Application
# In Error state the key below had the value of "\bin\java.exe"
wrapper.java.command=D:\SAS\SASPrivateJavaRuntimeEnvironment\9.4\jre\bin\java.exe
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
wrapper.java.classpath.1=D:\SAS\SASVersionedJarRepository\eclipse\plugins\JavaServiceWrapper_3.2.3\wrapper.jar
wrapper.java.classpath.2=D:\SAS\SASVersionedJarRepository\eclipse\plugins\sas.launcher.jar
# Java Additional Parameters
wrapper.java.additional.1=-Djava.system.class.loader=com.sas.app.AppClassLoader
wrapper.java.additional.2=-Dsas.app.repository.path="D:\SAS\SASVersionedJarRepository\eclipse"
Note : Another wrapper.conf sits in D:\SASConfig\Lev1\Web\Applications\SASWIPSchedulingServices9.4\dip but that seems have properties for the Windows service!
Related
Was setting up Airflow (2.1.4) in a virtual environment followed by an install of a third-party plugin "pip install simple-dag-editor"
Plugin installed successfully, however upon checking the plugin list, there were duplicated entries.
(venv) root#test-server:/opt/airflow$ airflow plugins
name | source | flask_blueprints | appbuilder_views
==================+============================================================+=======================================================+=============================================================
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
Airflow portal also resulted in 2 entries in the "Admin" section
Any idea what is happening? I tested the setup again both on a docker container and standalone on the server. Both instances did not result in the duplicated entries therefore I am suspecting it is related to running Airflow in a Python virtual environment. The server is running on CentOS 7.
I believe you might have plugin installed twice in two different places:
In "plugins" folder as simply a python package
Installed as python package
Aiflow Allows for both types of installations, and I think if you have both - it will install both.
If you change the airflow log level to verbose, you should be able to see two entries:
"Loading plugins from entrypoints"
"Loading plugins from directory: <DIRECTORY>"
They should be followed by attempts to import the plugins.
The solution would be to remove the plugings from the "plugins" directory.
It's also possible that you have two packages that have the same entrypoint - for example if you installed it with different package name before, it could also be discovered twice. Airflow checks all pacakges available and if they have appropriate entrypoint declared, it will load it as plugin. But if you enable DEBUG logging level, you should see details. You can easily set airflow logging level by config option (or environment variable):
https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#logging-level
I want to create an automated script for setting up VS Code.
Part of this is the installation of the extensions and configuring them as necessary.
So I was able to install the extensions via CLI, but can't find how to change the extension settings by only using the command line.
For example - I want to change Jest Runner settings. I found this on their readme:
Jest Runner will work out of the box, with a valid Jest config.
If you have a custom setup use the following options to configure Jest Runner:
| Command | Description |
| --- | --- |
| jestrunner.configPath | Jest config path (relative to ${workFolder} e.g. jest-config.json) |
| jestrunner.jestPath | Absolute path to jest bin file (e.g. /usr/lib/node_modules/jest/bin/jest.js) |
| jestrunner.debugOptions | Add or overwrite vscode debug configurations (only in debug mode) (e.g. `"jestrunner.debugOptions": { "args": ["--no-cache"] }`) |
| jestrunner.runOptions | Add CLI Options to the Jest Command (e.g. `"jestrunner.runOptions": ["--coverage", "--colors"]`) https://jestjs.io/docs/en/cli |
| jestrunner.jestCommand | Define an alternative Jest command (e.g. for Create React App and similar abstractions) |
| jestrunner.disableCodeLens | Disable CodeLens feature
| jestrunner.codeLensSelector | CodeLens will be shown on files matching this pattern (default **/*.{test,spec}.{js,jsx,ts,tsx})
But don't know how to access it via cmd.
Any thoughts on how to do this?
Thanks!
Was able to find a solution now.
So it turns out that the settings are actually stored in:
<userFolder>\AppData\Roaming\Code\User\Settings.json
From there I can open up the json file and add in the commands as specified by the extension's readme.
I'm attempting to start OrientDB in distributed mode on AWS.
I have an auto scaling group that creates new nodes as needed. When the nodes are created, they start with a default config without a node name. The idea is that the node name is generated randomly.
My problem is that the server starts up and ask for user input.
+---------------------------------------------------------------+
| WARNING: FIRST DISTRIBUTED RUN CONFIGURATION |
+---------------------------------------------------------------+
| This is the first time that the server is running as |
| distributed. Please type the name you want to assign to the |
| current server node. |
| |
| To avoid this message set the environment variable or JVM |
| setting ORIENTDB_NODE_NAME to the server node name to use. |
+---------------------------------------------------------------+
Node name [BLANK=auto generate it]:
I don't want to set the node name because I need a random name and the server never starts because it's waiting for user input.
Is there a parameter I can pass to dserver.sh that will pass this check and generate a random node name?
You could create a random string to pass to OrientDB as node name with the ORIENTDB_NODE_NAME variable. Example:
ORIENTDB_NODE_NAME=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
For more information about this, look at: https://gist.github.com/earthgecko/3089509
I have downloaded a copy of the 1.1.0-RELEASE tagged source code for Spring RESTdocs, but "gradlew build" is failing during the test phase. 273 of 502 tests are failing with variations on this error:
org.springframework.restdocs.request.RequestPartsSnippetTests > requestPartsWithOptionalColumn[Markdown] FAILED
java.lang.AssertionError:
Expected: is adoc snippetPart | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
but: was:Part | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
The problem looks to be that the string "adoc snippet" is prefixed to the start
of the expected output. I don't think that's right, although I can see in the AbstractContentSnippetMatcher.describeTo() why it's happening and it doesn't look very conditional so maybe it's the test's actual result that's wrong?
I have made no changes to the source code* but I don't see other people reporting this problem, so I'm mystified. I'm entirely new to gradle. Is there some kind of config I need to set up to make the tests pass? Should I be using a different target?
(OK... 1 teensy change: I removed the new-line-at-end-of-file check from the checkStyle - I'm downloading from Github onto a Windows PC.)
The problem is that the files in the zip have Unix-style line endings but, when run on Windows, Checkstyle and the tests expect Windows-style line endings.
Typically a Windows Git client will take care of this for you by converting the line endings when you check out the code. For example, the default configuration of Git for Windows is to check code out with Windows-style line endings but commit changes with Windows-style line endings.
You may be able to find a Windows utility that will batch-convert the line endings from LF to CRLF. Failing that, it's probably easiest to install a Git client (such as Git for Windows that I linked to above), ensure it's configure to perform line ending conversion, and then:
> git clone https://github.com/spring-projects/spring-restdocs
> cd spring-restdocs
> gradlew build
Hi I am facing an issue in starting the Apache DS. My environment is as follows.
Windows 7
64 Bit
I have 2 JVM's running (32 and 64bit) I have given the 32 bit JVM for the Apache DS.
When I start the service it says "windows couldnt start ApacheDS - default service on Local computer Error 1067 The process Terminated Unexpectedly"
When I check the logs in the instances folder shows the following log
STATUS | wrapper | 2013/07/15 15:27:55 | --> Wrapper Started as Service
STATUS | wrapper | 2013/07/15 15:27:55 | Launching a JVM...
INFO | jvm 1 | 2013/07/15 15:27:55 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO | jvm 1 | 2013/07/15 15:27:55 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
INFO | jvm 1 | 2013/07/15 15:27:55 |
STATUS | wrapper | 2013/07/15 15:28:01 | <-- Wrapper Stopped
Can Someone please help me to start the Apache DS Service
Go to the
Program Files\ApacheDS\instances\default\conf
and modify the log4j.properties Change all FATAL log level to the DEBUG and restart the service. You can find what is the main reason of problem in new log files that are produced in the
Program Files\ApacheDS\instances\default\log
For example I have this problem after change the log level, I found the main error is
ERR_250_ENTRY_ALREADY_EXISTS ou=system already exists!
And this is an open issue in the ApacheDS
https://issues.apache.org/jira/browse/DIRSERVER-1954
Hope this help you!
Open Installation path and go to below path or where ever you have installed your Apache DS,
open C:\Program Files (x86)\ApacheDS\conf\wrapper.conf xml file in text mode
find below path,
Path to java executable
wrapper.java.command
you need to update "wrapper.java.command=" with you the java installation path example as below,
wrapper.java.command=C:\Program Files\Java\jre1.8.0_221\bin\java.exe
follow above path or find the java directory and update,
you are fine to fire your ApacheDS service, go to services(or C:\Program Files (x86)\ApacheDS\Manage ApacheDS --> Double Click) find ApacheDS and start.
This isn't my solution - but I think this answer the temp directory problem with also explaining why it occurs - Please find the link and the answer below:
https://issues.apache.org/jira/browse/DIRSERVER-2007
I tested this change (since it made it into the lastest version of ApaceDS server) and it is still not working on Windows 2008 when running as a service, but the problem is not the length of the path but the ability to write the temp directory. On my system the TEMP & TMP environment variables are set to:
%SystemRoot%\TEMP for System and for User is it %USERPROFILE%\AppData\Local\Temp.
Since the ApacheDS service is running as "Local System account" I would assume it would be trying to write to %SystemRoot%\TEMP. For whatever reason (and I can think of a few) ApacheDS can't create a temp file in that folder.
I fixed by creating a tmp folder in the instance directory and added the following line to wrapper.conf:
wrapper.java.additional.6=-Djava.io.tmpdir="%INSTANCE_DIRECTORY%/tmp"
That fixed the problem. I think it would be better if ApacheDS explicitly set it's temp folder to someplace it controlled and knew it could write to. A sys admin that wanted the files somewhere else could make a symlink or change the wrapper.conf. Those temp files contain ldap data so it would be better from a security standpoint to keep them with the rest of the instance data. If the instance is going to have its own log folder it might as well have its own temp directory.
Might it be, that you have selected javas /bin folder during installation as Java root directory?
If so, set it one level higher, as /bin is not the root directory.
If you have the below error all you gotta do is create a 'Temp' Directory in 'C:\Windows\system32\config\systemprofile\AppData\Local' and that's it.
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\tempks1231340801626329934ks
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
at java.nio.file.Files.newByteChannel(Unknown Source)
at java.nio.file.Files.createFile(Unknown Source)
at java.nio.file.TempFileHelper.create(Unknown Source)
at java.nio.file.TempFileHelper.createTempFile(Unknown Source)
at java.nio.file.Files.createTempFile(Unknown Source)
at org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:318)
at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:219)
at org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:152)
at org.apache.directory.server.wrapper.ApacheDsTanukiWrapper.start(ApacheDsTanukiWrapper.java:175)
at org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)*
I got the same issue. I managed to solve that, and I succeeded. The solution is as follow:
Open Java settings in Control panel (Control Panel>Programs>Java on,
my case, windows 7)
The setting screen shows up. Then click on Java tab. Click View...
button
At the User tab, click on Find button
After that, you choose the folder that contains the x86 JRE.
Finally, click Finish to add that x86 Run-time Environment to be used by programs that need the x86 version to run.
That's all. Try it.
delete file C:\Program Files (x86)\ApacheDS\instances\default\conf\config.ldif