I am trying to resolve a cobbler issue, request your help/guidance on the same. we have spacewalk with cobbler. when I add a new host and do a cobbler sync, i am getting the below error and TASK FAILED.
rendering DHCP files
generating /etc/dhcp/dhcpd.conf
Exception occured: <class 'cexceptions.CX'>
Exception value: 'Error templating file, check cobbler.log for more details'
when I cross check the cobbler.log, these entries were recorded...
Mon Apr 25 14:44:45 2016 - WARNING | errors were encountered rendering the template
Mon Apr 25 14:44:45 2016 - WARNING |
[{'code': u'VFFSL(SL,"net0",True)/mac',
'exc_val': NotFound("cannot find 'net0'",),
'lineCol': (2, 11),
'rawCode': u'${net0/mac}',
'time': 'Mon Apr 25 14:44:45 2016'}]
Thanks
Nandakumar
we found its was a profile with the system Profile with a wrong name, which was stopping creating the dhcpd.conf file. After removing the particular system profile, everything works well.
Thanks
Nandakumar
Related
I've got a plain vanilla install of ignite 2.14, with the binaries downloaded from https://ignite.apache.org/download.cgi (exact link https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip). I'm on Windows 10, IGNITE_HOME is not set in the PATH (this is optional), and Ignite's using this java runtime:
OpenJDK Runtime Environment 1.8.0_201-2-redhat-b09 Oracle Corporation
OpenJDK 64-Bit Server VM 25.201-b09
I start an ignite node using the default configuration provided in the downloaded zip apache-ignite-2.14.0-bin.zip :
ignite.bat ..\config\default-config.xml
This starts fine. Following the instructions at https://ignite.apache.org/docs/latest/tools/control-script I can check the state and see I've got a single node cluster in state ACTIVE (the default-config.xml must not have native persistence enabled, so the cluster goes to ACTIVE state automatically).
I can then set the state to INACTIVE like so:
control.bat --set-state INACTIVE
This works fine. However if I set the state to active again like so:
control.bat --set-state ACTIVE
I get the error pasted below and the cluster stays in the INACTIVE state. I first came across this error when using Ignite in embedded server mode, but I can still reproduce it with a fresh out-of-the-box ignite install (not using embedded). I'm surprised that a plain vanilla install just calling a couple of basic commands falls over like this. Any idea what's happening?
This is the error:
C:\temp\apache-ignite-2.14.0-bin\bin>control.bat --set-state ACTIVE
Nov 17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
INFO: Client TCP connection established: /127.0.0.1:11211 Nov
17, 2022 4:27:17 PM
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection
close INFO: Client TCP connection closed: /127.0.0.1:11211 Nov 17,
2022 4:27:17 PM org.apache.ignite.internal.client.util.GridClientUtils
shutdownNow WARNING: Runnable tasks outlived thread pool executor
service [owner=GridClientConnectionManager,
tasks=[java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask#6d7b4f4c]]
Control utility [ver. 2.14.0#20220929-sha1:951e8deb] 2022 Copyright(C)
Apache Software Foundation User: info Time: 2022-11-17T16:27:16.344
null suppressed:
Command [SET-STATE] finished with code: 4 Error stack trace: class
org.apache.ignite.internal.client.GridClientException: null
suppressed:
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:632)
at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:563)
at org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:691)
at org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116)
at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3734)
at org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1211)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2508)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2273)
at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
Control utility has completed execution at: 2022-11-17T16:27:17.642
Execution time: 1298 ms Press any key to continue . . .
It's a known issue, which is, unfortunately, not fixed yet.
As a workaround, you can execute the command with the autoconfirmation flag --yes, as shown below:
control.bat --set-state ACTIVE --yes
I'm developing an automation script and I'm getting the next error:
ImportError: No module named socket in at line number 2
I'm using jython 2.7, maximo 7.6.
Someone knows a workaround? I know that not every package is installed as it were in python and as it seems the socket pckg is one of the not installed...
I was able to view the Maximo contents of the Maximo jython.jar (or any .jar file) by executing the following command as administrator at the command prompt on a Windows server:
assoc .jar=CompressedFolder
With that I was able to locate and browse the Lib folder within the jython.jar on a Windows server Websphere implementation at the following location:
C:\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\installedApps\ctgCell01\MAXIMO.ear\lib\jython.jar\Lib
The socket.py module exists there so it should be possible to use it from within Jython in Maximo. It appears to be a version specifically written for Jython and references the following in the .py file:
https://wiki.python.org/jython/NewSocketModule
In vanilla Maximo 7.6.0 it appears the Jython path does not include the Lib folder of the jython.jar referenced above. You can find details of how to add it to the path programmatically in an automation script here:
https://expertinmaximo.wordpress.com/2016/08/26/import-python-libraries-to-use-in-automation-scripts/
Once that is done you should be able to import the socket library and use it in your script for example:
from java.lang import System
import sys
# Required : Appending to sys.path to refer to python libraries
if sys.path.count('__pyclasspath__/Lib') == 1:
service.log('\nPath to /Lib already exists\n')
else :
service.log('\nExtend path to /Lib \n')
sys.path.append('__pyclasspath__/Lib')
import socket
try:
#create an AF_INET, STREAM socket (TCP)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
service.log('\nsocket created\n')
except socket.error, msg:
service.log('\nFailed to create socket. Error code: ' + str(msg[0]) + ' , Error message : ' + msg[1] + '\n')
Once that is executed you should see similar to the following in the log (provided autoscript logging is functioning):
07 Jun 2020 15:18:04:949 [DEBUG] putting System value <type 'java.lang.System'>
07 Jun 2020 15:18:04:949 [DEBUG] putting sys value <module 'sys' (built-in)>
07 Jun 2020 15:18:04:949 [DEBUG] getting sys
07 Jun 2020 15:18:04:949 [DEBUG] putting socket value <module 'socket' from '__pyclasspath__/Lib/socket.py'>
07 Jun 2020 15:18:04:949 [DEBUG] getting socket
07 Jun 2020 15:18:04:949 [DEBUG] getting socket
07 Jun 2020 15:18:04:949 [DEBUG] getting socket
07 Jun 2020 15:18:04:949 [DEBUG] putting s value <socket._socketobject object at 0x5>
07 Jun 2020 15:18:04:949 [DEBUG] execution completed for cached compiled script MXC_SOCKET for launch point MXC_SOCKET_LP
07 Jun 2020 15:18:04:949 [DEBUG] Path to /Lib already existssocket created
I suggest using Java libraries to do what you want. All of the Java libraries needed to build Maximo are waiting for your call. This will also reduce the risk of compatibility problems if you want to send data back to Maximo.
Today I ran into the same problem but solved it rather quickly using Java libraries instead of Python. Here's a function I wrote that returns all IP addresses of a host name as a set:
from java.net import InetAddress
def getIpAddress(hostName):
hostIpAddresses = set()
try:
service.log_debug("DNS querying the host name: " + hostName)
hosts = InetAddress.getAllByName(hostName)
for i in range(len(hosts)):
hostIpAddresses.add(str(hosts[i].getHostAddress()))
service.log_debug("Address found: " + str(hostIpAddresses))
return hostIpAddresses
except:
return "NOT FOUND"
I am running Spoon - Pentaho EE V 6.1 on my laptop (8 GB RAM) and allocated 4 G to Spoon. Still it takes 3 minutes and 30 seconds to start. I dont have any plugins and my plugins directory is empty. I have also tried this by closing all applications and processes but with no luck. Am I missing anything obvious?
Sep 22, 2017 10:15:13 AM org.apache.cxf.bus.osgi.CXFExtensionBundleListener addExtensions
INFO: Adding the extensions from bundle org.apache.cxf.cxf-rt-javascript (208) [org.apache.cxf.javascript.JavascriptServerListener]
Sep 22, 2017 10:15:13 AM org.pentaho.caching.impl.PentahoCacheManagerFactory$Reg
istrationHandler$1 onSuccess
INFO: New Caching Service registered
2017/09/22 10:15:27 - General - Logging plugin type found with ID: CheckpointLog Table
2017/09/22 10:18:00,201 ERROR [KarafLifecycleListener] Error in Blueprint Watcher org.pentaho.osgi.api.IKarafBlueprintWatcher$BlueprintWatcherException: Unknown error in KarafBlueprintWatcher at org.pentaho.osgi.impl.KarafBlueprintWatcherImpl.waitForBlueprint(KarafBlueprintWatcherImpl.java:103) at org.pentaho.di.osgi.KarafLifecycleListener$2.run(KarafLifecycleListen er.java:161) at java.lang.Thread.run(Unknown Source)
Caused by: org.pentaho.osgi.api.IKarafBlueprintWatcher$BlueprintWatcherException : Timed out waiting for blueprints to load: pdi-dataservice-server-plugin,pentaho-big-data-impl-shim-initializer,pentaho-big-data-impl-shim-hdfs,pentaho-big-data-impl-shim-hbase,pentaho-big-data-impl-shim-mapreduce,pentaho-big-data-impl-shim-pig,pentaho-big-data-impl-shim-oozie,pentaho-big-data-impl-shim-sqoop,pentaho-big-data-impl-vfs-hdfs,pentaho-big-data-kettle-plugins-common-named-cluster-bridge,pentaho-big-data-kettle-plugins-guiTestActionHandlers,pentaho-big-data-kettle-plugins-hdfs,pentaho-big-data-kettle-plugins-hbase,pentaho-big-data-kettle-plugins-mapreduce,pentaho-big-data-kettle-plugins-pig,pentaho-big-data-kettle-plugins-oozie,pentaho-big-data-kettle-plugins-sqoop,pentaho-hadoop-shims-mapr-osgi-jaas,pentaho-big-data-impl-clusterTests,pentaho-big-data-impl-shim-shimTests,pentaho-yarn-api,pentaho-yarn-impl-shim,pentaho-yarn-kettle-plugin,pentaho-metaverse-core,pentaho-metaverse-web,pentaho-requirejs-osgi-manager,pentaho-angular-bundle,common-ui-6.1.0.1,pentaho-marketplace-di at org.pentaho.osgi.impl.KarafBlueprintWatcherImpl.waitForBlueprint(KarafBlueprintWatcherImpl.java:88)
... 2 more
2017/09/22 10:18:42 - General - Starting agile-bi
2017/09/22 10:18:43 - class org.pentaho.agilebi.platform.JettyServer - WebServer.Log.CreateListener localhost:10001
Finally found the answer. Its a known issue and fixed under Version 7
There seems to be a timing issue in the Karaf Blueprint Watcher where sometimes it will ask a bundle for its blueprint file before the bundle is in RESOLVED state. This triggers a (usually) parallel resolve that causes the bundle to be destroyed immediately after creation.
http://jira.pentaho.com/browse/PDI-15488
http://jira.pentaho.com/browse/PDI-14698
http://jira.pentaho.com/browse/PDI-15574
When I run my playframework2 web application using IntelliJ idea
[frontend] $ run 9000
I get this error message:
Path(C:\Users\Dell\IdeaProjects\frontend\logs\application.log) is not a directory so descendants can not be called on itis not a directory
[trace] Stack trace suppressed: run last compile:run for the full output.
[error] (compile:run) java.lang.reflect.InvocationTargetException
[error] Total time: 2 s, completed 17 avr. 2015 23:22:42
Seems to do with incorrectly terminated Java/JVM.
Try seeing if you can find something like a zombie Java instance in the process manager, or alternatively try again after a reboot.
I have encountered a problem with running Jboss as service on Fedora. Here is the log I have after using command: systemctl status jboss-as.service
Here is the log I have been receiving:
jboss-as.service - SYSV: JBoss AS Standalone
Loaded: loaded (/etc/rc.d/init.d/jboss-as)
Active: failed (Result: resources) since Thu 2014-01-16 09:31:54 CET; 46min ago
Process: 501 ExecStart=/etc/rc.d/init.d/jboss-as start (code=exited, status=0/SUCCESS)
Jan 16 09:31:22 servername.domain systemd[1]: Starting SYSV: JBoss AS Standalone...
Jan 16 09:31:23 servername.domain jboss-as[501]: Starting jboss-as: chown: missing operand after ‘/var/run/jboss-as’
Jan 16 09:31:23 servername.domain jboss-as[501]: Try 'chown --help' for more information.
Jan 16 09:31:54 servername.domain jboss-as[501]: [ OK ]
Jan 16 09:31:54 servername.domain systemd[1]: PID file /var/run/jboss-as/jboss-as-standalone.pid not readable (yet?) after start.
Jan 16 09:31:54 servername.domain systemd[1]: Failed to start SYSV: JBoss AS Standalone.
Jan 16 09:31:54 servername.domain systemd[1]: Unit jboss-as.service entered failed state.
First, I tried to find a solution for the chown: missin operand after ... problem and found something: here but it did not help. And also, I was looking for the answer for the PID file problem but it does not even exist in in the location: var/run/jboss-as/
This is because the startup script uses the variable $JBOSS_USER but it is not defined inside the script.
Please put in the file /etc/jboss-as/jboss-as.conf the following line:
JBOSS_USER=root
(change the root with other dedicated linux user e.g. jboss-as)
It looks like the service startup script expects to be able to write to the /var/run/jboss-as directory but doesn't have permissions to do so.
In your place I'd ensure that this directory is owned by the user that runs JBoss and that it is writable.
Check that there aren't other errors (particularly missing or incorrect paths) in your /etc/rc.d/init.d/jboss-as file (I assume you copied it from the jboss install folder to create a startup script.
I had the same issue until I fixed a completely unrelated link in that script, then it went away.
In Centos 7, if you straight way copying the jboss-as-standalone.sh in /etc/rc.d/init.d/, ensure JBOSS_CONF and JBOSS_HOME path is correct.
For me, it was with systemd. When I set the service y put wrong the PID File.
Example:
In the service was like
/var/run/jboss-as/jboss-as-standalone.pid
But in the script was like
/var/run/jboss-as/jboss-as.pid