ralda at gmx.de
Thu Jan 20 15:25:29 UTC 2011
> I had seen the "system log" as something for Linux processes to use -
> not for user apps to add to. Maybe that is a false understanding.
syslog() and syslogd use so called facilities to separate the log
messages (original syslogd can split messages according to those
facilities in different files). One of the defined facilities is USER,
which means normal applications (most probably applications that are
normally started by root for system maintenance). Another facility is
DAEMON, used by long lived daemon processes. See syslog(3) manual page
for a list of all facilities.
> I have inherited a suite of programs, each of which runs as a process,
> which do not have the "tagname" built-into their progress or debug output
Applications that do not set an explicit tagname do automatically use
there executable or process name as TAGNAME (which is the more proper
usage). The logger command allows explicit specification of that name,
else all messages would been log with the same process name. That is,
why shell script often use "$0" as TAGNAME, which is the shell script
name (treated as application name). So you do not need to set an
explicit TAGNAME in own C applications, just use syslogd("Your message
string") and that message string gets logged via syslogd. If you have
several several programs called that way and you want to see all
messages of that programs you can just do an
egrep "TAGNAME1|TAGNAME2|TAGNAME3|..." MESSAGE_FILE_NAME
and you get all messages in the correct program invocation order (sorted
by log time).
> It will take me forever to go and ...
Ok that is the general problem of wrong software design. There are to
many programmers out there, writing software for Unix systems (and
alike) without knowing and understanding the fundamental concepts of and
behind Unix. I hate such software and had to fix (in the past) a lot of
trouble forced by such misbehaved software designs. ... not counting
lost time by discussions with software managers of companies who never
had any experience with Unix systems ... click-click-windows ... "I'm
the software manager and know how computers work" in there brain ...
sorry, got a bit frustating, to push the wheel that way over and over
again ... [sick]
> system( ls -l logdirectory )
Ok, those output is definitely not for logging via syslogd. Usual Unix
software do collect output of that type (including massive printf
output) in separate files, using time-stamp like file naming technics
and a find call afterwards (or may be before) to delete old protocol files.
> That does have the advantage that if a process fails, but I don't notice
> for 24 hours ( these things are in a field in Peru. ) the file for that
> process will contain it's last dying words, they won't have been rotated
> away by it's verbose and still living, cousins.
A true argument. Those things depend on application requirements.
syslog is not for massive data output. Normal long lived daemon
processes under Unix don't do such massive message output. They fork and
run child processes that may redirect there output in separate files per
child invocation, possibly producing a single information/warning/error
response message in syslog (could give the reference to the output file
name) ... that would be more Unix style. The bad is to create
overwhelmed long lived processes doing so many different things, that
massive data output is required for monitoring/debugging.
The Unix style is to create small and simple programs doing only limited
work, but doing it in a pretty good/fast/easy way. Those simple programs
get added together by scripts and other programs to create the
applications needs. ... that is just to point it out ... no indention to
force you in any special direction.
> I think my preference is a valid point of view :-)
Depends on the point you choose for viewing ;-) ... and (not at least)
what you are going to achieve (the big goal).
More information about the busybox