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