To reiterate, most debugging with strace would be using programs started on the command line and crashing or having a known stop point. I am not going to kid you and say this would be easy.

In your case the issue with the file in “ /var” does not necessarily end tracing, and as soon as it hits this you want the app to crash and stop logging strace lines.

If the program being debugged in strace crashes, then the log lines about the reason for failure will be very close to the end of the file (perhaps a hundred lines or so from the end…there are function calls present for cleanup upon failure as well). Only strace does not require the source code, and strace does not need debug symbols…it works by monitoring system calls to the kernel, including calls to the correct file in “ /var”, and the reason why it fails (nice applications check return values of failed calls and provide a note on the reason for the fail… strace shows the actual returns even if the app throws away the information). Imagine if you were to run a huge application in a debugger like gdb, and every single function call and every single step through the code was logged to a file. An strace log line looks like a C function call, although with slightly altered notation. You could end up with GB of logs before it ever disconnects, even in a very short time. The second thing you’d need to do is probably to redirect strace logs to a remote computer instead of to the Jetson. If you were going to do this, then what you’d need to do is learn to stop the daemon, and manually run an instance of it with sudo, such that upon failure the process will end instead of respawning.

However, strace has enormous volumes of logs. If the daemon were just an individual application I would suggest that if you are really motivated, then you could use strace to see what the failure is. I do not know the specifics of how TeamViewer handles sessions, and how the daemon (running as root) hands off to a new user as a session starts.Ĭontinuous disconnect and connect tells me that authentication starts, fails, and then automatically tries again. In theory TeamViewer could handle more than one session, and thus spawn more than one PID for each session.

How to start teamviewer before login