CARVIEW |
Using fs_usage to see what files a process is using
Today I wanted to figure out where the vercel
CLI tool on my Mac kept its authentication tokens.
I solved the problem using the macOS fs_usage
command, which traces filesystem activity for everything or for a specific process.
I ran vercel login
to start the tool running. Thankfully Vercel's tool pauses at that point and asks you to select a login provider - which means you can find the PID of the new process in another window:
$ vercel login
Vercel CLI 28.16.11
> Log in to Vercel (Use arrow keys)
❯ Continue with GitHub
Continue with GitLab
Continue with Bitbucket
Continue with Email
Continue with SAML Single Sign-On
─────────────────────────────────
Cancel
Then in another window:
$ ps aux | grep vercel
simon 87632 0.0 0.0 408644400 1552 s023 S+ 7:58AM 0:00.00 grep vercel
simon 87587 0.0 0.1 409432576 100576 s021 S+ 7:58AM 0:00.41 node /opt/homebrew/bin/vercel login
Then I started fs_usage
like this:
sudo fs_usage -f pathname 87587
The -f pathname
option filters to just show "Pathname-related events". The PID comes at the end.
With that command running, I completed the login process in the other window. A whole bunch of output was dumped to the fs_usage
window, including the following:
08:02:07.011111 lstat64 /Users/simon/Library/Application Support/com.vercel.cli 0.000006 node.4017721
08:02:07.011124 lstat64 /Users/simon/Library/Application Support/com.vercel.cli/auth.json 0.000011 node.4017721
08:02:07.011587 stat64 /Users/simon/Library/Application Support/com.vercel.cli/auth.json 0.000009 node.4017721
08:02:07.011716 open F=27 (_WC_T______X) /Users/simon/Library/Application Support/com.vercel.cli/auth.json.1284651536 0.000074 node.4017721
08:02:07.019564 close F=27 0.000013 node.4017721
So the answer to my question is that Vercel store their authentication tokens in ~/Library/Application Support/com.vercel.cli/auth.json
.
Sure enough:
$ cat ~/Library/Application\ Support/com.vercel.cli/auth.json
{
"// Note": "This is your Vercel credentials file. DO NOT SHARE!",
"// Docs": "https://vercel.com/docs/project-configuration#global-configuration/auth-json",
"token": "... redacted ..."
}
More fs_usage
Running sudo fs_usage
without any other parameters displays a constant stream of everything happening on the machine - pretty overwhelming!
This includes network operations and disk I/O as well.
The -f
filter option accepts the following values:
-
network
- network-related events, such asaccept
,recfrom
andsendto
. These do not appear very readable, just presenting information likerecvfrom F=13 B=0x2fc
. -
filesys
filesystem events are also very low-level:fcntl
,stat64
,pread
etc - but some of them do at least include the full path to the file being accessed. -
pathname
events are things likestat64
,open
,close
,readlink
- these all include the path and appear to be less verbose thanfilesys
- I thinkpathname
is the most useful filter. -
exec
events show when processes are started and stopped. I haven't played with these enough to see them working yet. -
diskio
events show disk I/O operations and are even more low-level thanfilesys
. -
cachehit
appears to show ALL of the above information, with the addition ofCACHE_HIT
rows.
So for most of my purposes it looks like sudo fs_usage -f pathname PID
is the most useful command.
See also these TILs
Related
- macos Using lsof on macOS - 2021-12-11
- macos Seeing files opened by a process using opensnoop - 2022-04-26
- linux Basic strace to see what a process is doing - 2020-09-07
- macos Browse files (including SQLite databases) on your iPhone with ifuse - 2022-09-13
- python CLI tools hidden in the Python standard library - 2023-06-28
- macos Finding the largest SQLite files on a Mac - 2020-08-19
- macos Accessing 1Password items from the terminal - 2024-07-09
- git Rewriting a repo to contain the history of just specific files - 2022-03-22
- github Finding uses of an API with the new GitHub Code Search - 2022-12-08
- macos Fixing "compinit: insecure directories" error - 2020-04-26
Created 2023-06-15T08:18:09+01:00, updated 2023-06-15T10:53:26+01:00 · History · Edit