| 1 |
On 20/02/2014 13:53, Yuri K. Shatroff wrote: |
| 2 |
> I don't need such 'solutions' to non-existent problems. But if there |
| 3 |
> were a *real* necessity to pretty-print a log's tail in service status, |
| 4 |
> I think it would have been a matter of a proper setup (i.e. the service |
| 5 |
> using syslog, hence a defined log format) and not a heck more complicated. |
| 6 |
> |
| 7 |
>> Definetly not a 5-minutes job. |
| 8 |
> |
| 9 |
> 5 minutes is even too much to type sort of |
| 10 |
> tail -${LINES} ${SERVICE}.log |
| 11 |
> if you know where to look up LINES and SERVICE. |
| 12 |
|
| 13 |
|
| 14 |
You've never actually tried this, right? |
| 15 |
|
| 16 |
Your idea instantly fails as the rc-service author has no idea of what |
| 17 |
you defined ${SERVICE} to be and no way to determine what it is now. |
| 18 |
|
| 19 |
How are you going to deal with the situation with a big busy daemon that |
| 20 |
immediately starts serving requests when started (i.e. with very little |
| 21 |
delay)? |
| 22 |
|
| 23 |
By the time grep, sed, awk and friends have gotten around to making |
| 24 |
their way through a log file of varying size, the entries that apply to |
| 25 |
restart can easy be many hundreds of log lines prior. |
| 26 |
|
| 27 |
I have done this, and it does not work. I got a result and it's |
| 28 |
relaible, but you don't want to know what it took. It's also highly |
| 29 |
customized and useless to anything other than my highly customized setup. |
| 30 |
|
| 31 |
-- |
| 32 |
Alan McKinnon |
| 33 |
alan.mckinnon@×××××.com |
Archives