I've followed the instructions in this Redhat Bugfix article, that is I did the following (I realize this is a Redhat fix)
Create a /etc/systemd/system/systemd-logind.service file
put the following lines in the file
.include /lib/systemd/system/systemd-logind.service
[Service]
Environment=SYSTEMD_LOG_LEVEL=warning
Restarted the rsyslog and systemd-logind services
Yet I still see systemd logs spamming /var/log/messages. Anything else I need to do in a CentOS box? Here's a sample
<30>1 2016-08-23T13:09:48-04:00 susralcent09 systemd - - - Starting Flush Journal to Persistent Storage...
<30>1 2016-08-23T12:48:37-04:00 susralcent09 systemd - - - Started System Logging Service.
<30>1 2016-08-23T12:48:36-04:00 susralcent09 systemd - - - Stopping System Logging Service...
<30>1 2016-08-23T12:48:36-04:00 susralcent09 systemd - - - Starting System Logging Service...
...and
<30>1 2016-08-23T13:01:01-04:00 susralcent09 systemd - - - Created slice user-0.slice.
<30>1 2016-08-23T13:01:01-04:00 susralcent09 systemd - - - Started Session 2 of user root.
<30>1 2016-08-23T13:09:48-04:00 susralcent09 systemd - - - Started Flush Journal to Persistent Storage.
<30>1 2016-08-23T13:01:01-04:00 susralcent09 systemd - - - Starting Session 2 of user root.
<30>1 2016-08-23T13:01:01-04:00 susralcent09 systemd - - - Starting user-0.slice.
Related
This is a very strange situation that's driving me nuts, and I would really appreciate some help here.
I am using CDK to define the DynamoDB table and associated indices. To test them locally, I installed cdklocal and DynamoDB local using localstack. When the computer (Mac running Ventura 13.1) is restarted, everything works as expected. Here is the script I use to bootstrap and start the stack (this is in a file called startStack.sh):
docker-compose up -d
echo "Waiting for 5 seconds"
sleep 5
cd test-app
cdklocal bootstrap
echo "Waiting for 5 seconds"
sleep 5
cdklocal deploy TestAppStack
#cdklocal deploy TestAppStack/ops-table
DYNAMO_ENDPOINT="http://localhost:4566/" dynamodb-admin &
open http://0.0.0.0:8001
cd ..
The test-app directory contains a local copy of the DynamoDB (and associated indices) definition. I do not encounter any errors running the cdklocal (or cdk) deploy commands so I am assuming that the CDK definition is not an issue.
The docker-compose looks like this:
version: "3.8"
services:
localstack:
container_name: AWS-DEVELOPMENT-WITH-LOCALSTACK
image: localstack/localstack:latest
network_mode: bridge
ports:
- "127.0.0.1:53:53"
- "127.0.0.1:53:53/udp"
- "127.0.0.1:443:443"
- "127.0.0.1:4566:4566"
- "127.0.0.1:4571:4571"
- "127.0.0.1:${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"
environment:
- DYNAMODB_SHARE_DB=1
- DISABLE_CORS_CHECKS=1
- SERVICES=s3,dynamodb,sns,sqs,firehose,kinesis,ses,sts,cloudformation
- DEBUG=1
- DATA_DIR=/tmp/localstack/data
- PORT_WEB_UI=8080
- LAMBDA_EXECUTOR=local
- KINESIS_ERROR_PROBABILITY=1.0
- DOCKER_HOST=unix:///var/run/docker.sock
- HOST_TMP_FOLDER=./.localstack
volumes:
- './.localstack:/var/lib/localstack'
- '/var/run/docker.sock:/var/run/docker.sock'
Everything works as expected when I first run the startStack.sh file - the dynamodb-admin window opens up correctly and other interfaces can interact with the local DynamoDB table. But after some time (and I have not been able to pinpoint the cause), all interactions with local DynamoDB start failing with the following error(s):
Bootstrapping environment aws://000000000000/us-west-2...
❌ Environment aws://000000000000/us-west-2 failed bootstrapping: UnknownEndpoint: Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
at Request.ENOTFOUND_ERROR (/usr/local/lib/node_modules/aws-sdk/lib/event_listeners.js:611:46)
at Request.callListeners (/usr/local/lib/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
at Request.emit (/usr/local/lib/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
at Request.emit (/usr/local/lib/node_modules/aws-sdk/lib/request.js:686:14)
at error2 (/usr/local/lib/node_modules/aws-sdk/lib/event_listeners.js:443:22)
at ClientRequest.<anonymous> (/usr/local/lib/node_modules/aws-sdk/lib/http/node.js:99:9)
at ClientRequest.emit (node:events:513:28)
at ClientRequest.emit (node:domain:489:12)
at Socket.socketErrorListener (node:_http_client:494:9)
at Socket.emit (node:events:513:28) {
code: 'UnknownEndpoint',
region: 'us-west-2',
hostname: 'localhost',
retryable: true,
originalError: [Error],
time: 2023-01-15T06:46:40.614Z
}
Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
The script hangs at the following message:
[16:52:01] Retrieved account ID 000000000000 from disk cache
[16:52:01] Assuming role 'arn:aws:iam::000000000000:role/cdk-hnb659fds-deploy-role-000000000000-us-west-2'.
[16:52:01] Assuming role failed: Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region.
[16:52:01] Could not assume role in target account using current credentials Inaccessible host: `localhost' at port `4566'. This service may not be available in the `us-west-2' region. . Please make sure that this role exists in the account. If it doesn't exist, (re)-bootstrap the environment with the right '--trust', using the latest version of the CDK CLI.
current credentials could not be used to assume 'arn:aws:iam::000000000000:role/cdk-hnb659fds-deploy-role-000000000000-us-west-2', but are for the right account. Proceeding anyway.
[16:52:01] Waiting for stack CDKToolkit to finish creating or updating...
Restarting the computer fixes it, but it's not clear what causes the issue in the first place. Restarting Docker does not help either.
Any thoughts on what could be causing the problem and how I can avoid it?
I'm adding this as an answer, although I do not have an affirmative answer I thought I would try to help.
I believe your port is being occupied and thus the process you are running is unable to obtain it resulting in error. Before running the job, check if the port is occupied:
sudo lsof -i :4566
Assumption
vRA to Saltstack config integration is working fine
Saltstack config accepting the keys from the minion
I am triggering an event from vRA when I am creating a new VM. I would like to know how the user will know that the states which triggered by the event are completed or not
For instance:
reactor:
- 'my/custom/event':
- salt://reactor/custom.sls
/srv/salt/reactor/custom.sls
test_df:
local.cmd.run:
- tgt: "role:MyServer"
- tgt_type: grain
- arg:
- df -h > /tmp/test_df.txt
On Cloud-init running the following:
salt-call event.send 'my/custom/event'
====================================================================
How the USER will find out that the event completed successfully or not, with errors or without?
I have a python project which uses Gitlab Job retry api to retry a job of a pipeline.
But my retry job is getting failed with the error "This job depends on other jobs with expired / erased artifact". What could be the reason for this error?
stages:
- build
build:
tags: [kubernetes, linux, default]
image: #image-url
stage: build
script:
- python3 setup.py sdist bdist wheel
artifacts:
paths:
- $CI_PROJECT_DIR/dist
- ${CI_PROJECT_DIR}/job
- ${CI_PROJECT_DIR}/*.egg-info/PKG-INFO
expire_in: 600 mins
your artifacts expire after 600 minutes, so if you re-run a pipeline stage later than that, the artifact will not be present any more. If the pipeline stage you re-ran depends on a previous stage's artifact, then the error you are seeing occurs
I'm currently trying to setup Bitnami's Wordpress + Nginx Docker with Azure App Service for Containers and I am stuck at the error message: Stopping site because it failed during startup.
I already tried to increase WEBSITES_CONTAINER_START_TIME_LIMIT without success. I also tried to find anything in the other logs, however, there is not relevant information.
This is my log:
2021-03-26T20:26:39.850Z INFO - Starting multi-container app..
2021-03-26T20:26:40.686Z INFO - Pulling image from Docker hub: registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:26:42.009Z INFO - latest Pulling from bitnami/wordpress-nginx
2021-03-26T20:26:42.011Z INFO - Digest: sha256:08ea17712bc6cd31a20128557aa5bbad562dc81af2e9a26b4f45bfca40e5538c
2021-03-26T20:26:42.013Z INFO - Status: Image is up to date for registry.hub.docker.com/bitnami/wordpress-nginx:latest
2021-03-26T20:26:42.021Z INFO - Pull Image successful, Time taken: 0 Minutes and 1 Seconds
2021-03-26T20:26:42.050Z INFO - Starting container for site
2021-03-26T20:26:42.052Z INFO - docker run -d -p 9180:80 --name as-wp-weu-prod_wordpress_0_f1793421 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=true -e WEBSITE_SITE_NAME=as-wp-weu-prod -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=as-wp-weu-prod.azurewebsites.net -e WEBSITE_INSTANCE_ID=8d9749e1ad54987267d51cda41194309f78e9fe336b09f44ea04d81342bdd40c -e HTTP_LOGGING_ENABLED=1 registry.hub.docker.com/bitnami/wordpress-nginx
2021-03-26T20:56:42.520Z ERROR - multi-container unit was not started successfully
2021-03-26T20:56:42.546Z INFO - Container logs from as-wp-weu-prod_wordpress_0_f1793421 = 2021-03-26T20:26:49.138042862Z [0m
2021-03-26T20:26:49.138217863Z [0m[1mWelcome to the Bitnami wordpress-nginx container[0m
2021-03-26T20:26:49.138376864Z [0mSubscribe to project updates by watching [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx[0m
2021-03-26T20:26:49.138532065Z [0mSubmit issues and feature requests at [1mhttps://github.com/bitnami/bitnami-docker-wordpress-nginx/issues[0m
2021-03-26T20:26:49.147750834Z [0m
2021-03-26T20:26:56.839294655Z nami INFO Initializing php
2021-03-26T20:26:56.907101461Z nami INFO php successfully initialized
2021-03-26T20:27:04.576803980Z nami INFO Initializing nginx
2021-03-26T20:27:04.676840017Z nami INFO nginx successfully initialized
2021-03-26T20:27:12.622656961Z nami INFO Initializing mysql-client
2021-03-26T20:27:12.721293503Z nami INFO mysql-client successfully initialized
2021-03-26T20:27:22.196788004Z nami INFO Initializing wordpress
2021-03-26T20:27:22.519271584Z wordpre INFO ==> Preparing Varnish environment
2021-03-26T20:27:22.527241945Z wordpre INFO ==> Preparing Apache environment
2021-03-26T20:27:22.537316623Z wordpre INFO ==> Preparing PHP environment
2021-03-26T20:27:22.588082613Z wordpre INFO WordPress has been already initialized, restoring...
2021-03-26T20:27:24.832051104Z mysql-c INFO Trying to connect to MySQL server
2021-03-26T20:27:24.861626532Z mysql-c INFO Found MySQL server listening at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130808807Z mysql-c INFO MySQL server listening and working at mariadb-weu-prod.mariadb.database.azure.com:3306
2021-03-26T20:27:25.130828007Z wordpre INFO Upgrading WordPress Database ...
2021-03-26T20:27:27.133719647Z wordpre INFO
2021-03-26T20:27:27.134393052Z wordpre INFO ########################################################################
2021-03-26T20:27:27.135004057Z wordpre INFO Installation parameters for wordpress:
2021-03-26T20:27:27.141716808Z wordpre INFO Persisted data and properties have been restored.
2021-03-26T20:27:27.142344313Z wordpre INFO Any input specified will not take effect.
2021-03-26T20:27:27.142926818Z wordpre INFO This installation requires no credentials.
2021-03-26T20:27:27.143452822Z wordpre INFO ########################################################################
2021-03-26T20:27:27.143975626Z wordpre INFO
2021-03-26T20:27:27.144505830Z nami INFO wordpress successfully initialized
2021-03-26T20:27:27.205315299Z [0m[38;5;2mINFO [0m ==> Starting gosu...
2021-03-26T20:27:27.243704595Z [0m[38;5;2mINFO [0m ==> Starting PHP-FPM...
2021-03-26T20:27:27.245663910Z [0m[38;5;2mINFO [0m ==> Starting NGINX...
2021-03-26T20:27:27.335050999Z 2021/03/26 20:27:27 [warn] 83#83: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:27:27.335712104Z nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /opt/bitnami/nginx/conf/nginx.conf:2
2021-03-26T20:56:46.234Z INFO - Stopping site as-wp-weu-prod because it failed during startup
This is my docker-compose:
version: '3.9'
services:
wordpress:
image: registry.hub.docker.com/bitnami/wordpress-nginx
restart: always
ports:
- '8080:80'
volumes:
- ${WEBAPP_STORAGE_HOME}/site/wwwroot:/bitnami/wordpress
- ${WEBAPP_STORAGE_HOME}/site/server_blocks:/opt/bitnami/nginx/conf/server_blocks/wordpress-server-block.conf
Thank you!
We're running RedHat 6.4 on 2 of our nodes.
We've installed the new Cloudera Manager 5.5.0 and we've been trying to create a cluster and add a first node to it (node is initially clean of any Cloudera component). Unfortunately, during the cluster installation, Cloudera Manager gets stuck every time at :
Installation failed. Failed to receive heartbeat from agent.
Ensure that the host's hostname is configured properly.
Ensure that port 7182 is accessible on the Cloudera Manager Server (check firewall rules).
Ensure that ports 9000 and 9001 are not in use on the host being added.
Check agent logs in /var/log/cloudera-scm-agent/ on the host being added. (Some of the logs can be found in the installation details).
If Use TLS Encryption for Agents is enabled in Cloudera Manager (Administration -> Settings -> Security), ensure that /etc/cloudera-scm-agent/config.ini has use_tls=1 on the host being added. Restart the corresponding agent and click the Retry link here.
We looked around and saw how this is usually caused by a misconfigured /etc/hosts file. So we edited ours on both Cloudera Manager and the new node, did a service network restart as well as service cloudera-scm-server restart but it didn't work either.
Here's what the /etc/hosts file looks like :
127.0.0.1 localhost
10.186.80.86 domain.node2.fr.net host
10.186.80.105 domain.node1.fr.net mgrnode
We also tried some cleaning up before relaunching the cluster creation by deleting scm_prepare_node.* and .scm_prepare_node.lock.
We looked at service cloudera-scm-agent status on the new node after each installation fail as well, and we noticed that the service isn't running (even when we do a service restart, the result is still the same)
service cloudera-scm-agent start
Starting cloudera-scm-agent: [ OK ]
service cloudera-scm-agent status
cloudera-scm-agent dead but pid file exists
Here's the agent logs on the new node side :
tail -f /var/log/cloudera-scm-agent/cloudera-scm-agent.log
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Agent Logging Level: INFO
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO No command line vars
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Missing database jar: /usr/share/java/mysql-connector-java.jar (normal, if you're not using this database type)
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Missing database jar: /usr/share/java/oracle-connector-java.jar (normal, if you're not using this database type)
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Found database jar: /usr/share/cmf/lib/postgresql-9.0-801.jdbc4.jar
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Agent starting as pid 24529 user cloudera-scm(420) group cloudera-scm(207).
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Because agent not running as root, all processes will run with current user.
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent WARNING Expected mode 0751 for /var/run/cloudera-scm-agent but was 0755
[30/Nov/2015 15:07:27 +0000] 24529 MainThread agent INFO Re-using pre-existing directory: /var/run/cloudera-scm-agent
[30/Nov/2015 15:07:29 +0000] 24529 MainThread agent INFO Re-using pre-existing directory: /var/run/cloudera-scm-agent/cgroups
Is there anything we're doing wrong?
Thanks in advance for your help!
This time we just created the cluster with the root user (didn't check the single user mode)
Besides, our host had no internet access, and having created our own repository we needed to do one last step before launching the cluster creation which is importing the GPG key on the host using this command :
sudo rpm --import
If anybody finds themselves facing the same problem, hope this helps!