3 ms·

It's like a debugger for networking, and surprisingly many programmers don't know how to use debuggers either.

by seiferteric 3y ago

x86x87 3y ago
It's more like strace but yeah.
- auguzanellato 3y ago
  And a lot of programmers don’t know about strace either
  - maximus-decimus 3y ago
    I can confirm, I didn't know about strace until this very moment. Looking at it, it basically only intercepts system calls? How often is that useful? What do people use it for?
    - mitchs 3y ago
      The most fun I've had with strace was debugging a 3-process deadlock. An snmp daemon was blocked waiting for a cli child process to finish, the cli was waiting for a response to a message on a socket it had open with a routing protocol daemon, which was waiting for a response from the snmp daemon. It is also a great way to figure out why programs without useful debug output die. Ie. after a program opens and reads a config file it doesn't like, it starts cleaning up and exits.
    - jeffreygoesto 3y ago
      I recently fired it up to quickly check which headers a crosscompiler used on a specific compilation unit. strace, grep, sort, done. I also use it as first check if something seems to hang. Sometimes you can see lock files trying to be acquired or access to wrong paths.
      - jeffreygoesto 3y ago
        Just recently I found something performing way better for that task: https://brendangregg.com/blog/2014-07-25/opensnoop-for-linux.html https://brendangregg.com/blog/2014-07-25/opensnoop-for-linux...
    - aseipp 3y ago
      Program shits itself randomly during execution, crashes, and doesn't tell you why. strace it. Oh, it turns out it's trying to execve() a binary that doesn't exist on the system, which wasn't documented as a dependency, so I didn't install it. Fixed. Lots of little things like that. Why is this program acting slow at startup when it should be fast? Oh, because it's opening and timing out on a socket connection with an unusually long timeout. Et cetera...
    - x86x87 3y ago
      it's useful when everything else you've tried failed and you have no clue what is going on. it's extremely helpful in figuring out why a program hangs or crashes. it's a good tool to have in the toolbox
    - pdw 3y ago
      `strace -f -eopen,openat` to see which files a programs opens. Very often useful, even if just to check which config file(s) a program reads.
    - TristanBall 3y ago
      It answers, or at least gives the definitive first clue behind a huge number of slow downs or apparent hangs, given how many of those are actually blocking resource waits or retry loops gone mad. It's probably most useful to sysadmins working with binaries, or even if you do do have the source, it's usually a shorter path to the solution for any app/os interaction problem. It's useful for certain classes of optimisation and tuning, because it will give timings and aggregate timings. I'll use it for things as simple as "where is this program reading it's config files" - often useful when doco is poor and/or there are multiple config locations selected by conditional logic. There's an "ltrace" as well, for share library tracing, although I've personally found that less useful - bugs that that shows are more likely to be code/logic problems rather that os/infrastructure interaction - which is to say, usually outside my job scope. On commercial unix, the equivalent to strace is truss, and it's been around forever. Like many, wirewhark, strace/truss are my go-to tools for a huge amount of troubleshooting.
    - klysm 3y ago
      It lets you see what a program is doing, where doing means any “effects” of the program that touch the system. Want to see whatS happening to files? You can strace for certain operations to certain files. Weird shitting the bed involving IO? Strace will illuminate the problem
    - jcul 3y ago
      As well as all the other uses, it can be great for a quick way to see what files a program is trying to access. E.g. some undocumented binary where it's not clear where its config should be, strace will quickly show what it tries to access.
    - michaelcampbell 3y ago
      I've used it on occasions to try and find why some app was erroring; typically the app would catch an exception (or ALL of them), and just die with something like "no." For example if the open call fails with ENOENT, the file it's looking for doesn't exist, and strace will (also) tell you what file it's trying to open.
    - dekhn 3y ago
      I use it constantly. I can't even imagine debugging some failures without strace. It's great for servers that don't log things but fail to load some config file (which can be debugged by inspecting the return codes of open() calls. There is also ltrace, for library calls, although I find it less useful.

