Hi Rainer, > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:rsyslog- > > > [EMAIL PROTECTED] On Behalf Of Michael Mansour > > > Sent: Tuesday, August 07, 2007 5:19 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Is rsyslog 1.17.5 RPM MySQL capable? > > > > > > Hi Rainer, > > > > > > > Michael, > > > > > > > > glad you got that far. I think output modularization brought up an > > > > old issue again: Add a semicolon to the end of the db action line. > > > > The MySQL command line parser is pretty old and could need an > > > > upgrade. I've stayed away from that, because it will be replaced > > > > when we do a new config file format. I'd appreciate if you could > > > > try. I'll also try to repro your bug, but I need to finish something > > > > else first. > > > > > > > > So the line should be like > > > > > > > > *.* > > > > >database-server,database-name,database-userid,database-password; > > > > > > > > NOTE THE END OF THE LINE! > > > > > > Yes that was spot on. I added the semicolon for 1.18.0, ran the debug > > > and it > > > went through and (finally) logged entries into the database (1.17.5 > > > would > > > still segfault). > > > > Interesting - I tried to repro, but so far to no avail. Will check > > and fix. > > > > > I then just moved those three binaries in /sbin to .orig and copied > > > across the > > > ones for 1.18.0 into /sbin, then did the "service rsyslog start" and > > > all worked: > > > > > > Aug 8 01:11:37 server rsyslogd: [origin software="rsyslogd" > > > swVersion="1.18.0" x-pid="15789"][x-configInfo udpReception="No" > > > udpPort="514" > > > tcpReception="No" tcpPort="0"] restart > > > Aug 8 01:11:37 server rsyslogd:To enable MySQL logging, a "$ModLoad > > > MySQL" > > > must be done - accepted for the time being, but will fail in future > > > releases. > > > Aug 8 01:11:37 server rsyslog: rsyslogd startup succeeded > > > Aug 8 01:11:37 server rsyslog: rklogd startup succeeded > > > Aug 8 01:11:37 server kernel: rklogd 1.18.0, log source = /proc/kmsg > > > started. > > > > > > where: > > > > > > # rsyslogd -v > > > rsyslogd 1.18.0, compiled with: > > > FEATURE_PTHREADS (dual-threading) > > > FEATURE_REGEXP > > > FEATURE_DB > > > FEATURE_LARGEFILE > > > FEATURE_NETZIP (syslog message compression) > > > SYSLOG_INET (Internet/remote support) > > > > > > See http://www.rsyslog.com for more information. > > > > > > and: > > > > > > # ldd rsyslogd |grep mysql > > > libmysqlclient.so.14 => /usr/lib/mysql/libmysqlclient.so.14 > > > (0x004fb000) > > > > > > and I see the entries getting logged into the SystemEvents table. > > > > > > >From here phpLogCon shows: > > > > > > 5 most recent logs (filter settings apply): > > > > > > No data found! > > > > > > Note: There are 23 events in the database, which are in the future! > > > > I think the "future problem" is probably related to your environment. > > This is most probably the clock skew that make also complained about. > > I worked out why there was the clock skew. Basically I was running > the compile on an nfs mount point, and the server doing the nfs > export was in the future > (I hadn't finished the ntp setup on it). I fixed the ntp setup on > the nfs exported server, and after a few minutes it synced correctly > in time with every other server. > > I also extracted the 1.18.0 tarball into a local filesystem on the server > running rsyslog, and the make went through fine without any clock skew. > > I then moved those newly generated rsyslog files to the /sbin > directory, and started rsyslog and it's logging to the database.
As an update to this, I modified the spec file that was in the 1.17.5 src rpm to just look for the 1.18.0, and built the 1.18.0 binary rpm without an issue. Regards, Michael. > Currently the database has (from phpLogcon): > > 5 most recent logs (filter settings apply): > > No data found! > > Note: There are 2142 events in the database, which are in the future! > > I'm not sure why it still says "in the future", so what I did was > stop rsyslog, truncate the systemevents table, restart rsyslog, and > still got: > > 5 most recent logs (filter settings apply): > > No data found! > > Note: There are 11 events in the database, which are in the future! > > I know you provided me with a link to a forum on this, so I'll try > and take this issue with phpLogCon up there. > > Do you know of any other software I can use which does was phpLogCon > does? so that I can allow user accounts to login and show syslog > events from the web? > > > > ie. there are events in the database which I can't view, but now this > > > may be > > > due to a database change between 1.17.5 and 1.18.0 ?? > > > > No, its unchanged for at least a year. > > Ok, that rules out that problem out then. > > > > It's too late in the morning now so I'll carry on with this tomorrow > > > sometime. > > > But if you have suggestions on what could be wrong with phpLogCon (ie. > > > why I'm > > > not actually viewing the entries even though events do exist) please > > > let me know. > > > > > > > I'd appreciate if you could post the phpLogCon issue (just copy and > > paste) to > > > > http://www.phplogcon.org/PNphpBB2.phtml > > > > I am right now way to disconnected from it - there are other folks > > who can probably help, but they are not necessarily reading this > > list ;) > > I'll do this now. > > > Thanks for your patience and help in getting rsyslog as bug-free as > > possible! > > My pleasure Rainer, your software is also immensely helpful for what > I need to get out of it too, so anything I can do to make it better... > > Michael. > > > Rainer > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > ------- End of Original Message ------- > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog ------- End of Original Message ------- _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
