CODEWITHSUNDEEP
linuxcapturetty
rafgrz
rafgrz

Reputation: 41

Capturing /dev/tty0 output to file

I'm newbie to Linux, so I've got gut feeling that answer is trivial, but after couple of days of looking for the answer I'm giving up and counting on your help...

I'm using software on CentOS 7. When I start it on TTY pseudo terminal (e.g. /dev/tty2) it prints out a lot of interesting information on the screen I need to analyze. Due to amount of information and for archiving I would like to save them in a file. So obviously I tried to redirect stdout, stderr to a file, but it turned out I can save only small portion of the information visible on the terminal screen (hundreds of lines). I used strace later to figure out the way application prints those information on the screen - it is writing to /dev/tty0 device (not /dev/tty, but /dev/tty0, currently visible console, which makes - I think - a big difference). Realizing this I tried many possible solutions to capture this output including:

It all works well for catching /dev/tty writes, but not for /dev/tty0!

Can you suggest any solution or even just an idea I could try?

Upvotes: 3

Views: 1983

Answers (1)

rafgrz
rafgrz

Reputation: 41

for those who may be interested... After couple of weeks of experimenting I share what I've learnt:

  1. Force-preloading method - easy and quick one, but with major drawback in my case - it in fact doesn't intercept syscalls, but libc standard library calls. Drawback, as application can directly call syscall bypassing libraries and it won't be intercepted. It happened in my case.

  2. Later on I tried kernel module, relatively quickly I could create basic one with intercepting syscalls by modifying syscall function address in syscall_table (requires some dirty hacks, like unprotecting write to that memory with CR0 register manipulation, etc...), but more I tried to progress I have faced more issues, especially in the context of intercepting process which is forking children, and I want to intercept syscalls for the forked processes as well. Of course big plus is that you have an ultimate access to any kernel structures, etc... After some time I've given up and tried the third option.

  3. Ptrace method - looks like complex one at first sight, but is quite logical, but you need to read longy man to have understanding. Again for forked processes things get complicated, but I'm close to create workable solution now, and stuff like PTRACE_O_TRACEFORK etc. helps a lot.

My conclusion - creation of universal solution for this is not an easy stuff anyway (for instance look at 'strace' source code...), for me ptrace is the best option, however you need to invest some time to understand it, especially for forking processes.

Conclusion no. 2 - trying to solve the issue it was great adventure for me and diving into depths of linux kernel and how syscall works was amazing learning :)

Thank you melpomene for inspiration! :)

Upvotes: 1

Related Questions