I do this with Brendan Gregg's opensnoop, which is standard on macOS.

https://www.brendangregg.com/blog/2014-07-25/opensnoop-for-l...

https://github.com/brendangregg/perf-tools/blob/master/opens...

On Windows, Process Monitor does the same thing --- with the additional feature that, since configuration is often stored in the registry there, it will also show which registry keys it touches.

  ps wxa | grep <cmd>  # or pgrep
  strace -f -f -e trace=file <cmd> | grep -v '-1 ENOENT (No such file or directory)$'

IIRC there's some way to filter ENOENT messages with strace instead of grep?

Strace: https://en.wikipedia.org/wiki/Strace

I use quick and dirty greps all the time, even when there is a "better" option available. It just works and is very intuitive in interactive contexts. Probably GP works in a similar way.

Remembered to add the `2>&1` stderr>stdout output redirection:

  ps wxa | grep <cmd>  # or pgrep
  strace -f -f -e trace=file <cmd> 2>&1 | grep -v '-1 ENOENT (No such file or directory)$'

Bash manual > 3. Basic Shell Features > 3.6 Redirections: https://www.gnu.org/software/bash/manual/html_node/Redirecti...

In lieu of strace, IDK how fast `ls -al /proc/${pid}/fd/*` can be polled and logged in search of which config file it is; almost like `lsof -n`:

  pid=$$ # this $SHELL's pid
  help set; # help help
  (set -B; cat /proc/"${pid}"/{cmdline,environ}) \
    | tr '\0' $'\n'

  (while 1; do echo \#$pid; ls -al /proc/${pid}/fd/*; done) | tee "file_handle_to_file_path.${pid}.log"
  # Ctrl-C

It's good Configuration Management practice to wrap managed config with a preamble/postamble indicating at least that some code somewhere wrote that and may overwrite whatever a user might manually change it to (prior to the configuration management system copying over or re-templating the config file content, thus overwriting any manual modifications)

  ## < managed by config_mgmt_system_xyz (in path.to.module.callable) >
  ## </ managed>

I prefer to use process substitution (not in POSIX):

  strace -f -e trace=file -o >(grep -v ENOENT) <cmd>

Interesting. I didn’t know you could do this. I can see how this can come in handy. Apparently there’s dtruss as an alternative for OS X.

https://8thlight.com/insights/dtrace-even-better-than-strace...

No more. At least with apple Silicon dtrace is completely unusable.

It still works if you turn off SIP. This is the same on Apple Silicon and Intel. However, for these purpose of tracking file accesses, I recommend using `eslogger` instead, as it doesn’t require disabling SIP and is faster, among other advantages.

Use fs_usage. https://ss64.com/osx/fs_usage.html

It’ll show all file events. No need to disable SIP. SIP is doing a lot of good work for users and unless you’re doing kernel work or low level coding I’d keep it enabled. Obv. There are other cases but for the general public keep it on.

It’s personal preference. If the security people had their way we’d all be developing on iPads. If SIP interferes with your work: turn it off. Linux doesn’t have SIP and it’s just fine to develop on Linux as well.

100% agree. We would put everyone on chromebooks if we had our way. I don’t think it’s good for productivity and generating new ideas for a company so I never advocate for it.

On M2 it is completely broken. Any usage of dtrace will hang the whole desktop. (Not sure if just the desktop or is it the whole kernel crashing)

Feel free to reference my feedback entry FB12061147 if you're reporting the same.

You can also use Activity Monitor and view process details to see all open file handles etc

Sure but I don't think that most programs keep their config files open the whole time they're running.

There was a man who never existed named Thomas Covenant, created by Stephen R Donaldson. Decades ago this character said something that has stayed and will stay with me my entire life:

"The best way to hurt somebody who's lost everything is to give him back something that is broken."

For us, this thing is MacOS. I miss dtrace every damn day.

DTrace allowed you to ask the damn os what it was doing, since the man pages are random and do not match the command line help, new daemons constantly appear with docs like this:

NAME rapportd – Rapport Daemon.

SYNOPSIS Daemon that enables Phone Call Handoff and other communication features between Apple devices.

     Use '/usr/libexec/rapportd -V' to get the version.

Dogshit.

There's also fs_usage that doesn't require disabling SIP:

https://mohit.io/blog/fs_usage-trace-file-system-calls-on-ma...

I do this much more frequently than I would like. But occasionally you have issues where the program lists a directory then only acts on specific names. So the strace output won't tell you what the expected name is.

All that time I spent dicking around with lsof...

strace uses ptrace, which some programs disable with prctl as a security measure.

So while this can be a useful hack, it doesn't always work.

Can't disable DTrace :)

Though DTrace is "only" available on Windows, Mac OS X, Solaris, illumos, and FreeBSD.

Oracle has relicensed DTrace to be Linux-friendly and even made kernel patches, but it'll probably never end up in the mainline kernel.

On Linux you can use bpftrace which is basically the same thing with slightly different names.

> Though DTrace is "only" available on Windows

Is it stable and production ready for heavy duty workloads?

Microsoft ships it, so I assume so? I haven't personally ran any versions beyond Windows 7, I can't directly comment on any features after that.

You can use sysdig instead, which doesn't use ptrace[1] and is much faster (as well as generally more pleasant and powerful).

[1]It used to have its own kernel extension but is eEBF based these days.

Users should be aware that `sudo apt install sysdig` may require reconfiguration of UEFI Secure Boot, and that there is no apparent clean abort from this possible. The raw-mode terminal screen contains the text:

  ┌────────────────────────┤ Configuring Secure Boot ├────────────────────────┐
  │                                                                           │ 
  │ Your system has UEFI Secure Boot enabled.                                 │ 
  │                                                                           │ 
  │ UEFI Secure Boot requires additional configuration to work with           │ 
  │ third-party drivers.                                                      │ 
  │                                                                           │ 
  │ The system will assist you in configuring UEFI Secure Boot. To permit     │ 
  │ the use of third-party drivers, a new Machine-Owner Key (MOK) has been    │ 
  │ generated. This key now needs to be enrolled in your system's firmware.   │ 
  │                                                                           │ 
  │ To ensure that this change is being made by you as an authorized user,    │ 
  │ and not by an attacker, you must choose a password now and then confirm   │ 
  │ the change after reboot using the same password, in both the "Enroll      │ 
  │ MOK" and "Change Secure Boot state" menus that will be presented to you   │ 
  │ when this system reboots.                                                 │ 
  │                                                                           │ 
  │ If you proceed but do not confirm the password upon reboot, Ubuntu will   │ 
  │ still be able to boot on your system but any hardware that requires       │ 
  │ third-party drivers to work correctly may not be usable.                  │ 
  │                                                                           │ 
  │                                  <Ok>                                     │ 
  │                                                                           │ 
  └───────────────────────────────────────────────────────────────────────────┘

This leads to a second screen asking for a new password. There is a <Cancel> option, but selecting it merely loops back to the first screen.

Hitting C-c (Control-c) has no effect.

There are validity rules for the password, but they are presented only after you've entered an invalid password, twice, the second time to confirm.

After this installation proceeds, then terminates with a warning:

  DKMS: install completed.
  Processing triggers for man-db (2.9.1-1) ...
  Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
  W: Operation was interrupted before it could finish

Where the "W:" above is colored red.

Distro was Ubuntu 20.04.

I suspect that's just because you're trying to install an old version (as I wrote sysdig used to have a kernel extension but now should use eBPF functionality provided in stock kernels). I can't easily verify (no ubuntu at hand), but presumably if you install the vendor supplied, up-to-date version (first google hit I found: https://www.linuxcapable.com/how-to-install-sysdig-on-ubuntu...) it will work without UEFI changes.

+1 for putting together that blog post on Cold Steel. Greetings from PH3 ;)

Thank you for your efforts!

These days Proton makes a lot of this unnecessary. I hope Trails games will continue to at least function on Linux. :)