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.
Related
I have installed Anaconda under Windows and Ubuntu under WSL. I have not used this Ubuntu installation for a long time. When I tried to run Ubuntu now, I saw the following:
That is, WSL starts a Jupyter Notebook server, which I have to kill by hitting Ctrl-C to get the Ubuntu prompt. What could be causing this behavior?
There are several ways for something to "autostart" when running WSL:
First, you (or an application) may have modified your startup scripts to start the Jupyter Notebook server. To see if this is the case, try starting WSL from PowerShell by running:
wsl -e bash --noprofile --norc
This will run bash without the startup scripts. If this brings you to the prompt without running the notebook sesrver, then the problem is in your ~/.bashrc or ~/.bash_profile (assuming bash is your default shell).
Given the symptoms you are seeing, this is the most likely cause. If that's the case, look in those files to see if you can find the line that is starting the server, and comment it out.
Second, and related to the first, do you recall trying to enable Systemd at any point using something like Genie or WSL2Hacks? If so, then I believe they modify your start scripts to run Systemd, which can be used to start other services. However, I would expect those Systemd-executed services to start daemonized, in the background, and not interrupt your shell's startup.
Under Windows 11, services can also be autostarted via /etc/wsl.conf, but again, they would be started by the root user in this case, and in the background. I can't think of a non-pathological way that this could be used to interrupt the user's startup shell experience.
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.
I've been searching high and low for this one, figuring it to be a common noob problem, but nothing. I saw an oblique reference somewhere that xampp's shell won't accept ctrl-c to close an operation but I'd like to confirm.
As it is, I'm running Xampp on a win7 machine and it's set up with the default apache mysql combo. Which is all fine. Except that the command line stops receiving commands once I start a server. So if I want to run another command I've gotta exit the xampp command line and restart it.
Is there a way to abort shell scripts in the xampp shell or is it just a product of the environment it's running in?
Ok, I'm going to consider this solved.
While Xampp locks up once you start a server instance. It's possible to run a server directly through the windows normal command line Start->Run->cmd, while doing other xampp stuff in the xampp shell.
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.
My shell provisioner is a small bash script that apt-gets a few things, installs a few Perl modules through cpan, sets up Apache and MySQL, echos some text, and exists.
Except that after printing its final message, it seems not to exit, but hangs forever.
Am I forgetting to do something? How can I begin to debug this?
If I use the VirtualBox manager to close the VM, I get a stack trace whose head reads,
/Applications/Vagrant/embedded/gems/gems/net-ssh-2.6.7/lib/net/ssh/ruby_compat.rb:30:in `select': closed stream (IOError)
Host OS: OS X Snow Leopard
Guest OS: Ubunut via precise32
TIA
This is really a comment but I don't have enough reputation to post it as a comment.
I would suggest two techniques to debug this problem.
1) Enable debugging in Vagrant like so:
VAGRANT_LOG=info vagrant up
2) Define set -x at the top of your shell script to link one line of your shell script to the output it creates when run. This should allow you to see which line of your shell script is hanging.
Updating your question with the Vagrantfile will also help us guide you in the right direction.
This issue should be resolved in a Vagrant release 1.2.4 or newer, which includes a fix which closes the ssh channel when the shell provisioner exits.