For the following per command
perf record -e cycles -j any -a -o perf.data -p 3696
I would like to record both user and kernel data. I know that the modifier :uk is valid for cycles, but I don't know if I have to apply ,uk for the -j option. According to the manual
-j, --branch-filter
any: any type of branches
u: only when the branch target is at the user level
k: only when the branch target is in the kernel
hv: only when the target is at the hypervisor level
So, for use data, I typically run perf record -e cycles:u -j any,u -a -o perf.data -p 3696. However, this time
perf record -e cycles:uk -j any,uk -a -o perf.data -p 3696
fails with unknown branch filter.
Is it fine to just use -j any for user and kernel data?
No. Using any means it will sample any 'type' of taken branches (eg. function call/function return/indirect branches etc.).
To record both user and kernel data, you should run perf record like this -
perf record -e cycles:u -j any,u,k -a -o perf.data -p <PID>
Also, you need not use both -a and the -p <PID> options together, in such a case -p <PID> switch overrides the -a option.
Related
I want to create a firewall to Docker container that allows only some IPs and rejects others.
The default setting was like this:
$ sudo iptables --list
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
As documented on the Docker document, this allows all incoming IPs.
So I'm modifying this. I ran the following commands:
sudo iptables -D DOCKER-USER -j RETURN
sudo iptables -A DOCKER-USER -s xx.xx.xx.xx,yy.yy.yy.yy -j ACCEPT
sudo iptables -A DOCKER-USER -j DROP
This should have worked,
my expected result is that if I try to access to the server from the zz.zz.zz.zz IP, it will be rejected, but from xx.xx.xx.xx, it will be passed.
But the result now is, whether I'm accessing from xx.xx.xx.xx (or yy.yy.yy.yy) or zz.zz.zz.zz, the page told me "Failed to connect". So apparently it's being dropped.
I have no idea what is happening, what is cause of this problem. Thanks for your help.
Specify the -i option as documented.
sudo iptables -I DOCKER-USER -i eth0 ! -s your.ip.add.res -j DROP
I have a fish shell completion like this for docker:
# 'docker-subcommands.txt' is an exhaustive list derived from the "Usage" message.
set -l subcoms (cat /etc/fish/completions/docker-subcommands.txt)
# Found '__fish_seen_subcommand_from' in the completion for `systemctl`
# (in /usr/share/fish/completions/...).
complete -f -c docker -n "not __fish_seen_subcommand_from $subcoms" -a "$subcoms"
function _docker_container_action
# The placeholder is needed here because fish will choke on an empty completion list.
echo (docker ps -aq) '{z-placeholder}'
end
function _docker_image_action
echo (docker images -q) '{z-placeholder}'
end
for sc in cp exec inspect restart rm start stop
complete -c docker -n "contains $sc (commandline -poc)" -x -a (_docker_container_action)
end
for sc in rmi run
complete -c docker -n "contains $sc (commandline -poc)" -x -a (_docker_image_action)
end
The problem is that the completion for image and container IDs needs to be dynamic (like file completion), whereas the above seems to run the -a command when the completion file is (re-)sourced.
How can I make this refresh the options when the completion is actually being applied?
I should mention that I've tried quoting the -a command, as seems to be common practice. But then instead of an option for each ID, I get only one completion option, a long string with space escapes in it (\) containing the IDs and \{z-placeholder} at the end. :(
[...] Quoting the -a command does work as long as its output is not produced by echo (which stringifies it). Turns out -a's "choking" problem is not having an argument, which is what happens if you put docker ps -aq there directly and there are no container IDs to list. So this pattern works:
function _docker_container_action
docker ps -aq
end
complete -c docker -n "contains $sc (commandline -poc)" -x -a "(_docker_container_action)"
And no need for my placeholder either.
whereas the above seems to run the -a command when the completion file is (re-sourced).
That's because you've included it here as a command substitution, so when the file is sourced, it expands, and the completion system has no idea what it was before.
But the -a option knows to expand its argument at completion-time, so all you need to do is quote it:
complete -c docker -n "contains $sc (commandline -poc)" -x -a "(_docker_container_action)"
I have a CentOS server with two static IP address (192.168.3.100 and 192.168.3.101) on same NIC and two containers running on it with port mapping as below. The containers use the same default 'bridge' network of docker
192.168.3.100:80->80/tcp container1
192.168.3.101:80->80/tcp container2
From the host, I can execute curl 192.168.3.100 or curl 192.168.3.101 and works fine. From the host/containers I can execute curl 172.17.0.2 or curl 172.17.0.3 and works fine.
But I cannot execute curl 192.168.3.100 or curl 192.168.3.101 from neither of these containers. Ends up with error No route to host. I can ping it though.
What am I missing here? I want to try to avoid using a 192 docker network as I do not want to tie up the address space with one machine. Using docker 1.12.6
Output for iptables reject rules iptables -S | grep -i reject
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
Thanks for your input
If you are able to ping and not able to curl and you get no route to host then it mostly means that your packets are getting rejected through firewall.
Check the iptables using sudo iptables -S or sudo iptables -L -n. If you see a REJECT or REJECT using icmp rule than thats the problem.
If you are not worried about iptables and are ok to clear it. Stop the docker service and run the below
$ iptables -F
$ iptables -X
$ iptables -t nat -F
$ iptables -t nat -X
$ iptables -t mangle -F
$ iptables -t mangle -X
This will clear all the tables. Then start the docker service and run the container again
I am trying Rancher (v.1.2.3) and I am not able to run the agent in the nodes.
1) I've installed the racher server in one node with the following command:
sudo docker run -d --restart=unless-stopped -p 80:8080 rancher/server:v1.2.3
2) Then I go to Add Host, and Ranchers gives me the command to add it.
3) I go to the Node 1, and put the following:
sudo docker run -d --privileged -v /var/run/docker.sock:/var/run /docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.1.2 http:/xxx/v1/scripts/D822D98E34752ABCDE:1890908200000:RASZERSE
4) The command line returns
docker: Error response from daemon: containerd: container did not start before the specified
I don't know what is going wrong, I think the container can not access to Rancher Server, but If do a
curl http:/xxx/v1/scripts/D822D98E34752ABCDE:1890908200000:RASZERSE
I can access it. In addition this is my IPTABLES:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N CATTLE_FORWARD
-N DOCKER
-N DOCKER-ISOLATION
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp- mss-to-pmtu
-A FORWARD -j CATTLE_FORWARD
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o docker_gwbridge -j DOCKER
-A FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker_gwbridge ! -o docker_gwbridge -j ACCEPT
-A FORWARD -i docker_gwbridge -o docker_gwbridge -j DROP
-A CATTLE_FORWARD -m mark --mark 0x668a0 -j ACCEPT
-A DOCKER-ISOLATION -i docker_gwbridge -o docker0 -j DROP
-A DOCKER-ISOLATION -i docker0 -o docker_gwbridge -j DROP
-A DOCKER-ISOLATION -j RETURN
Ubuntu v14.04
Docker v1.12.3
It would be greatly appreciated if you could help me.
Thanks
The full error is presumably "containerd: container did not start before the specified timeout", which means Docker isn't starting the container. Rebooting the host will probably help.
If the nodes which you are using, ie the one where you start rancher/server:v1.2.3 and the one where you start the agent are the same, then there could be internal port access issue.
Rancher uses UDP services/ports like 500 for internal communications. These must be permitted, maybe by adding to firewalld zones etc. Issues might occur if you use managed networking.
I am successfully able to capture with this command line.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w c:\capture.pcap
I have tried this method and it pops the Wireshark command line help window.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w -f 10.0.0.1 and 10.0.0.2 and 10.0.0.3 c:\capture.pcap
I have also tried this way.
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w -f host 10.0.0.1 and 10.0.0.2 and 10.0.0.3 c:\capture.pcap
Neither one of the above work. they both get the same error. I know it is something simple, however I do not know Wireshark well enough.
Thanks.
You have a few problems:
The filename (c:\capture.pcap) must immediately follow the -w flag.
The filter must be "quoted" if it contains spaces.
You must specify the "host" keyword before each address.
The logical operation you want is almost certainly "or", not "and"
Given the above, try:
C:\Program Files\Wireshark\wireshark.exe -i 4 -k -b duration:3600 -w c:\capture.pcap -f "host 10.0.0.1 or host 10.0.0.2 or host 10.0.0.3"