Update instructions to work on FC/Ubuntu, Strigo/custom setup

README.md

@@ -19,6 +19,16 @@ This repository contains examples and hands-on labs for various Linux tracing wo
 
 - - -
 
+#### Strigo Virtual Environment
+
+When this workshop is delivered as instructor-led training, the instructor will provision a Strigo virtual classroom (EC2 instances) for each student. To use the Strigo virtual environment:
+
+1. Log in to Strigo using the link provided by the instructor (you can log in with Google or create a new account, no verification required)
+1. Enter the classroom token (four characters) provided by the instructor to join the classroom
+1. Navigate to the Lab tab (fourth from the top, the icon that looks like a test tube) to get your EC2 instance started
+
+- - -
+
 #### Labs
 
 1. [Probing Tracepoints with ftrace](ftrace.md)

bpf-contention.md

@@ -9,7 +9,8 @@ In this lab, you will experiment with what it takes to write your own BPF-based
 First, you'll build a multi-threaded application ([parprimes.c](parprimes.c)) that calculates -- guess what -- prime numbers. It does so in multiple threads and uses a mutex, which makes it a good candidate for our purposes. Run the following command to build it:
 
 ```
-$ gcc -g -lpthread parprimes.c -o parprimes
+$ gcc -g -lpthread parprimes.c -o parprimes     # on Fedora
+# gcc -g -pthread parprimes.c -o parprimes      # on Ubuntu
 ```
 
 Try to run it with the following parameters, just to see that it works:

bpf-io.md

@@ -9,7 +9,8 @@ In this lab, you will experiment with some of the task-focused tools from BCC to
 You will need to generate a bunch of data so we can monitor the database while inserting items and while querying them. To do so, use the provided [data_access.py](data_access.py) script. It takes a single command-line argument, which can be either `insert`, `insert_once`, or `select`. But first, we need to make sure MySQL is running:
 
 ```
-# systemctl start mariadb
+# systemctl start mariadb   # on Fedora
+# systemctl start mysql     # on Ubuntu
 ```
 
 Now run the insert script using the following command (it will run in an infinite loop):
@@ -42,11 +43,10 @@ OK, so we are seeing some block I/O being submitted. Let's take a look at the ca
 # stackcount -i 10 submit_bio
 ```
 
-From the output, it's clear that there are a lot of fsyncs and a lot of writes, all to XFS. Let's try a couple of dedicated XFS tools next to figure out what's happening there:
+It seems that there are quite a few I/O operations. Let's take a look at some of the slower ones (slower than 1ms):
 
 ```
-# xfsdist 5 1
-# xfsslower
+# fileslower 1
 ```
 
 OK, so which files are being touched by mysqld while you're inserting rows? Run the following command to find out:

bpf-memleak.md

@@ -31,7 +31,7 @@ Use the following command to run `memleak` and attach to the word count applicat
 By default, `memleak` will print the top 10 stacks sorted by oustanding allocations -- that is, allocations performed and not freed since the tool has attached to your process. Try to analyze these call stacks yourself. Note that the C++ compiler does not make it very easy to understand what's going on because of name mangling -- you can pipe `memleak`'s output through the `c++filt` utility, which should help.
 
 The most obvious source of allocations is in the `word_counter::word_count` method, which calls `std::copy` to read from the input file. It pushes a bunch of strings into a vector using a `std::back_insert_iterator`. However, it's not obvious why these strings aren't being reclaimed when we move to the next file. What's surprising is that the `std::shared_ptr` to the `word_counter` class, allocated in the `main` function, isn't being freed either. For each file processed, we allocate a
-`word_counter` that is not freed. At this point, you should inspect the [wordcount.cc](wordcount.cc) source file carefully and try to determine where the memory leak is coming from.
+`word_counter` that is not freed. At this point, you could inspect the [wordcount.cc](wordcount.cc) source file carefully and try to determine where the memory leak is coming from.
 
 > Hint: `std::shared_ptr`s do not automatically break cyclic references. Two objects referring to each other through a `std::shared_ptr` will not be automatically reclaimed.
 

bpf-usdt.md

@@ -8,7 +8,7 @@ In this lab, you will experiment with discovering USDT probes in a running proce
 
 The `tplist` tool from the BCC collection can discover USDT probes in an on-disk executable, library, or running process. It can also tell you a lot of details about the probe locations and arguments. Unfortunately, it doesn't tell you the *meaning* of these arguments -- you often have to discover them yourself by using the documentation. In this section, you will walk through this process for the Node.js main executable, `node`.
 
-If you haven't already, clone the [Node.js](https://github.com/nodejs/node) repository and build it with the `--with-dtrace` flag, which enables USDT support, using the following commands:
+If you're using an instructor-provided appliance, it should already have Node cloned and configured with USDT support. If you're using your own machine, clone the [Node.js](https://github.com/nodejs/node) repository and build it with the `--with-dtrace` flag, which enables USDT support, using the following commands:
 
 ```
 $ git clone https://github.com/nodejs/node.git
@@ -103,7 +103,8 @@ $ curl 'localhost:8080/login?user=dave&pwd=123'
 
 #### Task 3: Enabling and Tracing JVM USDT Probes with `trace`
 
-OpenJDK is also instrumented with a number of USDT probes. Most of them are enabled out of the box, and some must be enabled with a special `-XX:+ExtendedDTraceProbes` flag, because they incur a performance penalty. To explore some of these probes, navigate to your `$JAVA_HOME` and take a look in the **tapset** directory:
+OpenJDK is also instrumented with a number of USDT probes. Most of them are enabled out of the box, and some must be enabled with a special `-XX:+ExtendedDTraceProbes` flag, because they incur a performance penalty. To explore some of these probes, navigate to your `$JAVA_HOME` and take a look in the **tapset** directory (or online: [tapset](https://github.com/mpujari/systemtap-tapset-openjdk9/tree/master/tapset-1.8.0)):
+:
 
 ```
 $ cd /etc/alternatives/java_sdk
@@ -116,7 +117,7 @@ jstack-1.8.0.77-1.b03.fc22.x86_64.stp
 
 These .stp files contain descriptions and declarations for a bunch of probes, including their arguments. As an example, try to find the `gc_collect_tenured_begin` and `gc_collect_tenured_end` probe descriptions.
 
-Now, let's move to a more practical example. You are now going to trace a running Java application and see which classes are being loaded, by using the `class_loaded` probe. First, find its "documentation":
+Now, let's move to a more practical example. You are now going to trace a running Java application and see which classes are being loaded, by using the `class_loaded` probe. First, find its "documentation" by running the following command (or by looking online: [hotspot-1.8.0.stp.in](https://github.com/mpujari/systemtap-tapset-openjdk9/blob/master/tapset-1.8.0/hotspot-1.8.0.stp.in#L208)):
 
 ```
 $ grep -A 10 'probe.*class_loaded' tapset/*.stp
@@ -150,7 +151,7 @@ And now discover the available tracepoints using `tplist`:
 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.77-1.b03.fc22.x86_64/jre/lib/amd64/server/libjvm.so hotspot:class__loaded
 ```
 
-And finally we can trace the interesting tracepoint with `trace`:
+And finally we can trace the interesting tracepoint with `trace` (replace the path to libjvm.so with the appropriate value from your system):
 
 ```
 # trace 'u:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.77-1.b03.fc22.x86_64/jre/lib/amd64/server/libjvm.so:class__loaded "%s", arg1'
@@ -162,7 +163,7 @@ At this point, you should get a trace message whenever a Java app loads a class.
 
 #### Task 4: Using JVM Extended USDT Probes with `argdist`
 
-Finally, let's experiment with one of the extended probes, which isn't always enabled because of its overhead. A couple of these probes are called on method entry and exit, and can be used for simple profiling (albeit with a pretty considerable cost). First, let's find the probes in the .stp file. They are called `method_entry` and `method_return`:
+Finally, let's experiment with one of the extended probes, which isn't always enabled because of its overhead. A couple of these probes are called on method entry and exit, and can be used for simple profiling (albeit with a pretty considerable cost). First, let's find the probes in the .stp file. They are called `method_entry` and `method_return` (or see online: :[`method_entry`](https://github.com/mpujari/systemtap-tapset-openjdk9/blob/master/tapset-1.8.0/hotspot-1.8.0.stp.in#L411) and `method_return`):
 
 ```
 $ grep -A 10 'probe.*method_entry' *.stp

data_access.py

@@ -32,7 +32,7 @@ def select():
             pass
         cursor.close()
 
-connection = mysql.connector.connect(host='localhost', database='test')
+connection = mysql.connector.connect(host='localhost', database='test', user='root')
 
 if "insert" in sys.argv:
     while True: