8.3 - 9.1 issues syslog-ng "fatal illegal instruction"

M

m4cr05

Not sure if this one is a bug, had a stack of issues on 9.1 with syslog-ng, so rolled back to 8.3, on a T1 105.

Issue is as follows. Fresh install.
# portsnap fetch extract update
# pkg_add -r syslog-ng

syslog-ng installed (dump of the install is below). Configured and started, it then drops the following error message. Any thoughts?

Code: 
mon01# /usr/local/etc/rc.d/syslog-ng start
Starting syslog_ng.
__sparc_utrap: fatal illegal instruction
__sparc_utrap: fatal illegal instruction
Twenty seconds later, syslog-ng is a dead process.

Code: 
--------------------------------- Install Process -------------------
pkg_add -r syslog-ng
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/Latest/syslog-ng.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/openssl-1.0.1_4.tbz[/URL]... Done.

Copy /usr/local/openssl/openssl.cnf.sample to /usr/local/openssl/openssl.cnf
and edit it to fit your needs.

Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/perl-5.14.2_2.tbz[/URL]... Done.
Removing stale symlinks from /usr/bin...
    Skipping /usr/bin/perl
    Skipping /usr/bin/perl5
Done.
Creating various symlinks in /usr/bin...
    Symlinking /usr/local/bin/perl5.14.2 to /usr/bin/perl
    Symlinking /usr/local/bin/perl5.14.2 to /usr/bin/perl5
Done.
Cleaning up /etc/make.conf... Done.
Spamming /etc/make.conf... Done.
Cleaning up /etc/manpath.config... Done.
Spamming /etc/manpath.config... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/pkgconf-0.8.5.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/eventlog-0.2.12.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/pcre-8.31.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/libiconv-1.14.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/gettext-0.18.1.1.tbz[/URL]... Done.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/python27-2.7.3_3.tbz[/URL]... Done.
====
Note that some of the standard modules are provided as separate
ports since they require extra dependencies:
bsddb           databases/py-bsddb
gdbm            databases/py-gdbm
sqlite3         databases/py-sqlite3
tkinter         x11-toolkits/py-tkinter
Install them as needed.
====
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/glib-2.28.8_4.tbz[/URL]... Done.
No schema files found: doing nothing.
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/gamin-0.1.10_4.tbz[/URL]... Done.
===============================================================================
Gamin will only provide realtime notification of changes for at most n files,
where n is the minimum value between (kern.maxfiles * 0.7) and
(kern.maxfilesperproc - 200). Beyond that limit, files will be polled.
If you often open several large folders with Nautilus, you might want to
increase the kern.maxfiles tunable (you do not need to set
kern.maxfilesperproc, since it is computed at boot time from kern.maxfiles).
For a typical desktop, add the following line to /boot/loader.conf, then
reboot the system:
    kern.maxfiles="25000"
The behavior of gamin can be controlled via the various gaminrc files.
See [URL]http://www.gnome.org/~veillard/gamin/config.html[/URL] on how to create
these files.  In particular, if you find gam_server is taking up too much
CPU time polling for changes, something like the following may help
in one of the gaminrc files:
# reduce polling frequency to once per 10 seconds
# for UFS file systems in order to lower CPU load
fsset ufs poll 10
===============================================================================
Fetching [URL]ftp://ftp.freebsd.org/pub/FreeBSD/ports/sparc64/packages-8-stable/All/gio-fam-backend-2.28.8_1.tbz[/URL]... Done.

syslog-ng is now installed!  To replace FreeBSD's standard syslogd
(/usr/sbin/syslogd), complete these steps:
1. Create a configuration file named /usr/local/etc/syslog-ng.conf
   (a sample named syslog-ng.conf.sample has been included in
   /usr/local/etc). Note that this is a change in 2.0.2
   version, previous ones put the config file in
   /usr/local/etc/syslog-ng/syslog-ng.conf, so if this is an update
   move that file in the right place
2. Configure syslog-ng to start automatically by adding the following
   to /etc/rc.conf:
        syslog_ng_enable="YES"
3. Prevent the standard FreeBSD syslogd from starting automatically by
   adding a line to the end of your /etc/rc.conf file that reads:
        syslogd_enable="NO"
4. Shut down the standard FreeBSD syslogd:
     kill `cat /var/run/syslog.pid`
5. Start syslog-ng:
     /usr/local/etc/rc.d/syslog-ng start
 
I fear this is a Sparc specific bug because I have syslog-ng running perfectly on several 9.1 AMD64 systems.
 
Agreed - And

I was just wondering if there are any other "slightly deranged ?" individuals out there who love to bring old - reliable - kit back into service, just because .. they run .. and run .. and run .. with no hassle for years on end.

I will dig into debugging this (not sure how.. and have to start somewhere :) falling back on standard syslog is too easy. Got a funny feeling it's down to the Sparc IIi chip, time to break out the Blade 100, 220r, 450, V880 and 4500 to see if I get consistent failures across the board.
 
Also try building the port instead of using the package. Maybe compiling it specifically for your machine helps.
 
m4cr05 said:
I was just wondering if there are any other "slightly deranged ?" individuals out there who love to bring old - reliable - kit back into service, just because .. they run .. and run .. and run .. with no hassle for years on end.

I will dig into debugging this (not sure how.. and have to start somewhere :) falling back on standard syslog is too easy. Got a funny feeling it's down to the Sparc IIi chip, time to break out the Blade 100, 220r, 450, V880 and 4500 to see if I get consistent failures across the board.
Click to expand...

I am also slightly deranged. Marius Strobl is the one to talk to on the mailing lists. Join the FreeBSD SPARC64 list and post your question. @SirDice has a good suggestion.
 
Last edited by a moderator:
Not sure if it helps point towards a solution, but syslog_ng works fine with OpenBSD Sparc64 on my Sun Blade 100. So perhaps recompiling the port is a good suggestion in order to see if that solves the problem.
 
You must log in or register to reply here.
Back
Top