strace, skim the last 4-5 pages of trace output before the error message is emitted, looking in particular for error return values (it's often not right before the error because the program has started to clean up). Figures out the problem 80% of the time within a couple of minutes.
Another common syscall related issue strace helps is with permissions denied. Most scripts just defend against the file existing and not whether the operation is possible, leading to obscure messages like operation not permitted. Strace to the rescue in such cases
It is one oft first lines of debugging, even if I have the source code, as sometimes the syscall that fails is buried deep in library code, but with the failed syscall and arguments I can track the line that made the wrong call.
In a nutshell, this is why I hate working in go. While I'm sure your code, dear hn golang fan, doesn't suffer from this, much of the go code I've had to deal with extends the principle of “unaware of many common failure modes and swallow them into the exit code” to every function.
1) what are exceptions in many languages are plain errors in Go 2) a defer-recover block is usually put at the very top of a risky call
This covers 99% of sources of panics.
Now, the one that truly does mess you up is when it comes from CGO/calling out to C. That will tear your application and there is nothing you can do about it.
If you bubble up errors a lot then errors.Is/As is made for that purpose.
You really only care about a stack trace with a panic.
In anycase, runtime.Stack() iirc should return the stack.
But this sounds more like trying to write other languages in Go rather than writing in Go.
To me, any code calling a `DoesFileExist(filename)` type of function is a code smell.
There is no point to checking if the file exists. None. Ever![1]
There is never a case where this is useful. The only times I see code that checks for the existence of a file is when, on subsequent lines, the file is used as if it exists (no error-checking on open), which is a bug.
A line in code that checks for the existence of a file correlates, in my experience, very strongly with using that particular file in that specific buggy manner.
[1] You might say that it's to provide a better user experience, such as "Your config file does not exist, do you want to create it?" or similar, but that's still buggy if you're determining whether the file exists by checking existence.
> There is never a case where this is useful.
Only a Sith deals in absolutes. What about the use case when you change behavior when a sentinel file exists and don't care about the contents? ;) e.g. touch firstrun
It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but...
Also, what about if you want to not overwrite existing output if it exists? O_CREAT|O_EXCL could be better (and important to use if the overwrite check has security implications)... though that doesn't exist in fopen(3) and you'd need to use fdopen which is inconvenient and risky in its own ways.
Point taken :-)
> What about the use case when you change behavior when a sentinel file exists and don't care about the contents?
You'll still care that you can write that file, right?
> It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but...
But, after you've checked the prerequisites, and you start your main work, you're still going to have to handle the case in that main work that one of the files you checked has the wrong permissions/is locked/was deleted.
It's not unusual for users to accidentally open a program twice by misclicking it when they only opened it once.
> It can also be useful if there's a whole bunch of prerequisites you're going to check before doing a bunch of work; yes, opening the descriptor and keeping it around might be nicer, but...
You answered this question below for the `open`/`openat` syscall. For `fopen` ...
> though that doesn't exist in fopen(3)
It has been in the standard since C11, I believe - mode `"x"` for exclusive create and open. You can use it with most C implementations today as most systems support C11.
Sometimes you don't need it.
systemd itself just checks that `/etc/initrd-release` exists and runs in initrd mode changing its default target to boot into (IIRC you can also manually change the default target to `initrd.target` in the initrd, but this way the default systemd vendored files don't need to be touched).
https://github.com/systemd/systemd/blob/7f13af72f89452950226...
Just ... open the file and handle the error?
What are you getting by checking that the file exists that you don't get from the 'file not found' error that the `openFile()` routine returns?
Because it doesn't matter if `doesFileExist()` returns true, you still have to handle the `file not found` error[1] when calling `openFile()` on the next line anyway.
[1] Just because the file exists when the program checked, that doesn't mean that the program can open it (permissions), that the file still exists (could have been removed between the call to check and the call to open), that the file is, in fact, a file that can be opened (and not a directory, for example), that the file is not exclusively locked (Windows) by some other process that opened it, etc. `doesFileExist()` tells you nothing that would change how the subsequent is written.
I guess we’re accustomed to thinking that absence of a file is not “exception-worthy” because it is expected under normal circumstances. But the cases you raised make sense.
You're still going to have to open it and handle the errors (in case it's the wrong permissions, or the filename is a directory, etc).
Checking if it exists doesn't make the subsequent code any easier or shorter - you still have to check for errors even if it exists.
some unix practices seems very inefficient
Until I opened a 2nd terminal window and did 'while [ 1 ]; do sudo strace -p $(pidof su); done' - that looped until I tried the login again, then attached, followed the calls and showed the delay was due to elogind and dbus; a quick 'apt purge elogind' then fixed the slow login.
Alternatively "-e trace=%file" to get all file-related system calls (will catch eg failing pre-emptive checks using access(3) -> stat(2)).
$ strace -e trace=open cat /dev/null
+++ exited with 0 +++
$ strace -e trace=openat cat /dev/null
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/null", O_RDONLY) = 3
+++ exited with 0 +++[1] I've been dipping my toes into BPF recently, and while complicated (best to simply clone the bpftools repo and work off of that) there's a lot that can be done that tools like strace won't be able to match.
A sprinkling of grep/perl (awk/sed/ruby/...) is mostly good enough eg:
strace -e trace=%file cat /etc/passwd 2>&1 >/dev/null | grep ^open | grep -Po '(?<=").*(?=")'
If so, what format do you expect for the output?
If it's one filename-per-line then how do you encode filenames with embedded newlines?
How do you encode non-UTF8 characters, or is the file meant to be parsed only in binary mode?
I don't know of any generally agreed upon spec for this, so no matter what you think is right, most people are going to have to write a special-purpose parser.
In which case you might as well parse the native strace output since one is about as complex as the other.
I still don't see it as common use case.
In a similar way, -k is useful to get tracebacks.
I wrote that experience up last week, for what it's worth: https://imrannazar.com/articles/linux-upgrade-fail