syslogd offers some potential for logging certain system events - the things
that could/should be logged outside of any application logging that might
have been added by a developer. Unfortunately syslog’s documentation is
thin and finding out which QNX utilities and system processes make use of
syslog is quite difficult.
logger has added to a number of scripts so that start/stop info can be
traced. dumper is run so that crash info is available if this type of event
occurs. My concern is for the events that might occur in between the above
extremes. An example of the in betweeners might be ‘Domain Errors’ that can
occur during math processing. Or some abnormal termination that doesn’t
trigger a dump.
Does anyone have a list of or know which QNX utilities and processes have
been built to make use of syslogd? Is syslog’ing as implemented in QNX4
viewed as being useful or not?
Gord
“Gord Sipko” <gsipko@nxtenergy.com> wrote in message
news:fjc4bi$b8q$1@inn.qnx.com…
syslogd offers some potential for logging certain system events - the
things that could/should be logged outside of any application logging that
might have been added by a developer. Unfortunately syslog’s
documentation is thin and finding out which QNX utilities and system
processes make use of syslog is quite difficult.
logger has added to a number of scripts so that start/stop info can be
traced. dumper is run so that crash info is available if this type of
event occurs. My concern is for the events that might occur in between
the above extremes. An example of the in betweeners might be ‘Domain
Errors’ that can occur during math processing. Or some abnormal
termination that doesn’t trigger a dump.
Does anyone have a list of or know which QNX utilities and processes have
been built to make use of syslogd? Is syslog’ing as implemented in QNX4
viewed as being useful or not?
To my knowledge it’s only used by the TCP/IP.
QNX4 application usually make use of the kernel trace buffer ( traceinfo )
Things like “domain error” are usually never logged, no more then when a
command like sin runs out of memory.
Gord
To my knowledge it’s only used by the TCP/IP.
QNX4 application usually make use of the kernel trace buffer ( traceinfo )
Things like “domain error” are usually never logged, no more then when a
command like sin runs out of memory.
Thanks Mario!
It looks like the tracelogger series of utilities is better suited to
providing the info I am looking for, as the system managers generate trace
events as part of their operation. Configuring traceinfo to provide useable
data will be the challenge…
Gord
“Gord Sipko” <gsipko@nxtenergy.com> wrote in message
news:fjch6o$jgs$1@inn.qnx.com…
To my knowledge it’s only used by the TCP/IP.
QNX4 application usually make use of the kernel trace buffer (
traceinfo )
Things like “domain error” are usually never logged, no more then when a
command like sin runs out of memory.
Thanks Mario!
It looks like the tracelogger series of utilities is better suited to
providing the info I am looking for, as the system managers generate trace
events as part of their operation. Configuring traceinfo to provide
useable data will be the challenge…
Why?
Gord
Why?
It’s not quite as complicated as I originally thought!
In my initial testing there were a large number of trace entries that were
not being translated and I thought I would have to do the work to sort it
out. Turns out including -e /etc/config/traceinfo.net solved the problem.
Overall it looks like tracelogger will be useful and my testing continues.
There are a few strange things… Severity 2 tx timeout messages from
Net/82557 are spewing out at the rate of 15-20/sec on an idle connection
(crossover cable between two machines and ping works both ways). There are
a large number of identical millisec timestamps appearing in groups of 5
consecutive trace entries. Tweaking Net.ether82557’s -t option might help
here, although why this error is occurring is a bit of a mystery.
I’m seeing overrun entries on tracelogger startup. Do you have any
suggestions for the sizing of Proc’s buffer?
Gord