OP
- Thread Starter
- #26
1: To have a file open, you need a process. Let's assume (comments below) that the process that is holding a file open for write is a new process started by the pkg command. So run "ps aux", save the output. Run the pkg command. Run "ps aux" again, and compare the results. This is going to be a bit tedious, as there will be lots of changes; you may want to write a small script to do the compare. Is there a new process, left over from the pkg run?
Did that long ago, there are no such processes. And, as I said at the start, fstat shows no write-open files on /usr.
Strip your X setup down as much as possible, then enable things one at a time.
Oh I went much further. I replaced my .xinitrc contents with "sleep 3600", started X, switched back to ttyv0, and ran my test. Which failed as before. I could only go further by starting X manually, but that would only eliminate xinit and a shell. And both of those would have been doing something like waitpid() when I ran the test so it's unlikely that they're the culprit.
Anyway, I seriously doubt that trying to match open/close pairs will do any good because there are no files open for write when the remount returns "device busy", according to fstat.
My working hypothesis is that when X starts it does something dodgy which lays dormant until "pkg add" does something to make /usr seem busy. It does not have to be a file open for write. I took a look at the remount code and there are a whole bunch of conditions that can give EBUSY. So it would seem that my first order of business is to track down the actual condition.
Is there any reason to think that sticking a bunch of prints into the remount code will cause any problems? That seems like the obvious way to track it down, unless I want to start learning how to use a kernel debugger.