I have a gitlab pipeline which executes it's jobs in my local machine, which has ubuntu 18.04 OS, using shell executor once the pipeline is triggered. It used to work fine with my ubuntu 20.04; once I downgraded my OS, my laptop is shutting down or turning into a black screen whenever the jobs are being executed.I have shared the final log messages from gitlab server!
Your best bet would be to check /var/log/syslog to see if or what errors are being thrown by your Runner. GitLab Runner logs to /var/log/syslog by default: GitLab Runner troubleshooting tips
Additionally, I'd check to see if there are any kernel failures at /var/log/kern.log (for whatever reason) considering you're having overall hardware issues when using a shell executor. That's definitely an odd issue.
Related
I added a new virtualbox runner to my gitlab self hosted solution and I'm getting this warning on it:
Runner has never contacted this instance
and it nevers runs any jobs
Bouncing the runner will definitely help, else re-register the runner.
Also, you should check the status of the Runner with the below command.
gitlab-runner status
If you are using the runner in Windows Server, then go to the path where you have stored the .exe file and run the below command:
.\<.exe> status
If the runner is in stopped state, the start the runner by using the same commands but just replace status with start.
Gitlab:14.4.0
Gitlab-Runner:14.4.0 & 13.0.1
After I upgrade Gitlab from 13.6.3 to 14.4.0, all Runner could not pick up jobs
I thought it was Runner version too old，but Gitlab-Runner:14.4.0 on other Linux vm show the same problem
gitlab-runner status looks normal
But when I use gitlab-runner --debug run on each vm, Runner work for few minutes, the runner on that vm could pick up jobs, now I run this command manual every 5 minute to keep other developer working
the problem is we deploy gitlab use docker version image on hand wirte Deployment deploy on Kubernetes, the background jobs fail and stuck many times, after we transfer data to new Gitlb which deploy by helm problem solved
I had the same problem. But I figured it came from the GitLab instance iteself.
The problem was thensolved by upgrading to 14.4.2. I don't think it's the update itself, but the restart of the GitLab instance after the upgrade proved useful.
Ran into a similar issue (GitLab EE v14.2.3-ee) whereby all 3 runners where in a wait state for minutes at a time, before any pending jobs were eventually picked up. Resolved the issue by...
removing all runners,
resetting the config.toml file (which was cluttered with [[runner]] entries from former runners),
restarting GitLab, and
then creating new runners.
Specifically, I performed the following steps...
Delete all runners via "GitLab console > Admin > Overview > Runners".
Log into runner host(s), find config.toml, and clean out the entire file except for...
concurrent=5
check_interval=0
[session_server]
session_timeout = 1800
Log into GitLab EE host and restart GitLab EE.
sudo gitlab-ctl restart
Log into the runner host(s), and create new runners (follow directions from "GitLab console > Admin > Overview > Runners" )
After the above corrective action, the runners now immediately pick up pending jobs.
I use Gitlab for doing Continuous Integration and Development and all of a sudden I get this error message "There has been a runner system failure, please try again"
There's no real error message or error code.
I've tried restarting the gitlab runner, using gitlab-runner restart, I've done a reboot of the server its running on but I keep getting this error message on Gitlab whenever I push a code change.
After a couple of hours, I realized the issue is that the server that Gitlab Runner is running on has no space left.
I logged into the server in question. Looked at the Gitlab log file using the following command:
journalctl -u gitlab-runner
And it showed me the following logs:
May 21 08:20:41 gitlab-runner[18936]: Checking for jobs... received job=178911 repo_url=https://.......git runner=f540b942
May 21 08:20:41 gitlab-runner-01 gitlab-runner[18936]: WARNING: Failed to process runner builds=0 error=open /tmp/trace543210445: no space left on device executor=docker runner=f540b942
To fix this issue I ran docker conatiner prune which clears out stopped containers.
Alternatively you could use docker system prune which would remove all unused objects.
See https://linuxize.com/post/how-to-remove-docker-images-containers-volumes-and-networks/ for more information about those docker commands.
Afterwards, I no longer got the error on Gitlab when pushing changes.
I have a jenkins server 1.651.3 running on a RedHat 6.3
Linux OS time is 12:30, but Jenkins server time is 11:30
How can I syncronize Jenkins server time with Linux ? (both should show 12:30)
Note: I tried these workarounds to solve the problem - without success:
1. added
-Duser.timezone=Asia/Jerusalem
-Dorg.apache.commons.jelly.tags.fmt.timeZone=Asia/Jerusalem
to /etc/sysconfig/jenkins and restarted jenkins service
2. executed
System.setProperty('org.apache.commons.jelly.tags.fmt.timeZone', 'Asia/Jerusalem')
from Jenkins Script console
Any ideas?
Bitnami GitLab 5.2 server is down with messages
We're sorry, but something went wrong.
We've been notified about this issue and we'll take a look at it shortly.
I was not notified! Yesterday I just could create new, not it s all inaccessible.
Current services status:
apache already running
gitlab_sidekiq not running (Bitnami GitLab 5.2.0: gitlab_sidekiq not running and could not be started)
gitlabci_sidekiq already running
redis already running
mysql already running
After reboot, it is still the same.
main page "Congratulations!" can be seen,
gitlab app - We're sorry,
GitLab CI- OK
UPDATE WITH ANSWERS:
VM with 512MB, 1 CPU core
Are you using the BitNami GitLab virtual machine? How much RAM did you configured for it? GitLab requires some resources in the machine, try to check the Sidekiq log file to see if there is any error: /opt/bitnami/apps/gitlab/htdocs/logs/sidekiq.log