Bill,
Bill Campbell<[EMAIL PROTECTED]> wrote on 2006-12-13 19:04:
> Is there any easy way to identify the program that's causing
> entries to end up in the %{l_prefix}/var/fsl/fsl.log file?
>
this is really a challenge because fsl doesn't know the application it is
linked into and the application being faked into believing it is using syslog
doesn't know about fsl!
> I'm seeing a bunch of things saying ``refused connect from...'',
> with nothing to identify the program that generated these.
>
Because of the library and the application being unable to help each other, the
developer or packager must tie them together. Hints to track down the logging
application:
find packages that use fsl
$ openpkg rpm -q --whatrequires fsl
unpack the sources and hunt for the messages you see
$ openpkg rpm -Uvh foo.src.rpm
$ cd $PREFIX/RPM/SRC/foo
$ openpkg rpm -bp foo.spec
$ cd $PREFIX/RPM/TMP/foo ...
$ grep -R "refused connect"
if that doesn't help, find executable binaries that have fsl embedded
$ openpkg rpm -ql `openpkg rpm -q --whatrequires fsl` \
| egrep '/([s]bin|libexec)/' \
| xargs what
read "openpkg man fsl" and hunt for "what(1)" to understand the search.
Once the applications are identified, their sources can be reviewed to find
calls to openlog(3). The facility passed there is the key for fsl to redirect
log messages catched from syslog(3). The problem with the syslog API is that
the use of openlog is optional. Apps omitting openlog cannot be used with fsl
and must be patched to call openlog.
Going one step deeper is to rebuild fsl with_fsl_debuglogcode=yes, install it
and rebuild one of the candidate packages with this fsl. Again, read "openpkg
man fsl" and this time hunt for -with-fsl-debug. And yes, you are reading
correct: this debugging stuff uses the contents of a symlink (not the file the
symlink is pointing to) as raw configuration data.
--
Thomas
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
