On Mon, Jan 05, 2015 at 09:21:06PM +0100, Laurent Bercot <ska-supervision_at_skarnet.org> wrote:
> On 05/01/2015 20:12, Caleb Spare wrote:
> >We're really happy with using runit/svlogd generally, but over time
> >we've found the TAI-timestamped filenames that svlogd produces, which
> >aren't human-readable, makes dealing with the logs too difficult.
>
> Can't you run a simple filter like tai64nlocal or s6-tai64nlocal when
> you need to read the logs ? Doesn't it fit your workflow, is it too
> inconvenient ?
>
> (I'm not asking this to be a jerk: I'm genuinely interested in learning
> what is acceptable or not to users. As a programmer, I find the advantages
> of TAI64N stamps obvious and I feel it's a very minor inconvenience to
> have to use a preprocessor when reading logs; but other users have
> different expectations and evaluation criteria, and it helps me to know
> where they're coming from.)
Here are my notes on this issue:
I had to somewhat re-orient the appadmins to use ls with -t switch
and also remind them to use the tools given to them creatively.
The last one (use creatively) didn't echo well in the in-file TAI64N timestamps
case, too much hassle to invoke s6-tai64nlocal. I had to hack the distribution
provided LESSOPEN script so less would show filtered output by default. There
are still unresolved cases, for example tail -f <filewithTAI64Nstamps>.
In general everything which in some way differs to common practices the older
*nix people are accustomed to is frowned upon. I know as I am a living case
myself, for long time I couldn't get used to /package, /command and /service
trees even if I quite clearly understand the technical reasoning. I guess it
could be PITA for bigger teams with lots of churn.
Recent move to systemd is in the same vein, I've already heard some whining
simply because things aren't how they used to be. Change is inconvenient and
people are lazy (me too :).
--
Vallo
Received on Wed Jan 07 2015 - 18:35:31 UTC