Unfortunately, occassionally we receive a following Rundeck exception for some of the scheduled jobs:
com.dtolabs.rundeck.core.NodesetEmptyException: No matched nodes: NodeSet{includes={name= myrealhost.com, dominant=false, }}
at com.dtolabs.rundeck.core.execution.workflow.NodeFirstWorkflowExecutor.validateNodeSet(NodeFirstWorkflowExecutor.java:369)
at com.dtolabs.rundeck.core.execution.workflow.NodeFirstWorkflowExecutor.executeWorkflowImpl(NodeFirstWorkflowExecutor.java:90)
at com.dtolabs.rundeck.core.execution.workflow.BaseWorkflowExecutor.executeWorkflow(BaseWorkflowExecutor.java:222)
at com.dtolabs.rundeck.core.execution.WorkflowExecutionServiceThread.runWorkflow(WorkflowExecutionServiceThread.java:83)
at com.dtolabs.rundeck.core.logging.LoggingManagerImpl$MyPluginLoggingManager.runWith(LoggingManagerImpl.java:148)
at com.dtolabs.rundeck.core.execution.WorkflowExecutionServiceThread.run(WorkflowExecutionServiceThread.java:74)
Exception: class com.dtolabs.rundeck.core.NodesetEmptyException: No matched nodes: NodeSet{includes={name= myrealhost.com, dominant=false, }}
No matched nodes: NodeSet{includes={name=myrealhost.com, dominant=false, }}
While hunting for a solution online, I came across a relevant Github issue https://github.com/rundeck/rundeck/issues/2942#issuecomment-360573113. Unfortunately, the fix suggested didn't help.
Please note the following details for your reference:
Rundeck version: 3.1.0-20190731
DB Type: MySQL 8
Install type: war
OS: Ubuntu 18
Use Asynchronous Cache: True
Cache Delay: 3600
Synchronous First Load: Enabled
Inventory source: Ansible Dynamic Inventory -- a Python script to load data from EtcD
Another relevant Github issue: https://github.com/rundeck/rundeck/issues/4231
Also, I haven't noticed any errors from Python inventory script except the aforementioned exception in Rundeck job log.
I had no choice but to reach out to the Rundeck community at Stack Overflow as the relevant Github issues seemed dormant.
I will appreciate any help on this front.
Thanks in advance.
It seems a node cache problem that happens sometimes. You can try this workaround.
Related
I am facing Failed to pull image with policy "always": Error response from daemon:Get https://registry-1.docker.io/v2/library/docker/manifests/20.10.17-dind: unauthorized: incorrect username or password (manager.go:203:0s) error while trying to run my pipeline to push my code on docker hub.
I tried different solution but everytime I get same error. I am using username of my dockerhub rather than email but facing same issue. One of my friend told me it may be dind issue you have to mentioned docker and dind image and service latest version tags but still same issue. Please help me, I really appriciate your efforts in advance.
Please check code screenshot attached with it.
Check if this is an authentication issue similar to this one
We noticed that the job succeeds if we delete Docker config file ~/.docker/config.json, containing credentials from previous CI jobs.
That is the reason why you should always use docker logout <registry> if the job runs in a non-disposable environment
I am running a cloud build trigger on a cloudbuid.yaml file in which I build a docker container and then deploy it to cloud run. The error stacktrace is as follows:
API [sql-component.googleapis.com] not enabled on project
The problem is that I have enabled both SQL and SQL Admin APIs in both projects (one for the cloud build and one for the database), which was confirmed in the console and in gcloud.
Here is the yaml code for the step I am referring to:
- name: 'gcr.io/cloud-builders/gcloud'
args: [
'beta',
'run',
'deploy',
'MY_NAME',
'--image', 'gcr.io/MY_PROJECT/MY_IMAGE',
'--region', 'MY_REGION',
'--platform', 'managed',
'--set-cloudsql-instances', 'MY_CONNECTION_NAME',
'--set-env-vars', 'NODE_ENV=production,INSTANCE_CONNECTION_NAME=MY_CONNECTION_NAME,SQL_USER=MY_USER,SQL_PASSWORD=MY_PASSWORD,SQL_NAME=MY_SCHEMA,TOPIC_NAME=MY_TOPIC'
]
Any suggestions?
Thanks.
P.S.: As per Eespinola suggestion, I checked and confirmed I am running Google Cloud SDK 254.0.0.
P.S. 2: I have also tried to create a project from scratch but ended up with the same results.
Ok so as per the same thread eespinola posted (see above), the Cloud Build gcloud step will be updated according to Cloud SDK 254.0.0 update in a near future (the actual date may or may not be posted in the same thread in the future). Until then, the alternative is to use the YAML file without the --add-cloudsql-instances flag and add it manually in the UI (I still have not tried this but it should work as per Google's development team).
I am trying to set up Stackdriver debugging using Go. Using the article and this great medium post I came up with this solution.
Key parts, in cloudbuild.yaml
- name: gcr.io/cloud-builders/wget
args: [
"-O",
"go-cloud-debug",
"https://storage.googleapis.com/cloud-debugger/compute-go/go-cloud-debug"
]
...
Dockerfile I have
...
COPY gopath/bin/stackdriver-demo /stackdriver-demo
ADD go-cloud-debug /
ADD source-context.json /
CMD ["/go-cloud-debug","-sourcecontext=./source-context.json", "-appmodule=go-errrep","-appversion=1.0","--","/stackdriver-demo"]
...
However the pods keeps crashing, the container logs show this error:
Error loading program: decoding dwarf section info at offset 0x0: too short
EDIT: Using https://storage.googleapis.com/cloud-debugger/compute-go/go-cloud-debug may be outdated as I haven't seen it used outside Daz's medium post. The official docs uses the package cloud.google.com/go/cmd/go-cloud-debug-agent
I have update cloudbuild.yaml file to install this package:
- name: 'gcr.io/cloud-builders/go'
args: ["get", "-u", "cloud.google.com/go/cmd/go-cloud-debug-agent"]
env: ['PROJECT_ROOT=github.com/roberson34/stackdriver-demo', 'CGO_ENABLED=0', 'GOOS=linux']
- name: 'gcr.io/cloud-builders/go'
args: ["install", "cloud.google.com/go/cmd/go-cloud-debug-agent"]
env: ['PROJECT_ROOT=github.com/roberson34/stackdriver-demo', 'CGO_ENABLED=0', 'GOOS=linux']
And in the Dockerfile I can get access to the binary in gopath/bin/go-cloud-debug-agent
When I execute the gopath/bin/go-cloud-debug-agent with my own program as an argument:
/go-cloud-debug-agent -sourcecontext=./source-context.json -appmodule=go-errrep -appversion=1.0 -- /stackdriver-demo
I get another opaque error:
Error loading program: AttrStmtList not present or not int64 for unit 88
So basically using the cloud-debug binary from https://storage.googleapis.com/cloud-debugger/compute-go/go-cloud-debug and cloud-debug-agent binary from the package cloud.google.com/go/cmd/go-cloud-debug-agent both don't work and give different errors.
Would appreciate any tips on what I'm doing wrong and how to fix it.
OK :-)
Yes, you should follow the current Stackdriver documentation, e.g. go-cloud-debug-agent
Unfortunately, there are now various issues with my post including a (currently broken) gcr.io/cloud-builders/kubectl for regions.
I think your issue pertains to your use of golang:alpine. Alpine uses musl rather than the glibc that you find on most other Linux distro's and so, you really must compile for Alpine to ensure your binaries reference the correct libc.
I'm able to get your solution working primarily by switching your Dockerfile to pull the Cloud Debug Agent while on Alpine and to compile your source on Alpine:
FROM golang:alpine
RUN apk add git
RUN go get -u cloud.google.com/go/cmd/go-cloud-debug-agent
ADD main.go src
RUN CGO_ENABLED=0 go build -gcflags=all='-N -l' src/main.go
ADD source-context.json /
CMD ["bin/go-cloud-debug-agent","-sourcecontext=/source-context.json", "-appmodule=stackdriver-demo","-appversion=1.0","--","main"]
I think that should get you beyond the errors that you documented and you should be able to deploy your container to Kubernetes.
I've made my version of your image publicly available (and will retain it for a few days for you):
gcr.io/dazwilkin-190402-55473323/roberson34#sha256:17cb45f1320e2fe04e0681310506f4c229896429192b0d1c2c8dc20ed54adb0d
You may wish to reference it (by that digest) in your deployment.yaml
NB For Error Reporting to be "interesting", your code needs to generate errors and, with your example, this is going to be challenging (usually a good thing). You may consider adding another errorful handler that always results in errors so that you may test the service.
I'm running BizTalk 2013r2 CU5 in Win2012r2
I noticed a file wasn't being collected from a receive location. The relevant host instance was running, so I checked the event log and found this:
SSO AUDIT Function: GetConfigInfo
({E182FB76-16B4-47D7-8178-4C66C9E3BA9D}) Tracking ID:
c4d0d0d1-0763-4ec5-99ea-fb2ac3bcc744 Client Computer: BizTalkBuild01
(BTSNTSvc64.exe:7940) Client User: BIZTALKBUILD01\BizTalkSvc
Application Name: {E182FB76-16B4-47D7-8178-4C66C9E3BA9D} Error Code:
0xC0002A1F, Cannot perform encryption or decryption because the secret
is not available from the master secret server. See the event log for
related errors.
I then restored the master secret using:
ssoConfig -restoresecret SSOxxxx.bak
After restoring, the file is still not being collected but the error messages in the event log have changed to this:
SSO AUDIT Function: GetConfigInfo
({2DC11892-82FF-4617-A491-5324CAEF8E90}) Tracking ID:
5e91d09d-1128-491b-851b-e8c8e69d06eb Client Computer: BizTalkBuild01
(BTSNTSvc64.exe:26408) Client User: BIZTALKBUILD01\BizTalkSvc
Application Name: {2DC11892-82FF-4617-A491-5324CAEF8E90} Error Code:
0x80090005, Bad Data.
Does anyone know of a solution to this please? This is the 2nd time I've faced this problem on different servers in the last 3 months.
The MSI for CU6 has now been fixed
For BizTalk 2013 R2 this may be a known issue, with a hotfix available!
There is a hotfix for this issue, however, the hotfix may introduce another issue (memory leak). A solution can be found here: https://blogs.msdn.microsoft.com/amantaras/2015/11/10/event-id-10536-entsso-bad-data-issue/
I'm in some trouble with GitLab CI.
I followed offical guide on:
https://github.com/gitlabhq/gitlab-ci/blob/master/doc/installation.md
Everything was ok, no errors nowhere. I followed Runner-Setup, too.
Anything alright.
But...
When I add a runner to a project and then try to build nothing happens.
It could be that I have not fully understood something or some of my configs are wrong.
I'm absolutely new to GitLab CI, but I like it and I want to learn new stuff.
I would be very very glad if someone could help me in some way.
Thanks!
BIG UPDATE:
Just figured out that:
~/gitlab-runners/gitlab-ci-runner$ bin/runner
Starting a runner process manually solves the problem but if I look at the gitlab-ci-runner in /etc/init.d -> it is running !?!
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner start
Number of registered runners in PID file=1
Number of running runners=0
Error! GitLab CI runner(s) (gitlab-ci-runner) appear to be running already! Try stopping them first. Exiting.
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner stop
Number of registered runners in PID file=1
Number of running runners=0
WARNING: Numbers of registered runners don't match number of running runners. Will try to stop them all
Registered runners=1
Running runners=0
Trying to stop registered runners...kill: No such process
OK
Trying to kill ghost runners...OK
What's wrong here? I'm out of my power or not seeing the problem?!
Problem solved!
You need to edit some values in /etc/init.d/gitlab-ci-runner script!
APP_ROOT="**PATH_TO**/gitlab-runners/gitlab-ci-runner"
APP_USER="**USER_WITH_DIRRIGHTS!**"
PID_PATH="$APP_ROOT/tmp/pids"
PROCESS_NAME="ruby ./bin/runner"
RUNNERS_PID="$PID_PATH/runners.pid"
RUNNERS_NUM=1 # number of runners to spawn
START_RUNNER="nohup bundle exec ./bin/runner"
Now it works!
In my case tags in the runner were different from tags in the .gitlab-ci.yml. Once I changed them so runner tags include all of the config file tests, tasks began to run.