[tahoe-lafs-trac-stream] [tahoe-lafs] #1936: the tahoe-lafs logging system is hard to discover

[tahoe-lafs]

#1936: the tahoe-lafs logging system is hard to discover
------------------------------+--------------------------------------------
     Reporter:  zooko         |      Owner:
         Type:  defect        |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-         |    Version:  1.9.2
  nodeadmin                   |   Keywords:  usability transparency logging
   Resolution:                |
Launchpad Bug:                |
------------------------------+--------------------------------------------

Comment (by warner):

 Let's see, {{{~/.tahoe/logs}}} contains two things:

 * {{{twistd.log}}}, which has top-level crashes that happen after
 daemonization (like "address already in use"), and other unhandled
 exceptions
 * {{{incidents/}}}, which are foolscap "flog" bundles, created when
 something weird happens

 In addition, there's stuff written to stderr during {{{tahoe start}}}, if
 it happens before daemonization. There's also runtime logging accessible
 with {{{flogtool tail NODEDIR/private/logport.furl}}}.

 We have a couple tickets about moving errors from post-daemonization to
 pre- , where they're immediately visible to the person running {{{tahoe
 start}}} or {{{tahoe run}}} (in contrast, post-daemonization errors are
 pretty hard to discover). I think we've managed to move most configuration
 errors to the pre-daemonization phase (by doing all our checking in
 {{{Client.__init__}}}), but address-already-in-use might be a significant
 exception.

 What if we had the node write out a {{{~/.tahoe/logs/README}}} each time
 it started, with a few lines about what each logfile was for, and how to
 run {{{flogtool tail}}} ?

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1936#comment:3>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage