Recently while at work we were given an older version of ubuntu (12.04) to work with on a vagrant machine.
I wanted to migrate over to fish or zsh due to them being way better then default bash but I'm encountering a weird error where if I navigate to the /vagrant folder (shared onto the local machine as well) every command I run stalls for 5-10 seconds. Outside of the folder it does fine and has no stalling problems.
Has anyone encountered this before or have any ideas on why this could be happening?
Probably some stat or something taking too long to finish. I will suggest to run strace on bash (if you have patient for that :) ).
Such stat can be for example called from your PROMPT, it's common to have there CWD.
I will suggest to not run commands from there if not necessary. You can call commands outside and provide path to there.
Ofcourse you can play with sharing, there is probably some weak point.
Related
I need to setup docker on my windows 10 OS. I've previously been a linux guy where everything just works so this is a pain for me. It works as expected but within the dockerfile there are calls that uses /bin/bash which makes the build fail.
I've tried to setup a VM with hyper-v but then i stopped because i figured there must be an easier way. I found the bash.exe in windows. i can't run as sudo but i guess that doesn't matter here as long as i run bash as administrator. wget works here but the docker program cant be found when i run docker --version.
Is the easiest way to run bash scripts on win10 with the bash.exe? And why can't docker run in the bash terminal (there is no .bashrc)?
I would use Linux on the Windows box. The two systems can access each other's file systems (\\wsl$, /mnt/c). I use Ubuntu, and it's as if I was using a "normal" Ubuntu box in all aspects, so far. I'd be surprised if your process didn't work here.
Alternatively, there's Cygwin. When running Cygwin, you're kinda in a VM, kinda not. It's a bit blurry. As such, it's not as robust as WSL. But it might do the trick, and it's a lot less "heavy" than installing a full Linux distro.
Similar to the issue #37033541, my commands do not stop. However, my system does not have unmounted drives; my GOPATH is set to /users/user_name/go:/users/user_name/goCode. Neither changing this path to the installation default, nor restarting the computer, or even starting a shell without my bashrc change the behaviour. While it is running, it does generate a functional executable.
I am running go 1.14.1 installed according to the instructions for macOS Mohave.
This behaviour replicates across other packages in my system. But transferring the code to the Go Playground or another Mac computer does not replicate the behaviour. When I run go build -x ..., the last action is: rm -r $WORK/b001/.
Running a stack trace on the process yields ongoing system calls that I cannot interpret (They do seem varied and would be happy to post some if someone would think them useful).
This did not use to happen, it started a few hours ago. I would appreciate the help of someone in troubleshooting this issue.
The issue was resolved only by putting in a fresh installation of the OS and then reinstalling go 1.14.1.
More here: https://groups.google.com/forum/#!topic/golang-nuts/YxqX9o2YJ4k
Very often when running ansible-playbook on the Vagrant VM from Windows, I need to stop in the middle of something by pressing Ctrl+C. This happens if ansible becomes unresponsive or there is some bug we need to fix asap, so there is no point of waiting until provisioner completes.
The probem is that Ctrl+C does not work, some 2 ruby.exe processes get stuck in process tree. Any subsequent vagrant commands fail until you manually kill these ruby processes.
I also use to kill all stucked python ansible processes on the VM before running new provision.
Any way to handle it more jently?
I found this problem as well on Windows and using Puppet Apply. The only way I can happily kill it by opening another terminal/cmd and then vagrant ssh -- sudo pkill puppet. That gracefully terminates the process, and allows me to regain control of my first terminal again.
In short the solution is:
Take a terminal that works.
I find one working gitbash v2.32.0.windows..
The latest available gitbash currently is v2.38.1. But only the old one is working correctly with Vagrant(Oracle VM). The strange thing is that the latest one (gitbash v2.38.1) is working fine with SSH connections to AWS EC2 instances.
Alternatively. Windows PowerShell is working fine with Vagrant(Oracle VM).
If someone needs my bad experience, here it is.
The following terminals DON'T WORK
gitbash v2.38.1 (latest for now)
gitbash V2.36.0
ConEmu v220807 Alhpa (latest for now)
cmder v1.3.20.1282 (latest for now)
I propose using vagrant halt.
I have recently set up Vagrant on my machine, and the first thing I noticed was that my terminal config was not synced, when I sshed into my server.
For instance I have changed my shell from bash to zsh, which does a lot of beautiful things for me (like removing case-sensitive auto completion). But on my vagrant virtual machine, or on my server, all this cool stuff is now gone. Also stuff like my important aliases is not synced.
Now, what is a proper way to sync stuff like this?
EDIT:
So currently, when I create/remove/edit an alias on my local machine, I have to copy the exact same changes into my VM and all other servers I frequently use. I see this as a very time consuming and unnecessary task.
What I do is version control my dotfiles and I keep them on github. Dotfiles are just the files in your root that start with a dot in the name such as .bashrc or .zshrc. They are "invisible" files, so you have to use ls -a instead of just ls to see them.
Here are my dotfiles: https://github.com/aharris88/dotfiles
When I get on a new machine, I just clone the repository to ~/dotfiles
Then, I have a bash script in there called setup.sh that backs up any old dotfiles that might already be in root into ~/dotfiles_old. Then it creates symlinks to the files that are in ~/dotfiles.
It also installs zsh and oh-my-zsh if it isn't already. It should work for linux or mac os x.
Here is an article describing how to version control your dotfiles: http://blog.smalleycreative.com/tutorials/using-git-and-github-to-manage-your-dotfiles/
Another thing that I do to get a new mac ready is use kitchenplan: https://github.com/kitchenplan/kitchenplan, which can sync a lot more settings, but this probably isn't what you're asking about. Here is my kitchenplan config: https://github.com/aharris88/kitchenplan-config
I have installed msysgit, and I am attempting to use it inside of Hudson. Whenever I run a command in an interactive shell, whether it be git-bash or a command prompt, the commands are instant. When I run them in Hudson, they lag for a very long time.
Running /bin/git help took 63 seconds when I just invoked it. I've never waited long enough to see a clone begin outputting (>10 minutes).
The Hudson mailing list is down, so I figured I would try here...
I've run into this problem as well, and figured out a workaround. When Hudson runs as a service, something is missing that your normal desktop environment has, which causes something to do with the network to have to re-load for each process. msys-1.0.dll attempts to load something in netapi32.dll which causes it to take so long. So I just downloaded plink.exe from PuTTY, and set my GIT_SSH env to use that instead. Problem averted.
Have you tried using the Git plugin for Hudson?