log to file

[jaredjennings]

You can't redirect the output of darbrrb, because then it runs dar, but dar (even if you don't tell it to use encryption and ask for a passphrase) expects that it's going to be running on a terminal, so when it has a problem and tells you to press Enter or Esc, it will have a place to get those keystrokes from. I think this is an opportunity for improvement for dar - particularly having read that libdar expects to read gnupg key passphrases from the terminal, rather than having some callback like the rest of the world - but in any case, darbrrb needs to write its log messages to a file. It doesn't actually even need to be optional. The only tricky thing is multiple darbrrb processes will be writing to the file... hmm.

[jaredjennings]

So the top darbrrb could open a UNIX socket or named pipe or something, passing it through dar via the command lines in the darrc, which sub-darbrrbs would communicate with. Actually the sub-darbrrbs wouldn't have to do any work, they could just signal the main darbrrb to do the work.

All this complicates darbrrb; the question is really whether it's better to have the complication be explicit in the code, or implicit in the tree of processes. Is this one issue of log writing (which I'm not sure exists), plus the issue of knowing what the original argv was, plus whatever might happen down the line, worth adding IPC? It's not perhaps as much complexity as a restart file... hmm

[jaredjennings]

03b7194 logs to a file. The only problem is, it logs to a file without an absolute name. So the top darbrrb, the one that runs dar, writes to darbrrb.log in the working directory at the time it was started; but the subordinate darbrrbs, the ones run by dar, have the scratch directory as their working directory, so they make their own darbrrb.log.

This is because the scratch directory can't be depended on to exist before the ensure_scratch_dir method is called, but that method also ensures a bunch of stuff inside the scratch directory, and so it should only happen once, in the super-darbrrb...

[jaredjennings]

I split the ensure_scratch_dir into two methods, called the first one at startup time, and made all the logs go into a file in it. As I suspected would happen, subprocesses log into that file just fine, but log messages from the parent process after a subprocess is gone don't seem to end up in the file.

I think the simplest way to go from here is to spawn a thread with a queue handler, ... oh, wait, the subprocesses aren't directly started by the parent process....

[jaredjennings]

I did a little étude with named fifos. Besides being UNIX-only, they can't be written to with buffered I/O, and unbuffered I/O has to happen with bytes, and the logging.StreamHandler calls the write method with strings. It got longer and longer, but not better.

[jaredjennings]

I'm going to just append the pid of each process to the name of the log file, and end up with thousands of short little log files in the scratch directory, which can be pieced together into a history by sorting them on access time. This is not preferable, but there are other things I want to fix first and this will work. f15099d, and I'll leave this issue open.