我在一家拥有一定数量的传统批处理stream程的公司工作。
当涉及到数据库连接时，其中一些东西实际上是泄漏的。
Strace不是一个选项，有太多的stream程，它们太短暂，我需要审计多个框。
IPtables不是一个选项，你可以匹配进程path/用户，但是你不能logging这些信息（据我所知）
通常的工具，如lsof / netstat等，只包含有关进程的信息，他们正在使用什么连接。
另一方面，这些批处理作业已经死了 – 所以我不能将进程与套接字相关联。
所以这是学习systemtap的好时机。 或者编写一个定制的内核模块。 但是我没有专业知识/时间来开始入侵syscall表，另外，我想学习systemtap，因为它似乎是非常有用的工具。
我的最终目标是写一个探针，
但恶魔是在细节..我无法得到它安装在Debian（wheezy）（所有），我得到更糟糕的错误在Ubuntu 12（精确）。
在Ubuntu上，一个基本的systemtap探针工作得很好（这些是基本的复制和粘贴示例）。
#! /usr/bin/env stap probe begin { println("hello world") exit () } 它产生预期的输出。
sudo stap -v stapinit.stp Pass 1: parsed user script and 76 library script(s) using 22792virt/13512res/2224shr kb, in 90usr/0sys/93real ms. Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 23056virt/14000res/2304shr kb, in 10usr/0sys/2real ms. Pass 3: translated to C into "/tmp/stap2ntfcM/stap_32acf6b6a3f643d9444c9c8339e390d8_687.c" using 23056virt/14332res/2584shr kb, in 0usr/0sys/0real ms. Pass 4: compiled C into "stap_32acf6b6a3f643d9444c9c8339e390d8_687.ko" in 1290usr/390sys/1902real ms. Pass 5: starting run. hello world Pass 5: run completed in 10usr/40sys/596real ms.
但更复杂的探头就会死亡，例如：
# Show sockets setting options # Return enabled or disabled based on value of optval function getstatus(optval) { if ( optval == 1 ) return "enabling" else return "disabling" } probe begin { print ("\nChecking for apps setting socket options\n") } # Set a socket option probe tcp.setsockopt { status = getstatus(user_int($optval)) printf (" App '%s' (PID %d) is %s socket option %s... ", execname(), pid(), status, optstr) } # Check setting the socket option worked probe tcp.setsockopt.return { if ( ret == 0 ) printf ("success") else printf ("failed") printf ("\n") } probe end { print ("\nClosing down\n") }
生产 –
Pass 1: parsed user script and 76 library script(s) using 22812virt/13660res/2224shr kb, in 90usr/10sys/120real ms. semantic error: missing i386 kernel/module debuginfo under '/lib/modules/3.2.0-27-generic-pae/build' while resolving probe point kernel.function("tcp_setsockopt") semantic error: no match while resolving probe point tcp.setsockopt semantic error: missing i386 kernel/module debuginfo under '/lib/modules/3.2.0-27-generic-pae/build' while resolving probe point kernel.function("tcp_setsockopt").return semantic error: no match while resolving probe point tcp.setsockopt.return Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 23136virt/14424res/2540shr kb, in 70usr/580sys/1255real ms. Pass 2: analysis failed. Try again with another '--vp 01' option.
看来我错过了一个依赖，但我已经安装了厨房的水槽。
sudo apt-get install elfutils sudo apt-get install linux-headers-generic gcc libcap-dev sudo apt-get install systemtap-sdt-dev sudo apt-get install systemtap systemtap-doc linux-image linux-headers-generic-pae
apt-get安装systemtapbuild议的软件包可能有些误导。
linux-headers-virtual，linux-image，linux-source和linux-tools都是虚拟软件包，所以会跟踪当前升级到的任何内核。
sudo apt-get install linux-headers-virtual linux-image linux-source linux-tools
为了好的措施，我还安装了fdutils和kernel-package
sudo apt-get install fdutils kernel-package
将尝试此并报告回来。
还是坏了，同样的错误，这实际上是我试图安装它的第三个系统。
我也发现了以下的Ubuntu错误，也许包是坏的？
https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/824105
看起来Ubuntu上的问题是，它们不会构build内核debugging符号包，或者至less以标准方式分发。 我的结论是，在Ubuntu上，systemtap软件包被破坏，只要它不安装关键的依赖关系。
https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/106957
在我的Debian框中，我有一个不同的问题，testing已启用 – 因此gcc已经升级到4.6，并且linux-headers包需要gcc 4.3
root@datasift:~# apt-get install systemtap linux-image-`uname -r`-dbg linux-headers-`uname -r` Reading package lists... Done Building dependency tree Reading state information... Done systemtap is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: linux-headers-2.6.32-5-amd64 : Depends: gcc-4.3 but it is not going to be installed E: Broken packages root@datasift:~# uname -a Linux datasift.sentimentmetrics.com 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
因此，总而言之，systemtap可能在Debian上正常工作，在Ubuntu上运行的可能性很小，而且我没有时间继续。 我希望我运行BSD / Solaris或者有一个标准的仪器接口，但是不pipe它是否是Linux的商品之神。
更新4
与此同时，我已经设法使用Linux审计框架，灵感来自以下发布：
我怎么能确定哪个进程在Linux上进行UDP通信？
我的审计命令：
auditctl -a exit,always -F arch=b64 -F a0=2 -S socket
以以下格式生成日志消息：
type=SYSCALL msg=audit(1344346149.672:1670): arch=c000003e syscall=41 success=yes exit=5 a0=2 a1=1 a2=6 a3=1999999999999999 items=0 ppid=1 pid=29674 auid=0 uid=1003 gid=1003 euid=1003 suid=1003 fsuid=1003 egid=1003 sgid=1003 fsgid=1003 tty=(none) ses=124 comm="php5" exe="/usr/bin/php5" key=(null)
哪个不错，但最终没用，因为它们不包含程序参数。
我真正需要的东西（至less）是能够反映论点的东西，例如：
exe="/usr/bin/php5" args="/Administraitor/learn-to-code-hehe.php"
理想情况下，我希望能够通过主机和端口进行过滤。
我已经设法使它在Ubuntu上工作，Debian是另一回事。
我已经创build了安装/监视脚本的存储库
https://bitbucket.org/sentimental/poc_stap
脚本也提供程序参数，所以对于顽皮的PHP脚本，现在可以识别错误的人。
不是一个答案，而是一个警告：SystemTap可能会令人困惑，有时甚至只是简单的车，其他时间不直观。 不过，这是一个很好的工具，只需要小心一点，并用其他工具交叉检查结果。
Brendan Gregg的这篇博客文章对SystemTap的奇怪世界进行了非常深入的分析。 当然，由于博客作者通常使用dtrace ，他的观点可能会有偏差。 无论如何，这个post做得非常好，让我再次考虑SystemTap的可靠性。 博客文章也有一些代码示例，可以帮助你解决你的问题。
以下是博客文章的引用：
在使用SystemTap的时候，我一直在logging我一直在做什么，包括什么工作，什么没有，以及我如何解决问题。 这被certificate是一个方便的参考。
在最近关于DTrace的一些主题中，人们询问它如何与SystemTap进行比较 – 有人评论说他们还没有时间研究。 我被鼓励张贴我的经验，这从我的笔记很容易做到。 我可以（也可能应该）将其中的一些进入SystemTap错误数据库。
我分享的是使用SystemTap的各种经验，包括我犯错的时间，因为我不知道自己在做什么。 我将从关于追踪磁盘I / O的叙述开始，它将各种经验联系在一起。 之后，它变得有些不连贯，从各种音符剪辑。 我会尽力保持这种技术性，积极性和build设性。 也许这将有助于SystemTap项目本身，看看用户（具有强大的dynamic跟踪和内核工程背景）所面临的困难。