ERROR: Preparation failed: Getwd: getwd: no such file or directory - gitlab-ci-runner

Gitlab runner throw ERROR: Preparation failed: Getwd: getwd: no such file or directory?
gitlab version is: GitLab Community Edition 8.6.4
gitlab-runner version: 1.11.5
My CI throw ERROR: Preparation failed: Getwd: getwd frequently,
but sometimes we commit is work fine. So we didn't know what the final reason cause this problem.
We only know about one thing that is this error shows after we moved the build directory.

In my case that was because of residual gitlab-runner processes still executing. I resolved it by identifying guilty pids then killed them:
$ ps -ax | grep gitlab-runner
27034 ? Ssl 0:06 /usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
$ sudo kill -9 27034

I got the same error and solved by restarting gitlab-runner
gitlab-runner restart

The Gitlab Runner checks out a copy of your repository into CI_PROJECT_DIR. You can check its value by adding the following to your .gitlab-ci.yml:
script:
- echo $CI_PROJECT_DIR
I received the "getwd: no such file or directory" error because:
I had changed my working directory to /var/www/mysite (I am using a docker container with gitlab-runner installed inside it, but I think that's beside the point)
one of my deploy script lines moves /var/www/mysite to /var/www/old-mysite.
I'm used to the Gitlab Runner checking out its build inside /home/gitlab-runner/build. When I changed the docker working directory this caused the runner to check it out at /var/www/mysite/build.
After my script moved /var/www/mysite to /var/www/old-mysite, on second and subsequent runs, gitlab runner still expected to find (/var/www/mysite) but it no longer existed, hence the error.
Given the above, I can't explain why the runner works the first time ever, when that directory also doesn't exist, but hopefully my answer might at least prompt something useful for someone! :)

Related

pod not found error, while using the rsync cmd to copy the results from ocp pod to jenkins workspace

I am running some automated tests using RBF, but sometimes when the test runner is complete and am trying to copy the test result from OCP to local using Rsync (using Jenkins job), it shows that the pod is not found, but test cases were run on the same pod, after restarting the pod this error is resolved, but after some time again this error comes. Can anyone tell me what is the root cause of this error and the solution for this?
tried to start rollout the pod, but this does not fix the problem permantely, after some run the error comes again

gitlab ci shell runner reports profile loading problem

I'm trying to setup the gitlab ci shell runner. I've used the docker runner before successfully but now I'd like to use another docker container within my testing routine and therefore switched to the shell runner.
After registering I'm running into an exception:
ERROR: Job failed (system failure): prepare environment: exit status 1. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
So, I went through the linked material but that didn't cure the problem. Now, I verified that the gitlab-runner user exists and it has access to docker (needed to run the docker test container). Also the gitlab-runner user is part of the docker group. I can also --login, fire up the /bin/bash without problems.
Still, all I get from the runner side is the the enigmatic message above. What other checkups to I need to do to track down this issue?
The careful reader will find the answer:
"A common failure is when you have a .bash_logout that tries to clear
the console."

Cannot start an existing container with Podman

I am running Podman version 1.6.2 on Ubuntu 18.04. I am unable to start a container after stopping it.
I run the container with:
podman run -d -p 8081:8081 --name nexus -v /opt/nexus-data:/nexus-data sonatype/nexus3
And it starts up ok. If I run:
podman container stop nexus
podman container start nexus
I get an error:
Error: unable to start container "nexus": container create failed (no
logs from conmon): EOF
When run with debug logging I see this in the output:
DEBU[0000] Initializing event backend journald DEBU[0000]
using runtime "/usr/lib/cri-o-runc/sbin/runc" WARN[0000] Error
initializing configured OCI runtime crun: no valid executable found
for OCI runtime crun: invalid argument
DEBU[0000] unmounted container
"419f6576ff23328c6445526058c9988aa27a4b69605348230fa26246a522c726"
ERRO[0000] unable to start container "nexus": container create failed
(no logs from conmon): EOF
The source image is:
docker.io/sonatype/nexus3
I'm not sure what the "invalid argument" in the logs means. Do I need to pass another argument?
there seems to be problem with the latest version of conmon package from Project Atomic PPA (v 2.0.3).
I had the same problem and I installed a lower version of conmon package (v 2.0.0) from,
https://launchpad.net/ubuntu/+archive/primary/+files/conmon_2.0.0-1_amd64.deb
This is a package built for Eoan. However, it worked on my Bionic environment and I am able to start my containers again.
As #Loki Arya noted, a bug in the common package was causing the issue. Since Podman for Unbuntu is no longer being hosted at projectatomic ppa, the updates after version 1.6.2 that fixed the bug were not available.
After removing the project atomic ppa and all associated packages, I reinstalled Podman for Ubuntu from its new repository location here
I've tested Podman (1.7) and it is working great, including the start command