It's like a debugger for networking, and surprisingly many programmers don't know how to use debuggers either.

x86x87 3y ago

It's more like strace but yeah.

auguzanellato 3y ago
And a lot of programmers don’t know about strace either
- maximus-decimus 3y ago
  I can confirm, I didn't know about strace until this very moment. Looking at it, it basically only intercepts system calls? How often is that useful? What do people use it for?
  - mitchs 3y ago
    The most fun I've had with strace was debugging a 3-process deadlock. An snmp daemon was blocked waiting for a cli child process to finish, the cli was waiting for a response to a message on a socket it had open with a routing protocol daemon, which was waiting for a response from the snmp daemon. It is also a great way to figure out why programs without useful debug output die. Ie. after a program opens and reads a config file it doesn't like, it starts cleaning up and exits.
  - jeffreygoesto 3y ago
    I recently fired it up to quickly check which headers a crosscompiler used on a specific compilation unit. strace, grep, sort, done. I also use it as first check if something seems to hang. Sometimes you can see lock files trying to be acquired or access to wrong paths.
    - jeffreygoesto 3y ago
      Just recently I found something performing way better for that task: https://brendangregg.com/blog/2014-07-25/opensnoop-for-linux.html https://brendangregg.com/blog/2014-07-25/opensnoop-for-linux...
  - aseipp 3y ago
    Program shits itself randomly during execution, crashes, and doesn't tell you why. strace it. Oh, it turns out it's trying to execve() a binary that doesn't exist on the system, which wasn't documented as a dependency, so I didn't install it. Fixed. Lots of little things like that. Why is this program acting slow at startup when it should be fast? Oh, because it's opening and timing out on a socket connection with an unusually long timeout. Et cetera...
  - x86x87 3y ago
    it's useful when everything else you've tried failed and you have no clue what is going on. it's extremely helpful in figuring out why a program hangs or crashes. it's a good tool to have in the toolbox
  - pdw 3y ago
    `strace -f -eopen,openat` to see which files a programs opens. Very often useful, even if just to check which config file(s) a program reads.
  - TristanBall 3y ago
    It answers, or at least gives the definitive first clue behind a huge number of slow downs or apparent hangs, given how many of those are actually blocking resource waits or retry loops gone mad. It's probably most useful to sysadmins working with binaries, or even if you do do have the source, it's usually a shorter path to the solution for any app/os interaction problem. It's useful for certain classes of optimisation and tuning, because it will give timings and aggregate timings. I'll use it for things as simple as "where is this program reading it's config files" - often useful when doco is poor and/or there are multiple config locations selected by conditional logic. There's an "ltrace" as well, for share library tracing, although I've personally found that less useful - bugs that that shows are more likely to be code/logic problems rather that os/infrastructure interaction - which is to say, usually outside my job scope. On commercial unix, the equivalent to strace is truss, and it's been around forever. Like many, wirewhark, strace/truss are my go-to tools for a huge amount of troubleshooting.
  - klysm 3y ago
    It lets you see what a program is doing, where doing means any “effects” of the program that touch the system. Want to see whatS happening to files? You can strace for certain operations to certain files. Weird shitting the bed involving IO? Strace will illuminate the problem
  - jcul 3y ago
    As well as all the other uses, it can be great for a quick way to see what files a program is trying to access. E.g. some undocumented binary where it's not clear where its config should be, strace will quickly show what it tries to access.
  - michaelcampbell 3y ago
    I've used it on occasions to try and find why some app was erroring; typically the app would catch an exception (or ALL of them), and just die with something like "no." For example if the open call fails with ENOENT, the file it's looking for doesn't exist, and strace will (also) tell you what file it's trying to open.
  - dekhn 3y ago
    I use it constantly. I can't even imagine debugging some failures without strace. It's great for servers that don't log things but fail to load some config file (which can be debugged by inspecting the return codes of open() calls. There is also ltrace, for library calls, although I find it less useful.