20.02.2014 15:33, Nicolas Sebrecht пишет:
The 20/02/14, Yuri K. Shatroff wrote:

(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. You can
check also with the journal, as I showed up.

I believe it would be a 5-minutes job to add the capability of printing
last N log entries for a service to `rc-service status`. Using cat, grep

If I understand you correctly, what you're proposing is an analyzing
tool which works after-the-facts.

I wasn't proposing anything. I was just supposing.

I mean extracting the per-daemon logs
from a global log archive whereas systemd works the opposite way, AFAIU.

What is a 'global log archive'? Do you mean a single file where all logs go? AFAIK you can set up syslog to log all messages into one file as well as per-service files. So the deal is just to extract configuration from syslog. Of course, if the services are using it, not keeping their own logs as is usually the case of apache. As a multiuser (multi-vhost) webserver admin I have to set up apache to log into users' home directories, so I even don't know how many user logs there really are. And I don't need to, because I've got my own global log. But a user is definitely more familiar with a text file he/she can download via FTP, than with a journalctl wrapper which he has to know how to use (and also be granted SSH access to use), at the least which parameters to specify, if at all usable in such setups.

You solution requires per-daemon extraction rules and have to be
maintained over time. So, postponed to errors.

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.

--
Regards,
Yuri K. Shatroff

Reply via email to