I'm trying to use govc to enable cpu performace counters on a vm but can't quite figure out how to do it...in the UI I have to shut it down, enable them, and then start it back up...but I don't see an option to enable cpu performance counters in govc
Ronak Patel [7:17 PM]
specifically trying to get VPMCEnabled enabled
when I run govc vm.option.info -vm "vm name" I get that option under Config.VPMCEnabled but I can't figure out how to flip that flag
I've tried all of these but none seem to work:
govc vm.change -vm="Admin" -e vcpu.vpmc=false
govc vm.change -vm="Admin" -e vcpu.vpmcenabled=false
govc vm.change -vm="Admin" -e vpmcenabled=false
govc vm.change -vm="Admin" -e config.vpmc=false
I also noticed that I can change the CPU Hot add like this:
govc vm.change -vm="Admin" -e vcpu.hotadd=false```
but the same syntax doesn't work for the cpu performance counters
Related
I have been searching around for over an hour and I am not quite finding what I am looking for. I am trying to perform a grep match to make sure the syntax in a command is correct before proceeding.
Contents of file:
deploy type:apptype1 artifact:coolio version:1.1.1 in dev
What I am looking for is to allow multiple types, artifact, version and allow for only dev or qa. Any other text added or missing should fail.
What I have tried so far is:
grep -ie "deploy type:apptype1\|apptype2\|apptype3 artifact:.*version:.*in dev\|qa file
The problem is if I add additional text or even change "in" to "on" it still matches. I suspect it is only matching the first part and not the entire line like I am wanting?
Use GNU grep:
grep -P '^deploy type:(apptype1|apptype2|apptype3) artifact:.*version:.*in (dev|qa)$' in_file
Example:
cat > in_file <<EOF
deploy type:apptype1 artifact:coolio version:1.1.1 in dev
deploy type:apptype2 artifact:coolio version:1.1.1 in qa
deploy type:apptype1 artifact:coolio version:1.1.1 on dev
EOF
grep -P '^deploy type:(apptype1|apptype2|apptype3) artifact:.*version:.*in (dev|qa)$' in_file
Output:
deploy type:apptype1 artifact:coolio version:1.1.1 in dev
deploy type:apptype2 artifact:coolio version:1.1.1 in qa
Here, GNU grep uses option:
-P : Use Perl regexes.
^ : Beginning of the line.
$ : End of the line.
SEE ALSO:
perlre - Perl regular expressions
This works for me :
echo "deploy type:apptype2 artifact:coolio version:1.1.1 in dev" | grep -i -E "deploy type:(apptype1|apptype2|apptype3) artifact:.*version:.*in (dev|qa)"
Note the > color on the next line indicating previous command returned 0 (Green) or else non zero (Red)
Based on your example, here is a solution for BSD/GNU grep:
grep -ie "deploy type:apptype[123] artifact:[[:alnum:]].* version:[[:alnum:]].* in [(dev\|qa)]" file
Edit
#timur-shtatland's answer is better - my answer will not exclude "dev_test" or "qa_temp"
I'm writing a daemon that will log in to other machines to confirm that a service is running and also start, stop, or kill it. Because of this, the unix commands get a little long and obfuscated.
The basic shape of the commands that are forming are like:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "APP.*APP_id=12345"'
Where APP is the name of the remote executable and APP_id is a parameter passed to the application when started.
The executable running on the remote side will be started with something like:
/path/to/APP configs/config.xml -v APP_id=12345 APP_port=2345 APP_priority=7
The exit status of this command is used to determine if the remote service is running or was successfully started or killed.
The problem I'm having is that when testing on my local machine, ssh connects to the local machine to make things easier, but pgrep called this way will also identify the ssh command that the server is running to do the check.
For example, pgrep may return:
26308 ./APP configs/config.xml APP_id=128bb8da-9a0b-474b-a0de-528c9edfc0a5 APP_nodeType=all APP_exportPort=6500 APP_clientPriority=11
27915 ssh -p 22 user#localhost pgrep -fl APP.*APP_id=128bb8da-9a0b-474b-a0de-528c9edfc0a5
So the logical next step was to change the pgrep pattern to exclude 'ssh', but this seems impossible because pgrep does not seem to be compiled with a PCRE version that allows lookaheads, for example:
bash -c -'ssh -p 22 user#localhost preg -fl "\(?!ssh\).*APP.*APP_id=12345"
This will throw a regex error, so as a workaround I was using grep:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "APP.*APP_id=12345" \\| grep -v ssh'
This works well for querying with pgrep even though it's a workaround. However, the next step using pkill doesn't work because there's no opportunity for grep to be effective:
bash -c 'ssh -p 22 user#host.domain.com pkill -f "APP.*APP_id=12345"'
Doesn't work well because pkill also kills the ssh connection which causes the exit status to be bad. So, I'm back to modifying my pgrep/pkill pattern and not having much luck.
This environment can be simulated with something simple on a local machine that can ssh to itself without a password (in this case, APP would be 'watch'):
watch echo APP_id=12345
Here is the question simply put: How do I match 'APP' but not 'ssh user#host APP' in pgrep?
It's kind of a workaround, but does the job:
bash -c 'ssh -p 22 user#host.domain.com pgrep -fl "^[^\s]*APP.*APP_id=12345"'
...which only matches commands that have no space before the application name. This isn't entirely complete, because it's possible that the path to the executable may contain a directory with spaces, but without lookaround syntax I haven't thought of another way to make this work.
really old q but!
export VAR="agent.py"; pkill -f .*my$VAR;
I'm trying to setup my gdbinit to make gdb automatically attach to a certain program on a remote machine.
My script is something like:
define hook-run
target extended-remote | ssh -T remotemachine gdbserver --multi -
attach $pid
... <additional complicated stuff here>
end
My problem, of course, is that I'm missing $pid. I can find it by running ssh remotemachine ps | grep myprogram, but I'm not sure how to run that from within the gdb script and assign it into that $pid variable. How can I do that? I'm guessing I'm going to need some Python here...
I can find it by running ssh remotemachine ps | grep myprogram
I believe your choices are
use Python, or
escape to shell
For (2) you can use something like:
define hook-run
shell gen-remote-run.sh > .remote-cmd.gdb
source .remote-cmd.gdb
end
and put all the "magic" of figuring out remote PID into gen-remote-run.sh
We did alot of stuff with Vagrant in the recent days, and there's a problem we encountered / didn't find any answer to. It's about checking the Status of the VirtualBox with Vagrant, for example:
if config.vmbox_status == 'running'
# do this stuff
end
If there is any easy way of checking / getting the current Virtual Box status let us know.
If you want to check running status with shell script. Try this code inside your project folder
vagrant status --machine-readable | grep state,running
Then check output string or exit code
You can use egrep to get current status (other answers check for certain statuses while this approach allows you to use case or if in scrips, like that (ugly and not-bullet proof!):
VM_STATUS=$(vagrant status --machine-readable | grep ",state," | egrep -o '([a-z_]*)$')
case "${VM_STATUS}" in
running)
echo "RUNNING"
;;
poweroff)
echo "POWEROFF"
;;
*)
echo "Unhandled: ${VM_STATUS}"
;;
esac
Or with the use of awk to get the VM's current state:
VM_STATUS=`vagrant status --machine-readable | grep ",state," | awk -F, '{print $4}'`
case "${VM_STATUS}" in
running)
echo "RUNNING"
;;
poweroff)
echo "POWEROFF"
;;
*)
echo "Unhandled: ${VM_STATUS}"
;;
esac
I am not sure if you want to do this within Vagrantfile necessarily but outside of it you can fire command vagrant status BOX_NAME and get the status of box. You will get text in following format:
Current VM states:
box2 running
change directory to location of VM: cd d:/vagant_boxes
run: vagrant status
I have a extremely complicated shell script, within which it calls a C++ program I want to debug via GDB. It is extremely hard to separate this c++ program from the shell since it has a lot of branches and a lot of environmental variables setting.
Is there a way to invoke GDB on this shell script? Looks like gdb requires me to call on a C++ program directly.
In addition to options mentioned by #diverscuba23, you could do the following:
gdb --args bash <script>
(assuming it's a bash script. Else adapt accordingly)
There are two options that you can do:
Invoke GDB directly within the shell script. This would imply that you don't have standard in and standard out redirected.
Run the shell script and then attach the debugger to the already running C++ process like so: gdb progname 1234 where 1234 is the process ID of the running C++ process.
If you need to do things before the program starts running then option 1 would be the better choice, otherwise option 2 is the cleaner way.
Modify the c++ application to print its pid and sleep 30 seconds (perhaps based on environment or an argument). Attach to the running instance with gdb.
I would probably modify the script to always call gdb (and revert this later) or add an option to call gdb. This will almost always be the easiest solution.
The next easiest would be to temporarily move your executable and replace it with a shell script that runs gdb on the moved program. For example, in the directory containing your program:
$ mv program _program
$ (echo "#!/bin/sh"; echo "exec gdb $PWD/_program") > program
$ chmod +x program
Could you just temporarily add gdb to your script?
Although the answers given are valid, sometimes you don't have permissions to change the script to execute gdb or to modify the program to add additional output to attach through pid.
Luckily, there is yet another way through the power of bash
Use ps, grep and awk to pick-out the pid for you after its been executed. You can do this by either wrapping the other script with your own or by just executing a command yourself.
That command might look something like this:
process.sh
#!/usr/bin/env bash
#setup for this example
#this will execute vim (with cmdline options) as a child to bash
#we will attempt to attach to this process
vim ~/.vimrc
To get gdb to attach, we'd just need to execute the following:
gdb --pid $(ps -ef | grep -ve grep | grep vim | awk '{print $2}')
I use ps -ef here to list the processes and their arguments. Sometimes, you'll have multiple instances of a program running and need to further grep down to the one you want
the grep -ve grep is there because the f option to ps will include the next grep in its list. If you don't need the command arguments for additional filtering, don't include the -f option for ps and ignore this piece
grep vim is where we're finding our desired process. If you needed more filtering, you could just do something like grep -E "vim.*vimrc" and filter down to exactly the process that you're trying to attach to
awk '{print $2}' simply outputs just the process' pid to stdout. Use $1 if you're using ps -e instead of ps -ef
My normal setup is to run such script that starts my process in 1 tmux pane and having typed something similar to the above in a bottom pane. That way if I need to adjust the filtering (for whatever reason), I can do it pretty quickly.
Usually though, it will be the same for a specific instance and I want to just attach automatically after its been started. I'll do the following instead:
runGdb.py
#!/usr/bin/env bash
./process.sh &
PID=$(ps -ef | grep -ve grep | grep -E "vim.*vimrc" | awk '{print $2}')
#or
#PID=$(ps -e | grep vim | awk '{print $1}')
gdb --pid $PID
This assumes that the original process can be safely run in the background.