The fds problem may comes from slow consumption

There are some possible reasons that have been thought:
- auditd lost. Each time I use `auditctl -b xxx` or `auditctl
  --reset-lost`, there are always a big number of losts. at first i
  thought it means how many auditd info was lost throw the net, or
  how many was thrown because of the audit info queue in the kernel
  was full. However, form the src code of kernel, it actually means
  how much is thrown away as there's no listener of auditd info. In
  other words, audit is a userspace-kernel function, but not two
  independent parts.
- audit backlog size. As the above.

But when i only listen to the syscall "open", i can almost always
hear the info in the docker. So I think this may be because the
audit info production is flooding, while in this program i check this
and that, causes too much time, the consumption is far slower.

Next step, I will use the MVC, all recvd info will be push into the
database, and add a new independent part to make database clean and
clear.

The key problem is, a process can open file1 as fd 3, write, close,
and open file2 as fd 3, write, close: which means i must figure out
which file to write when "write" event comes. Now i check the
pid/fd/close_time in database to choose which is written, but find
and check doc also use lots of time. Maybe, use two collections, one
is fds that records files not closed, the other records closed files?

Besides, as clone/fork/pthread_create all uses syscall clone, but
their flags are different. Maybe i can also use `pid/tgid` pair to
distinguish between process and thread. Good idea.

Be quick, your internship has passed a half. What kinds of answer
will you hand in?

0 files changed, 0 insertions, 0 deletions