from_busybox_maillist at dexdyne.com
Fri Jan 21 16:19:00 UTC 2011
Very interesting. Thank you.
I have been given a suite of co-operating processes to work on, which
live on an embedded device.
We have not implemented a remote debugger. So all I have is printf.
The processes themselves have almost zero "I've done this and so I'm
going to do that" debug printfs built in. I think th guy who wrote them
was a genius and his code just worked
and/or was an idiot who made no allowance for later or lesser mortals
and/or inserted printfs and removed them when he'd got it going.
I'm trying to learn about Linux, and what tools exist, and do useful
enhancement and maintenance at the same time.
For instance he clearly got OpenVPN going without having any idea HOW the
original writers intended it to work.
He killed and completely reloaded the exe every time the comms config
changed. Don't think he'd ever heard of sigusr.
It worked... but if you mis-use stuff you will eventually fall in a hole.
Plus the target is for a 5-year up-time down a dirt-track in Peru. Or/And
to work on dodgy mains which comes and goes twice a day. So I'm having to
fret about stuff which people on attended systems can brush under their
Thanks anyway - I will consider your wise words if I ever get to start
In article <4D3853E9.2060905 at gmx.de>, ralda at gmx.de (Harald Becker) wrote:
> *From:* Harald Becker <ralda at gmx.de>
> *To:* from_busybox_maillist at dexdyne.com
> *CC:* busybox at busybox.net
> *Date:* Thu, 20 Jan 2011 16:25:29 +0100
> Hallo David!
> > 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
> which means normal applications (most probably applications that are
> normally started by root for system maintenance). Another facility
> DAEMON, used by long lived daemon processes. See syslog(3) manual
> 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
> > messages.
> Applications that do not set an explicit tagname do automatically
> there executable or process name as TAGNAME (which is the more
> usage). The logger command allows explicit specification of that
> else all messages would been log with the same process name. That
> why shell script often use "$0" as TAGNAME, which is the shell
> name (treated as application name). So you do not need to set an
> explicit TAGNAME in own C applications, just use syslogd("Your
> string") and that message string gets logged via syslogd. If you
> 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
> by log time).
> > It will take me forever to go and ...
> Ok that is the general problem of wrong software design. There are
> 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
> had any experience with Unix systems ... click-click-windows ...
> the software manager and know how computers work" in there brain ...
> sorry, got a bit frustating, to push the wheel that way over and
> again ... [sick]
> > system( ls -l logdirectory )
> Ok, those output is definitely not for logging via syslogd. Usual
> software do collect output of that type (including massive printf
> output) in separate files, using time-stamp like file naming
> 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
> response message in syslog (could give the reference to the output
> name) ... that would be more Unix style. The bad is to create
> overwhelmed long lived processes doing so many different things,
> massive data output is required for monitoring/debugging.
> The Unix style is to create small and simple programs doing only
> work, but doing it in a pretty good/fast/easy way. Those simple
> 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
> what you are going to achieve (the big goal).
More information about the busybox