I am deploying contextbroker and when I use "-multiservice header"
as contextBroker_extra_ops option, the contextBroker is not started and not further information is obtained. Could you help me?
I am using contextBroker version 0.15.0
contextBroker -port 9999 -logDir /var/log/contextBroker -pidpath /var/log/contextBroker/contextBroker.pid -dbhost 127.0.0.1:27017 -db testdb1 -multiservice header
log directory: '/var/log/contextBroker'
DEBUG#12:59:56 paConfig.cpp[892]: setting trace levels to '0-255'
DEBUG#12:59:56 paConfig.cpp[893]: Leaving function paConfigActions
parameter 'header' not recognized
Using /etc/init.d/contextBroker I got a failure
/etc/init.d/contextBroker start
Starting...
contextBroker is stopped
Starting contextBroker... cat: /var/log/contextBroker/contextBroker.pid: No such file or directory
pidfile not found [FAILED]
The -multiservice CLI parameter changed between version 0.14.1 and 0.15.0. From 0.15.0 changelog:
# rpm -q --changelog contextBroker
* mié oct 01 2014 Fermin Galan <fermin#tid.es> 0.15.0-1 (FIWARE-3.5.3-1)
...
- Fix: made the broker not support URL-based multiservice (tenants) anymore (Issue #522)
- Fix: removed all the code related to URL-tenants (Issue #522)
...
Just replacing -multiservice header by -multiheader should solve the problem.
Related
I was trying to build an customized image of postgresql+repmgr+timescaledb on docker.
Here is my dockerfile:
FROM bitnami/postgresql-repmgr:12.4.0-debian-10-r90
USER root
RUN apt-get update \
&& apt-get -y install \
gcc cmake git clang-format clang-tidy openssl libssl-dev \
&& git clone https://github.com/timescale/timescaledb.git
RUN cd timescaledb \
&& git checkout 2.8.1 \
&& ./bootstrap -DREGRESS_CHECKS=OFF -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
&& cd build \
&& make \
&& make install
RUN echo 'en_US.UTF-8 UTF-8' >> /etc/locale.gen && locale-gen
USER 1001
build command:
docker build -f dockerfile -t my/pg-repmgr-12-tsdb:12.4.0-debian-10-r90 .
When I tested it, it ran perfectly for the primary node, but when I tried to establish a stand by node, the instance stopped almost immediately after starting up and leaving the logs to be:
postgresql-repmgr 18:51:11.00
postgresql-repmgr 18:51:11.00 Welcome to the Bitnami postgresql-repmgr container
postgresql-repmgr 18:51:11.00 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql-repmgr
postgresql-repmgr 18:51:11.00 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql-repmgr/issues
postgresql-repmgr 18:51:11.01
postgresql-repmgr 18:51:11.03 INFO ==> ** Starting PostgreSQL with Replication Manager setup **
postgresql-repmgr 18:51:11.05 INFO ==> Validating settings in REPMGR_* env vars...
postgresql-repmgr 18:51:11.06 INFO ==> Validating settings in POSTGRESQL_* env vars..
postgresql-repmgr 18:51:11.06 INFO ==> Querying all partner nodes for common upstream node...
postgresql-repmgr 18:51:11.13 INFO ==> Auto-detected primary node: 'pg-0:5432'
postgresql-repmgr 18:51:11.14 INFO ==> Preparing PostgreSQL configuration...
postgresql-repmgr 18:51:11.14 INFO ==> postgresql.conf file not detected. Generating it...
postgresql-repmgr 18:51:11.26 INFO ==> Preparing repmgr configuration...
postgresql-repmgr 18:51:11.27 INFO ==> Initializing Repmgr...
postgresql-repmgr 18:51:11.28 INFO ==> Waiting for primary node...
postgresql-repmgr 18:51:11.30 INFO ==> Cloning data from primary node...
postgresql-repmgr 18:51:12.11 INFO ==> Initializing PostgreSQL database...
postgresql-repmgr 18:51:12.11 INFO ==> Cleaning stale /bitnami/postgresql/data/standby.signal file
postgresql-repmgr 18:51:12.12 INFO ==> Custom configuration /opt/bitnami/postgresql/conf/postgresql.conf detected
postgresql-repmgr 18:51:12.13 INFO ==> Custom configuration /opt/bitnami/postgresql/conf/pg_hba.conf detected
postgresql-repmgr 18:51:12.16 INFO ==> Deploying PostgreSQL with persisted data...
postgresql-repmgr 18:51:12.19 INFO ==> Configuring replication parameters
postgresql-repmgr 18:51:12.23 INFO ==> Configuring fsync
postgresql-repmgr 18:51:12.25 INFO ==> Setting up streaming replication slave...
postgresql-repmgr 18:51:12.28 INFO ==> Starting PostgreSQL in background...
postgresql-repmgr 18:51:12.52 INFO ==> Unregistering standby node...
postgresql-repmgr 18:51:12.59 INFO ==> Registering Standby node...
postgresql-repmgr 18:51:12.64 INFO ==> Running standby follow...
postgresql-repmgr 18:51:12.71 INFO ==> Stopping PostgreSQL...
waiting for server to shut down.... done
server stopped
while normal logs continues with several restarts. The logs were confusing because no error is thrown.
Thanks to the first comment, I found that the postgres logs (which I used volumes to access later) said:
2022-10-17 12:37:51.070 GMT [171] LOG: pgaudit extension initialized
2022-10-17 12:37:51.070 GMT [171] LOG: starting PostgreSQL 12.4 on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2022-10-17 12:37:51.072 GMT [171] LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-10-17 12:37:51.072 GMT [171] LOG: listening on IPv6 address "::", port 5432
2022-10-17 12:37:51.074 GMT [171] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-10-17 12:37:51.106 GMT [171] LOG: redirecting log output to logging collector process
2022-10-17 12:37:51.106 GMT [171] HINT: Future log output will appear in directory "/opt/bitnami/postgresql/logs".
2022-10-17 12:37:51.119 GMT [173] LOG: database system was interrupted; last known up at 2022-10-17 12:37:49 GMT
2022-10-17 12:37:51.242 GMT [173] LOG: entering standby mode
2022-10-17 12:37:51.252 GMT [173] LOG: redo starts at 0/E000028
2022-10-17 12:37:51.266 GMT [173] LOG: consistent recovery state reached at 0/E000100
2022-10-17 12:37:51.266 GMT [171] LOG: database system is ready to accept read only connections
2022-10-17 12:37:51.274 GMT [177] LOG: started streaming WAL from primary at 0/F000000 on timeline 1
2022-10-17 12:37:51.579 GMT [171] LOG: received fast shutdown request
2022-10-17 12:37:51.580 GMT [171] LOG: aborting any active transactions
2022-10-17 12:37:51.580 GMT [177] FATAL: terminating walreceiver process due to administrator command
2022-10-17 12:37:51.581 GMT [174] LOG: shutting down
2022-10-17 12:37:51.601 GMT [171] LOG: database system is shut down
Can someone please tell me where I did wrong? Much appreciated!
Additional information on reproducing：
the command used for the primary node instance:
docker run --detach --name pg-0 --network my-network --env REPMGR_PARTNER_NODES=pg-0,pg-1 --env REPMGR_NODE_NAME=pg-0 --env REPMGR_NODE_NETWORK_NAME=pg-0 --env REPMGR_PRIMARY_HOST=pg-0 --env REPMGR_PASSWORD=repmgrpass --env POSTGRESQL_POSTGRES_PASSWORD=adminpassword --env POSTGRESQL_USERNAME=customuser --env POSTGRESQL_PASSWORD=custompassword --env POSTGRESQL_DATABASE=customdatabase --env POSTGRESQL_SHARED_PRELOAD_LIBRARIES=repmgr,pgaudit,timescaledb -p 5420:5432 -v /etc/localtime:/etc/localtime:ro my/pg-repmgr-12-tsdb:12.4.0-debian-10-r90
the command used for the standby node instance:
docker run --name pg-1 --network my-network --env REPMGR_PARTNER_NODES=pg-0,pg-1 --env REPMGR_NODE_NAME=pg-1 --env REPMGR_NODE_NETWORK_NAME=pg-1 --env REPMGR_PRIMARY_HOST=pg-0 --env REPMGR_PASSWORD=repmgrpass --env POSTGRESQL_POSTGRES_PASSWORD=adminpassword --env POSTGRESQL_USERNAME=customuser --env POSTGRESQL_PASSWORD=custompassword --env POSTGRESQL_DATABASE=customdatabase --env POSTGRESQL_SHARED_PRELOAD_LIBRARIES=repmgr,pgaudit,timescaledb -v /etc/localtime:/etc/localtime:ro -p 5421:5432 my/pg-repmgr-12-tsdb:12.4.0-debian-10-r90
Sometimes the best way through is just to find another...
I changed the dockerfile to
FROM bitnami/postgresql-repmgr:13.6.0-debian-10-r90
USER root
RUN apt-get update \
&& apt-get -y install \
gcc cmake git clang-format clang-tidy openssl libssl-dev \
&& git clone https://github.com/timescale/timescaledb.git
RUN cd timescaledb \
&& git checkout 2.8.0 \
&& ./bootstrap -DREGRESS_CHECKS=OFF -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
&& cd build \
&& make \
&& make install
RUN echo 'en_US.UTF-8 UTF-8' >> /etc/locale.gen && locale-gen
USER 1001
and the problem is solved.
I even have no clue whether the version of base image or the version of timescaledb did the magic, but anyhow my problem is solved. Hope any one who encountered the same issue later can benefit from my struggle. >3<
I'm running an MQTT server mosquitto version 2.0.11 on the same Raspberry Pi Bullseye (3 A+) as both broker and client. I had code working, but understand that one needs to modify a .conf file to get things working. I must still not be understanding something because here's my file:
# I had pid_file /run/mosquitto/mosquitto.pid below, but changed this when docs suggested below should be included if running automatically when device boots, which it will be.
pid_file /var/run/mosquitto/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
listener 1883
allow_anonymous true
Now when I try to run mosquitto like this:
mosquitto -c /etc/mosquitto/conf.d/mosquitto.conf
I get this error:
1637370455: Loading config file /etc/mosquitto/conf.d/mosquitto.conf
1637370455: Error: Duplicate pid_file value in configuration.
1637370455: Error found at /etc/mosquitto/conf.d/mosquitto.conf:7.
1637370455: Error found at /etc/mosquitto/conf.d/mosquitto.conf:14.
Line 7 is the pid_file /var/run/mosquitto/mosquitto.pid
Line 14 is the include_dir /etc/mosquitto/conf.d
I can make basic pub and sub tests with localhost but still no luck with the hostname. Yes I know you should use security but I have an app that controls a robot over local WiFi and want to preserve app usage without changing that component too.
Any help on getting me back on track to getting the Mosquitto broker & client working on the same pi, allowing anonymous access, and running, is much appreciated. I hav gone through the docs, example file, and consulted other tutorials like Steve’s but proper configuration is still unclear. Thx!
Firstly the errors about not being able to open the pid or log files are because you are running mosquitto as a normal user (probably pi). This user does not have permission to read/write to file in /var/run or /var/log hence the failure when you try and run it "manually".
You've not said how you installed 2.0.11, as the default version bundled with Bullseys is still a 1.5.x build. Assuming you used the mosquitto.org repository then the mosquitto service will have been installed and configured. It will automatically pick up the default config file at /etc/mosquitto/mosquitto.conf as should be displayed with:
$ sudo service mosquitto status
● mosquitto.service - Mosquitto MQTT Broker
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset
Active: active (running) since Sun 2021-10-31 17:28:52 GMT; 2 weeks 5 days ag
Docs: man:mosquitto.conf(5)
man:mosquitto(8)
Process: 499 ExecStartPre=/bin/mkdir -m 740 -p /var/log/mosquitto (code=exited
Process: 505 ExecStartPre=/bin/chown mosquitto /var/log/mosquitto (code=exited
Process: 507 ExecStartPre=/bin/mkdir -m 740 -p /run/mosquitto (code=exited, st
Process: 510 ExecStartPre=/bin/chown mosquitto /run/mosquitto (code=exited, st
Process: 25679 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCE
Main PID: 511 (mosquitto)
Tasks: 1 (limit: 2181)
CGroup: /system.slice/mosquitto.service
└─511 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Nov 19 00:00:10 www systemd[1]: Reloading Mosquitto MQTT Broker.
Nov 19 00:00:10 www systemd[1]: Reloaded Mosquitto MQTT Broker.
Warning: Journal has been rotated since unit was started. Log output is incomple
The simplest way to enable access from other machines is to do the following:
Reset the default config file to as it was when installed
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
port 1883
include_dir /etc/mosquitto/conf.d
create a new file in /etc/mosquitto/conf.d e.g. called connect.conf
listener 1883
allow_anonymous true
restart the service with sudo service mosquitto restart
I am trying to implement the BYFN Hyperledger example form my Windows 10 Linux Subsystem (Ubuntu Xenial). However, the ./byfn.sh -m up command fails with the following output:
$GOPATH/fabric-samples/first-network$ ./byfn.sh -m up
Starting with channel 'mychannel' and CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
2018-04-24 22:12:44.343 UTC [main] main -> INFO 001 Exiting.....
LOCAL_VERSION=1.1.0
DOCKER_IMAGE_VERSION=1.1.0
Creating peer0.org1.example.com ... done
Creating orderer.example.com ... done
Creating peer1.org1.example.com ... done
Creating peer0.org2.example.com ... done
Creating peer1.org2.example.com ... done
Creating cli ... done
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"scripts/script.sh\": stat scripts/script.sh: no such file or directory": unknown
ERROR !!!! Test failed
I see that only one container is built:
$GOPATH/fabric-samples/first-network$ dps
CONTAINER ID NAMES NETWORKS STATUS SIZE
3e66d31c6b9a cli net_byfn Up 27 minutes 17B (virtual 1.46GB)
From the output it seems that the cli container cannot see the script.sh script. Thinking this maybe a docker-compose volume-bind issue I tried to check the binds in the cli container:
$GOPATH/fabric-samples/first-network$ docker exec -ti cli bash
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# ls scripts/
root#3e66d31c6b9a:/opt/gopath/src/github.com/hyperledger/fabric/peer# exit
exit
$GOPATH/fabric-samples/first-network$ ls scripts/
capabilities.json script.sh step1org3.sh step2org3.sh step3org3.sh testorg3.sh upgrade_to_v11.sh utils.sh
Looking at the the docker-compose-cli.yaml file I see the following binds for the cli container:
volumes:
- /var/run/:/host/var/run/
- ./../chaincode/:/opt/gopath/src/github.com/chaincode
- ./crypto-config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
- ./scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
- ./channel-artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
My Docker settings:
$GOPATH/fabric-samples/first-network$ docker version
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.2
Git commit: 0520e24
Built: Wed Mar 21 23:05:52 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: false
$GOPATH/fabric-samples/first-network$ docker-compose version
docker-compose version 1.21.0, build 5920eb0
docker-py version: 3.2.1
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
My Go version:
$GOPATH/fabric-samples/first-network$ go version
go version go1.10.1 linux/amd64
Wondering if I'm missing something. I should mention that I used the following command to start form scratch, based on a fresh set of images (no prior images) as outlined in this script:
curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s 1.1.0
Thanks
Its most probably the version of golang---Fabric needs go version 1.9.x and the error message exec failed: container_linux.go:348: indicates the same thing.
In my case, it was the first Note on this page https://hyperledger-fabric.readthedocs.io/en/latest/install.html
I'm running on Windows 10, but Docker won't work since i need Windows 10 Pro or better to run it. So i'm using Docker Toolbox, and must follow the Windows 7 trick of cloning the sources anywhere under C:\Users
While trying to run a puppet update form a node:
sudo /opt/puppetlabs/bin/puppet agent -t
I get an error:
Error: Could not retrieve catalog; skipping run
Error: Could not send report: Connection refused - connect(2) for "puppet" port 8140`
Elsewhere indicates this is likely a problem with the puppetserver service, and suggests to reboot the server. Restarting didn't help, and when I try to restart the service I get failure:
~$ sudo service puppetserver restart
Job for puppetserver.service failed because the control process exited with error code. See "systemctl status puppetserver.service" and "journalctl -xe" for details.
I've looked at these logs, and as a puppet/linux noob, I'm not sure what to do next.
systemctl status puppetserver.service
● puppetserver.service - puppetserver Service
Loaded: loaded (/lib/systemd/system/puppetserver.service; enabled; vendor preset: enabled)
Active: activating (start-post) since Fri 2016-09-02 15:54:26 PDT; 2s ago
Process: 22301 ExecStartPre=/usr/bin/install --directory --owner=puppet --group=puppet --mode=775 /var/run/puppetlabs/puppetserver (code=exited
Main PID: 22306 (java); : 22307 (bash)
Tasks: 17
Memory: 335.7M
CPU: 5.535s
CGroup: /system.slice/puppetserver.service
├─22306 /usr/bin/java -Xms6g -Xmx6g -XX:MaxPermSize=256m -XX:OnOutOfMemoryError=kill -9 %p -Djava.security.egd=/dev/urandom -cp /opt/p
└─control
├─22307 /bin/bash /opt/puppetlabs/server/apps/puppetserver/ezbake-functions.sh wait_for_app
└─22331 sleep 1
Sep 02 15:54:26 puppet systemd[1]: Starting puppetserver Service...
Sep 02 15:54:26 puppet java[22306]: OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
puppet version 4.6.1
The puppet master communicates with the other node using port number 8140.
I don't think a restart will help, since this looks like a connection issue between the server and the node.
please try the following -
first make sure that the puppet master is actually listening on port 8140. run the following command on the puppetmaster -
netstat -ntlp | grep 8140
this command should return something like this -
tcp 0 0 0.0.0.0:8140 0.0.0.0:* LISTEN 1783/puppetmaster
If you don't get the same output, your puppetmaster is not listening, and therefore can not compile catalogs for the node.
Try checking the puppet master log at /var/log/puppetmaster.log
check that the node can communicate with the puppetmaster on the relevant port. you can check this quickly with the telnet command. run this on your node -
telnet < puppetmaster ip address \ dns name> 8140
you should get something like -
Connected to <puppet-master-IP/DNS-name>
Escape character is '^]'.
if you don't get this output, this means that something is blocking you from accessing the puppetmaster. try opening the port in your firewall to access the puppetmaster.
if you're still stuck try using the --debug flag for verbose output and edit your question.
Could be 2 things: (1) in puppet.conf you have configured more memory than you have on your machine. Or (2) You installed both apt-get install puppetserver and apt-get install puppet.
If you get failed to start puppet.service: unit not found. error on slave machine while connecting to puppet.
Close the putty and then again open and connect it.The issue wont come while starting putty on slave.
The error occurs because there is not enough RAM and to fix the error, open the Puppet server configuration file:
sudo nano /etc/sysconfig/puppetserver
And reduce the amount of allocated RAM for the Puppet server (for example, I specified 512m instead of 2g):
JAVA_ARGS="-Xms512m -Xmx512m"
Now let’s start the Puppet server:
sudo systemctl start puppetserver
Newcomer to postgres here!
I edited pg_hba.conf as mentioned here , but when I try to restart postgresql service, the attempt fails. Below is the command line output with all the information I could gather.
[root#arunpc modules]# service postgresql restart
Redirecting to /bin/systemctl restart postgresql.service
Job failed. See system logs and 'systemctl status' for details.
[root#arunpc modules]# systemctl status postgresql.service
postgresql.service - PostgreSQL database server
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: failed since Sun, 08 Apr 2012 21:29:06 +0530; 14s ago
Process: 12228 ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=0/SUCCESS)
Process: 12677 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=1/FAILURE)
Process: 12672 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 12184 (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/postgresql.service
[root#arunpc modules]# tail /var/log/messages
....
Apr 8 21:29:06 arunpc systemd[1]: postgresql.service: control process exited, code=exited status=1
Apr 8 21:29:06 arunpc systemd[1]: Unit postgresql.service entered failed state.
Apr 8 21:29:06 arunpc pg_ctl[12677]: pg_ctl: could not start server
Apr 8 21:29:06 arunpc pg_ctl[12677]: Examine the log output.
FWIW, here is the configuration file (pg_hba.conf) used:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all postgres ident sameuser
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1 password
# IPv6 local connections:
host all all ::1 password
What could be the error here? It used to work fine before I made the edit (and since this was a development machine, I brilliantly didn't make any backup).
I would also like to get a more detailed log output. The log message in /var/log/messages file does ask me to "Examine the log output" - which log output would this be? What other troubleshooting steps can I take?
Many thanks in advance!
Depending on your startup script, it might redirect the postmaster's output to a file. This is usually server.log in the PGDATA directory. Things I'd try:
Comment out everything in pg_hba.conf and retry. If the problem is a syntax error in that file, then commenting out the offending line will allow the server to start and then you'll be able to uncomment one at a time until you find the error.
Start postmaster directly from the shell without sending it to the background. Just run postmaster -D <pgdata dir> and it should spew some more helpful logs.