I'm trying to deploy contextBroker using the command /etc/init.d/contextBroker and I get the following error:
Starting...
contextBroker is stopped
Starting contextBroker... su: user orion does not exist
cat: /var/log/contextBroker/contextBroker.pid: No such file or directory
pidfile not found [FAILED]
Using the following command I can start contextBroker:
/usr/bin/contextBroker -port 10026 -logDir /var/log/contextBroker
-pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion
Which could be the cause of the problem?
There was a bug in the Orion RPM fixed in 0.16.0 that causes the removal of the "orion" user when updating the RPM package. The "orion" user is the one used by default by the /etc/init.d/contextBroker script, thus causing the error message su: user orion does not exist.
Note that although the bug has been fixed in 0.16.0, updating from 0.15.0 (for instance) to 0.16.0 will be problematic, as the version being updated (0.15.0) is still "buggy". Updating from 0.16.0 to any newer version (e.g. upcoming 0.17.0) should work without problem.
Fortunatelly, the problem has an easy solution: instead of updating the package, remove it and install again, typically with:
yum remove contextBroker
yum install contextBroker
Related
On Centos, I ran into the following error:
sudo snmptrap -v 2c -c read localhost '' UPS-MIB::upsTraps
MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs
Cannot find module (UPS-MIB): At line 0 in (none)
UPS-MIB::upsTraps: Unknown Object Identifier
The above error happened after
Copied UPS-MIB.txt to /usr/share/snmp/mibs
I started snmptrapd:
snmptrapd -f -Lo -Dread-config -m ALL
The version of the Net-SNMP is 5.2.x.
The same procedures work fine with Ubuntu 18.04/Net-SNMP 5.3.7.
I wonder how to debug and fix the problem?
Besides the Net-SNMP version difference, on Ubuntu, I found an instruction to install mib-download-tool, and execute it after the installation of Net-SNMP, and comment out the lines beginning with min: in snmp.conf in order to fix the error of missing MIB's.
However, for the Centos, I had no need and found no such instruction, thus I have not done it yet, as there is no error message of missing MIB's.
The MIB file is downloaded from https://tools.ietf.org/rfc/rfc1628.txt
renamed to UPS-MIB.txt (It seems to me that the name of the MIB file does not matter, as long as it's unique? I tried to use a different names, upsMIB.txt, rfc1628.txt, but it does not help to improve.)
I solved the problem as follows:
manually copied /usr/share/snmp/mibs/ietf/UPS-MIB on an Ubuntu with Net-SNMP 5.7.3 installed to the Centos /usr/share/snmp/mibs/UPS-MIB
then restart the snmpd
by the command:
service snmpd restart
then the OID of UPS-MIB becomes visible and accessible.
Maybe, the version that I downloaded from https://tools.ietf.org/rfc/rfc1628.txt is not suitable??
I have Docker installed under CentOS Linux 7.6.1810 and Plesk Onyx 17.8.11, and everything was fine. For a few hours I can't start mongoDB or Docker anymore.
I get this error message
{"message":"OCI runtime create failed: container_linux.go:344: starting container process caused \"process_linux.go:297: getting the final child's pid from pipe caused \\\"read init-p: connection reset by peer\\\"\": unknown"}
What could it be?
I have fixed it, I downgraded containerd.io to the version 1.2.0 and Docker is running.
Docker-ce 18.09.2 + Linux Kernel 3.10.0 produces the same problem as you. If we want to use Docker-ce 18.09.2, Linux Kernel 4.x+ is required.
We have keycloak 3.2.0 working on Docker.
When we run it, we add the ARGS --server-config standalone-ha.xml
e.g
Docker run foo bar jboss/keycloak:4.5.0.Final --server-config standalone-ha.xml
Purely because we're running a few nodes to the same DB
Upgrading to 4.5, the documentation here:
https://www.keycloak.org/docs/latest/server_installation/index.html#_standalone-ha-mode
Says, also add
--server-config standalone-ha.xml
However, when i do that (From version 4.0 onwards), i get
21:12:03,574 INFO [org.jboss.modules] (main) JBoss Modules version 1.8.6.Final
java.lang.IllegalArgumentException: WFLYSRV0191: Can't use both --server-config and --initial-server-config
at org.jboss.as.server.Main.assertSingleConfig(Main.java:395)
at org.jboss.as.server.Main.determineEnvironment(Main.java:169)
at org.jboss.as.server.Main.main(Main.java:96)
at org.jboss.modules.Module.run(Module.java:352)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:593)
21:12:03,973 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
Now, if i run keycloak WITHOUT --server-config, and i enter the container, PS AUX shows its running standalone-ha.xml as config.
But thats because we are migrating from a DB which has 3.2.0 previously installed.
How do i enable and constantly make sure that standalone-ha.xml gets selected by passing parameter --server-config to choose the *-ha.xml configuration?
Thanks
It is a problem in Keycloak. Using -c instead of --server-config helps.
See https://issues.jboss.org/browse/KEYCLOAK-9393 for more details.
I've been installing Ceilometer for Openstack Pike on Ubuntu 16.04 LTS using this install guide.
Everything went ok, up to the moment, when but when I've tried to restart gnocchi-api I got message
Failed to start gnocchi-api.service: Unit gnocchi-api.service not found.
I checked /etc/init.d and there is no script gnocchi-api (although gnocchi-metricd is, and it's working properly). Tried reinstalling package gnocchi-api, but it didn't help. When starting gnocchi-api normally, from the command line it works, although sends a bunch of warnings (but I think they are common)
I'm looking for a way to make it work normally - like a service and using conf file.
2017-11-27 20:01:40.593 6059 INFO gnocchi.rest.app [-] WSGI config used: /usr/lib/python2.7/dist-packages/gnocchi/rest/api-paste.ini
2017-11-27 20:01:40.753 6059 WARNING keystonemiddleware._common.config [-] The option "__file__" in conf is not known to auth_token
2017-11-27 20:01:40.759 6059 WARNING keystonemiddleware._common.config [-] The option "configkey" in conf is not known to auth_token
2017-11-27 20:01:40.760 6059 WARNING keystonemiddleware._common.config [-] The option "here" in conf is not known to auth_token
2017-11-27 20:01:40.762 6059 WARNING keystonemiddleware.auth_token [-] AuthToken middleware is set with keystone_authtoken.service_token_roles_required set to False. This is backwards compatible but deprecated behaviour. Please set this to True.
2017-11-27 20:01:40.768 6059 WARNING keystonemiddleware.auth_token [-] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint
STARTING test server gnocchi.rest.app.build_wsgi_app
Available at http://127.0.1.1:8000/
DANGER! For testing only, do not use in production
apt-get currently pulls version 3.1.9 of gnocchi-api. If you manually install gnocchi-api 3.1.2, this service file is very much there in it.
service gnocchi-api start works fine with this.
But I am not sure if functionality is ok or if this is an intended change with 3.1.9.. Still to check these.
This is the same on the latest version on Ubuntu 16.04 / gnocchi version 4.2.0
Confirmed bug as of now: https://bugs.launchpad.net/ceilometer/+bug/1750933
gnocchi-api.service unit cannot be started as it has not been created.
Just after the install of the Context Broker I've tried to test it creating a new entity as described in the session Entity Creation of https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide, but I'm getting a "connection reset by peer" error.
The log doesn't seem say anything, even I raised the level of traces with -t 0-255 option.
Aditional info:
$ contextBroker --version
0.14.0
$ ps aux | grep context
/usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion -t 0-255
The issue was fixed updating the Context Broker to a newer version, in my case to version 0.14.1, which can be found here: http://repositories.testbed.fi-ware.org/repo/rpm/x86_64/.
I can't say exactly what was wrong, since after updating everything was working fine.