Scilab, backdoor error, octave conflict

I installed scilab.6.0.0 and backdoor fromscilab website (which I could not find it from Application>Module maneger>atom>Technical). I moved the backdoor file my home and from scilab command line I installed it
-->atomsInstall('/home/user/BackDoor_0.2_5.5.bin.x86_64.linux.tar.gz')
Even though, it installed backdoor successfully, when I restart the scilab I got this error message with backdoor
Start Toolbox BackDoor
Load macros
atomsLoad: An error occurred while loading 'BackDoor-0.2':
lib: Old binary lib detected. Please recompile it for Scilab 6.
As I understand I need to update the library, but I don't know how?
Would sb tell me explicitly (because I am a newbie user of scilab) how can I get over the error?
at the and I try to connect octave and scilab and when I try to run a demo script at octave I get also this error
>> sci_sim_example
Scilab connection failed
FYI: I already installed sci_cosim package (after I downloaded the package, I write to octave prompt >>pkg install sci_cosim_0.1.3.tar.gz), and I load it before running the script.
How can I recompile the lib: Old binary lib detected
Thank you so much for your help in advance
Here's what worked for me.
Download Scilab 5.5.2 (link for Linux 64bit version)
Extract the .tar.gz file in your preferred system location to install it there. Generally, my preferred location to extract / install self-contained packages is inside /opt .
You can extract the .tar.gz file using your filebrowser's graphical facilities, or on the command line; if /opt is owned by root (which it usually is) you may need to change ownership after extraction. E.g. your installation might look something like this:
cd /opt
sudo wget http://www.scilab.org/download/5.5.2/scilab-5.5.2.bin.linux-x86_64.tar.gz
sudo tar -xvzf ./scilab-5.5.2.bin.linux-x86_64.tar.gz
sudo rm scilab-5.5.2.bin.linux-x86_64.tar.gz
sudo chown $USER ./scilab-5.5.2 -R
Launch scilab by typing
/opt/scilab-5.5.2/bin/scilab &
in your terminal.
Once scilab is launched, go to Applications->Module Manager ATOMS. In the new window that comes up, click on All modules -> BackDoor -> Install.
You should get a message saying "Installation done, please restart SciLab".
Exit Scilab, and launch it again from the terminal. If you see a message:
atomsLoad: An error occurred while loading 'BackDoor-0.2':
File "/opt/scilab-5.5.2/share/scilab/contrib/BackDoor/0.2/etc/backdoor.start" does not exist.
then type the following commands in your terminal to rename the affected files:
cd /opt/scilab-5.5.2/share/scilab/contrib/BackDoor/0.2/etc/
mv BackDoor.start backdoor.start
mv BackDoor.quit backdoor.quit
Restart SciLab again. Hopefully this time it will work and SciLab will inform you that BackDoor is listening for connections at a certain port.
PS. Also note that from the octave side of things, the -auto option is no longer accepted when you perform a pkg install. You will need to load the sockets and sci_cosim packages manually each time you want to use this.

Elastic Beanstalk stops at EbExtensionPostBuild

I am having a problem deploying an EB instance with a custom .ebextensions file. This is the relevant part in that file:
container_commands:
01_migrate:
command: 'python db_migrate.py'
02_npm_build:
command: 'npm install && npm run prod'
As you can see, these commands are for migrating my PostgreSQL database (via a Flask backend) and building my React .jsx files.
If I leave these commands out, the deployment completes perfectly well. However, once I put them in, looking at the eb-activity.log it stalls at this part forever (as far as I can tell):
[2017-04-10T02:39:24.106Z] INFO [3023] - [Application deployment app-613e-170409_223418#1/StartupStage0/EbExtensionPostBuild] : Starting activity...
I also get this message on the Health overview in the console (this is after 1 day):
Performing application deployment (running for 1 day).
I have also tried to deploy it without those container_commands, and then including it back after the successful initial deployment. Then I get the same error message as before in eb-activity.log, and I also get this message on the Health overview:
Incorrect application version "app-2a3d-170409_214923" (deployment 1). Expected version "app-2a3d-170409_214923" (deployment 1).
Which is very strange because those two versions referenced are the same versions. I don't know what this means!
I found a solution.
Remove all you container_commands from .ebextensions/
Go ssh to instance, kill process with.
sudo killall python
Then Deploy new version without container_commands.
And start debuging all your container_commands, one by one on ssh..
Have fun.