Use ltrace and strace to track Linux Process events and assist in troubleshooting

[Original post address: Success. First, take a look at the description of ltrace and strace: ltrace-a library call tracerstrace-trace system CILS and signals below I use a simple example of C and C ++ to demonstrate their usage, using C and C ++ at the same time also means a little comparison. Main. C # include <stdio. h> int main () {printf ("Hello world! "); Return 0;} Main. cpp # include <iostream> int main () {STD: cout <" Hello world! "<STD: Endl; return 0;} if you are interested, you can first compare the assembly code generated by the two. The Assembly content is related to the trance result. Compile the Assembly Code as follows (due to the length limitation of Baidu blog, attachments cannot be uploaded, so they will not be posted): gcc-s. /main. c-o main. c. SG ++-s. /main. CPP-O main. CPP. s. Next, compile the binary file: GCC. /main. c-o. /main_cg ++. /main. CPP-o. /main_cpp View File main_c main_cpp attributes: Elf 64-bit LSB executable, amd x86-64, Version 1 (sysv), for GNU/Linux 2.6.9, dynamically linked (uses SHARED libs ), for GNU/Linux 2.6.9, not stripped both run the same result and print "Hello World!" And then exit. Next, let's look at the trace results. Ltrace./main_c _ libc_start_main (0x400498, 1, 0x7fffeb89e8a8, 0x4004d0, 0x4004c0 <unfinished...> printf ("Hello world! ") = 13 Hello world! ++ Exited (status 0) ++ ltrace. /main_cpp _ libc_start_main (0x400844, 1, 0x7fff01389398, 0x400880, 0x400870 <unfinished...> _ primary (0x600e2c, 65535, primary, 3, 0x31e1752350) = 2 _ cxa_atexit (0x40082c, 0, 0x400960, 3, 0x31e1752350) = primary (0x600d10, 0x400968, 0x7fff013893a8, 4, 0x31e1752370) = 0x600d10_znsolsepfrsos_e (0x600d1 0, 0x4006e0, 0, 0xfbad2a84, 0 xffffffff <unfinished...> _ blank _ (0x600d10, 0x4006e0, 0, 0xfbad2a84, 0 xffffffffffhello world !) = 0x600d10_znst8ios_base4initd1ev (0x600e2c, 0, 0x31e1752370,-1, 0x2b2e79280530) = 3 ++ exited (status 0) ++, the C language is really concise! Next, let's take a look at the strace result (some data is omitted due to space restrictions): strace. /main_cexecve (". /main_c ",[". /main_c "], [/* 30 vars */]) = 0brk (0) = 0x1a9d4000uname ({sys =" Linux ", node =" cece106 ",...}) = 0 access ("/etc/lD. so. preload ", r_ OK) =-1 enoent (no such file or directory) Open ("/etc/lD. so. cache ", o_rdonly) = 3 fstat (3, {st_mode = s_ifreg | 0644, st_size = 68624 ,...}) = 0 MMAP (null, 68624, prot_read, map_private, 3, 0) = 0x2afefc5f60 00 close (3) = 0 open ("/lib64/libc. so.6 ", o_rdonly) = 3 read (3, "/177elf/2/1/1/0/0/0/0/0/0/0/0/0>/3/0/0/1/0/0/0/220/332a/3411/0/0/0 "..., 832) = 832 mprotect (0x31e154d000, 2097152, prot_none) = 0 close (3) = 0arch_prctl (arch_set_fs, 0x2afefc608210) = 0 write (1, "Hello world! ", 13 Hello world !) = 13exit_group (0) strace. /main_cppexecve (". /main_cpp ",[". /main_cpp "], [/* 30 vars */]) = 0brk (0) = 0x1d954000mmap (null, 4096, prot_read | prot_write, map_private | map_anonymous,-1, 0) = 0x2b4f71efd000uname ({sys = "Linux", node = "performance106 ",...}) = 0 access ("/etc/lD. so. preload ", r_ OK) =-1 enoent (no such file or directory) Open ("/etc/lD. so. cache ", o_rdonly) = 3 fstat (3, {st_mode = s_ifreg | 0644, st_si Ze = 68624 ,...}) = 0 close (3) = 0 open ("/usr/lib64/libstdc ++. so.6 ", o_rdonly) = 3arch_prctl (arch_set_fs, bytes) = 0 mprotect (0x31e121b000, 4096, prot_read) = 0 munmap (bytes, 68624) = 0 fstat (1, {st_mode = s_ifchr | 0620, st_rdev = makedev (136, 1 ),...}) = 0 MMAP (null, 4096, prot_read | prot_write, map_private | map_anonymous,-1, 0) = 0x2b4f71efe000write (1, "Hello world! /N ", 14 Hello world !) = 14exit_group (0) =? From the perspective of the System Call process, the final method is the same, but the C ++ process is cumbersome. The above example captures the execution process of the executable program, and can also capture the events being executed inside the service program. For example, what services such as nginx, Apache, and Python are currently doing and there is a reference phase when exceptions occur. Because Java uses its own virtual machine, you must use the corresponding monitoring tools (such as jprofile, jconsole, and jvisualvm) of Java ). If you use ltrace for tracking, you will receive "cannot attach to PID 18663: operation not permitted ". Generally, commands such as truss, GDB, pstack, pfiles, top, lsof, pmap, netstat, and PS are used for analysis.