1 |
20.02.2014 19:24, Alan McKinnon пишет: |
2 |
> On 20/02/2014 13:53, Yuri K. Shatroff wrote: |
3 |
>> I don't need such 'solutions' to non-existent problems. But if there |
4 |
>> were a *real* necessity to pretty-print a log's tail in service status, |
5 |
>> I think it would have been a matter of a proper setup (i.e. the service |
6 |
>> using syslog, hence a defined log format) and not a heck more complicated. |
7 |
>> |
8 |
>>> Definetly not a 5-minutes job. |
9 |
>> |
10 |
>> 5 minutes is even too much to type sort of |
11 |
>> tail -${LINES} ${SERVICE}.log |
12 |
>> if you know where to look up LINES and SERVICE. |
13 |
> |
14 |
> |
15 |
> You've never actually tried this, right? |
16 |
|
17 |
You probably misunderstood. I don't *intend* to try this myself with |
18 |
existing tools, I'm speaking of the init scripts modification. I say |
19 |
that this modification of e.g. OpenRC, if required, would be done quite |
20 |
easily with some assumptions. |
21 |
|
22 |
> Your idea instantly fails as the rc-service author has no idea of what |
23 |
> you defined ${SERVICE} to be and no way to determine what it is now. |
24 |
|
25 |
Yes, the rc-service author does not have any idea because he is not |
26 |
requested to. |
27 |
${SERVICE} obviously comes from `rc-service status ${SERVICE}` . |
28 |
The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by: |
29 |
1. putting LINES= in /etc/conf.d/${SERVICE} |
30 |
2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and |
31 |
doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe |
32 |
'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or *whatever*) |
33 |
3. adding this `tail -n ...` or whatever call to the init script . |
34 |
4. voila. |
35 |
|
36 |
If you feel I'm again entirely wrong please point out why. |
37 |
|
38 |
> How are you going to deal with the situation with a big busy daemon that |
39 |
> immediately starts serving requests when started (i.e. with very little |
40 |
> delay)? |
41 |
|
42 |
Either you or I seem to have misunderstood again. |
43 |
The problem in question IMO was to add the output of last N log entries |
44 |
to `*service status` analogous to systemctl status. |
45 |
When you do tail -n $FILE, don't you *always* get the last N lines of |
46 |
the file at the moment of issuing the cmd, regardless whether the file |
47 |
is being added a million lines per second. I don't think that journalctl |
48 |
can essentially work differently. |
49 |
|
50 |
> By the time grep, sed, awk and friends have gotten around to making |
51 |
> their way through a log file of varying size, the entries that apply to |
52 |
> restart can easy be many hundreds of log lines prior. |
53 |
|
54 |
Why do you refer to restart? |
55 |
|
56 |
Canek wrote: |
57 |
|
58 |
>> systemctl status apache2.service |
59 |
|
60 |
>> (see [2]) will print the status of the Apache web server, and also |
61 |
>> the last lines from the logs. You can control how many lines |
62 |
|
63 |
I don't notice anything about restart here. Just print out the last N lines. |
64 |
|
65 |
If the question were about [re]start logs, and if in general you are |
66 |
getting millions of entries written to the logs, you could use DBMS (not |
67 |
necessarily relational). Maybe this *does* require some mess to setup |
68 |
(we did it back in times of SunOS), but it could be resolved with |
69 |
OpenRC/any SysV/BSD init (at the init-scripts level) if really necessary. |
70 |
Am I wrong? |
71 |
|
72 |
> I have done this, and it does not work. I got a result and it's |
73 |
> relaible, but you don't want to know what it took. It's also highly |
74 |
> customized and useless to anything other than my highly customized setup. |
75 |
|
76 |
Well, if you have to set up one system from scratch then probably it's |
77 |
easier to use one generalized tool. But if you have an already |
78 |
long-working setup which suits your needs, I believe it's relatively |
79 |
easy to deploy it on other systems. |
80 |
I don't like truisms but there is no generic setup suitable for |
81 |
everything. Neither is systemd-journald. |
82 |
|
83 |
-- |
84 |
Regards, |
85 |
Yuri K. Shatroff |