I need to create a simple script (Windows .bat) that will provision or up a box.
Not much experience with .bat files, so this is what I have so far:
Edited thanks to Greg Hewgill
cd C:\vagrant-box\
call vagrant-up.bat
if errorlevel 1 call vagrant-provision.bat
The .bat files called in the script just contain one line: vagrant up and vagrant reload, respectively.
When the vagrant box is down, then vagrant up runs successfully. When up, I encounter an error with vagrant up (which I expect) but the whole batch file dies there. ErrorLevel doesn't appear to do anything.
Here is the error if it makes a difference
Bringing machine 'default' up with 'virtualbox' provider...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["list", "hostonlyifs"]
Stderr: VBoxManage.exe: error: Failed to create the VirtualBox object!
VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005) - Server execution failed (extend)
VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start.
I want to emphasize I don't care about the error per se. It works when the box is not running, so it's fine. I just want to capture or ignore it, and move to the next command.
vagrant up exits with code 0 even if the machine is already running.
But you don't have to bother with exit codes, you can just run:
vagrant provision && vagrant up
And you should cover both cases. If the guest is not running, vagrant provision will gracefully fail and vagrant up will succeed, and vice versa.
Please post your vagrant-up.bat.
Also, try either this:
vagrant up --debug
and/or
VAGRANT_LOG=debug vagrant <action>
To get more detais about the COM/VBox issue.
Related
I have installed and configured and also used TV the first time today in Nvidia jetson Xavier,
but after restart Im getting this issue:
teamviewerd.service: Can't open PID file /var/run/teamviewerd.pid (yet?) after start: No such file or directory
Please tell me why and how to fix it, it is of extreme importance !
I use TeamViewer to connect to a machine (Ubuntu 20.04) that not always have a graphical user session started and I noticed that even with teamviewerd running the machine is offline.
I fixed the problem running:
sudo teamviewer setup
From teamviewer --help:
teamviewer setup Configure headless modes (non-gui/console)
Without running this, the only way for me was to start manually a graphical user session and open the TeamViewer GUI on the host I wanted to use.
Make sure you enable/start gdm.service or another supported login manager
Found this question via a search when facing the same issue on Fedora 30 x86_64.
Solution for me was to edit /etc/systemd/system/teamviewerd.service and comment out the line that says:
PIDFile = /run/teamviewerd.pid
So it reads:
# PIDFile = /run/teamviewerd.pid
(or whatever PIDFile it specifies)
then run:
systemctl daemon-reload
systemctl start teamviewerd
systemctl status teamviewerd
I am trying to install flink on windows running into all sorts of problems . Please help.
Downloading the tar file from net, does not give me windows bat file options. Used the download links at https://flink.apache.org/downloads.html#apache-flink-1111. So i cannot run start-local.bat. Infact i dont even have start-local.sh . I ended up installing cygwin just so i can run start cluster bat
However running the start cluster bat is giving weird issues and exiting immediately.
$ ./start-cluster.sh
Starting cluster.
Starting standalonesession daemon on host DESKTOP**.
Starting taskexecutor daemon on host DESKTOP**.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Improperly specified VM option 'MaxMetaspaceSize=268435456
'
This is an open bug for sometime and is deferred to Flink 1.14 version.
https://issues.apache.org/jira/browse/FLINK-18438
https://issues.apache.org/jira/browse/FLINK-18792
Since I have updated windows, my conemu terminal is giving me the following error each time a session is created:
wslbridge error: failed to start backend process
note: backend error output: -v: -c: line 0: unexpected EOF while looking for matching `''
-v: -c: line 1: syntax error: unexpected end of file
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
Has anyone an idea to bring conemu to a wsl terminal? Thank you
A similar error is caused by upgrading WSL from v1 to v2.
If you read through the discussion on this github issue for ConEmu you'll find a variety of instructions that can be distilled into:
Change the command for the task {Bash::bash} to the following:
wsl.exe
A GitHub user posted this workaround which worked for me:
I've fixed the issue by doing this:
Download latest cygwin1-20200531.dll.xz from https://cygwin.com/snapshots/ and unpack the file as cygwin1.dll into ConEmu\wsl\ (replacing the original file there)
Download #Biswa96's wslbridge2 from https://github.com/Biswa96/wslbridge2/releases and unpack to the same directory
Replacing {WSL::bash} task's Command with:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe -cur_console:pm:/mnt -eConEmuBuild -eConEmuPID -eConEmuServerPID -l
I can now access my Ubuntu under W10 just like before the W10 upgrade. Backscroll and arrows in VIM work as expected.
The key part of step 3 is to replace conemu-cyg-64.exe --wsl with conemu-cyg-64.exe %ConEmuBaseDirShort%\wsl\wslbridge2.exe.
Longer term, it looks like the author of ConEmu is working on switching to the new Windows PTY API, which will eliminate the need for the wslbridge hack (and many others) entirely.
I had the same issue with last update windows
(Feature update to Windows 10, version 2004 - Successfully installed on 9/1/2020)
the error does not seem to be related to the version of WSL from 1 to 2:
$ wsl -l -v
NAME STATE VERSION
Ubuntu-20.04 Running 1
Nevertheless, this workaround worked for me as well, thank you so much!
Exactly this goes through upgrading WSL from v1 to v2.
You have to open cmder and in the startup command or Task enter {wsl.exe} and ready
cmder is working again.
Yes, the new command for WSL2 is much simpler, but just running wsl does not cause .profile to be read because launching this way does not request login shell, and it launches as root.
A better command is to specify the user id and to invoke the shell of your choice (bash is most common) with the appropriate option. For bash a login shell is desirable so .profile, .bashrc and .bash_aliases get sourced, if present. The -l (lower case L) does that:
wsl -U yourUserName bash -l
I'm trying to start tomcat with a teamcity deployment build step. The steps below all work with no issues when ran directly, but do not work in a teamcity step. The java window appears and closes, as though the build step kills all child processes when completed. I have tried all of the following:
batch (command line running a batch in sources, or right in teamcity script, and command line, and process build types):
call "%env.CATALINA_HOME%\bin\startup.bat"
start "%env.CATALINA_HOME%\bin\startup.bat"
cmd /k "%env.CATALINA_HOME%\bin\startup.bat"
start "DEV server" "%env.CATALINA_HOME%\bin\startup.bat"
powershell:
# wasnt sure if env var was being carried over, not relevant
$env:CATALINA_HOME = %env.CATALINA_HOME%
Start-Process "%env.CATALINA_HOME%\bin\startup.bat"
is there some way to tell TeamCity 10 build step 'hey, leave whatever was started running'?
CATALINA_HOME is an environment variable in the teamcity parameters (env.CATALINA_HOME) and is set to "C:\apache-tomcat" which is correct.
Some additional information: the TC server and agent is running as a user account, the user account has access to all folders (and is local admin) as well.
in tomcat bin\setenv.bat I had CATALINA_OPTS -XmX and -Xms parameters which were very large and required 64 bit java.
When doing this specific build parameter (which I recommend for debugging, it will block the TC build)
%env.CATALINA_HOME%\bin\catalina.bat
(argument: run)
I then got an exit code 1 build failure with a useful error message (but no tomcat logs):
[08:25:24]Error: Could not create the Java Virtual Machine.
[08:25:24]Error: A fatal exception has occurred. Program will exit.
[08:25:24]Invalid maximum heap size: -Xmx32768m
[08:25:24]The specified size exceeds the maximum representable size.
[08:25:24]Process exited with code 1
If you need large Xmx and Xms of a child process, the BUILD AGENT executing the build needs to be running from 64 bit as well! In my case, I had, eg
C:\Teamcity_BuildAgent_Deploy\jre
I copy pasted my 64 bit jre installation in there as well per TC docs and then it could start processes with large Xmx and Xms. I did not adjust TEAMCITY_AGENT_MEM_OPTS or any batches.
I need to run Jboss 7 as service.
Followed these steps :-
Copied my Jboss to C:\Program Files <86>
Downloaded Jboss-native-2.0.10-windows-x64-ssl and copied the contenst of bin catalog to %JBOSS_HOME%/bin
Changes done on service.bat as per link instructions
https://community.jboss.org/message/724488
Changed my dir location to my Jboss bin
and given command service.bat install
C:\Program Files \jboss7>bin>service.bat install
Failed installing JBAS50SVC
Access is Denied.
Service JBoss Application Server 7.1.1 installed.
I'm not able to rectify this problem .
It appears to be windows access issue.
Try the following:
Does the windows ID you are using have Administrator privileges? If no, get a Admin ID else if Yes, proceed to step 2.
Try to do the same but in some other drive (not c: )
UPDATE #1 : OP says he can not see the output of service.bat file
Follow the following steps
Open start menu
Search for "cmd"
Right click "cmd" and run as Administrator
type in following command
cd C:\Program Files \jboss7\bin
Type service.bat and observe the output
On a 2008 Windows Server this occurs because you're not running the command line as an administrator. Those of us who have spent considerable amounts of time on 2003 server, and others before that, keep forgetting that your logged in ADMIN level account does NOT get passed to the command line automatically like with previous versions of Windows.
With any additional errors, past this one, I would keep going back to the service.bat file and looking at the path statements, throughout that file, to ensure that they are all correct to reach what is correct for your installation.
Also, don't forget to create a log folder under standalone (unless you're doing a domain install). Failure to do that will also cause issues as well.
yoda