Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 2202 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Live Logs empty

davidqdc
I just upgraded to ASL v5 (using the 5.015 ISO) and brought everything to v5.019 via up2date.  I notice that all my Live Logs are empty.  So, I may not view the live packet filter log, nor anything "Live".

Has anyone else seen such behavior?  ASL is successfully logging to my syslog server, at least for the facilities I have chosen.

Any help appreciated.


This thread was automatically locked due to age.
Parents
  • 0
    Upon further review, ASL v5.019 is ONLY logging via remote syslog; nothing is hitting /var/log on the ASL.  I haven't had the opportunity to reboot just yet; I have to wait until this evening.  I HUP'd syslog-ng process.  I restarted MDW.  I don't see anything reflected in the remote syslogs, so am at a bit of a loss.

    I wonder if anyone else has seen something similar?  Basically, after I installed ASL v5.105 and brought it to v5.019 via up2date, everything ran fine.  Logs worked until midnight of the day I installed.
  • 0 in reply to davidqdc
    Hm, strange. Never heard of that case yet. Can you take a look into the /etc/syslog-ng.conf file and search for file destinations? Is local logging still enabled in the webadmin?
Reply Children
  • 0 in reply to andreas
    After a reboot, syslog-ng completely failed to launch due to a parse error in the configuration file.  I believe I found the problem (for the parse error).

    Remote logging requires: remote machine (network definition), service (service definition) and facilities to remotely log.  The service was SYSLOG, which is defined as TCP/UDP port 514.  The offending lines in the configuration file included 'tcpudp' for the remote destination definitions in /etc/syslog-ng.conf.  I global search/replaced 'tcpudp' with 'udp', and syslog-ng would launch.

    So, most everything seems okay now.  I can't disable remote syslog via webadmin, and not all the Live Logs display data, but do seem to be collecting data throughout the day.
  • 0 in reply to davidqdc
    That's a good error description. I'll investigate that tomorrow. Thanks so far!
  • 0 in reply to davidqdc
    OK, I did some investigations. In the WebAdmin, you configure the service which is used for remote syslog. If you select the predefined service "SYSLOG", udp/512 should be configured. To check this, you can take a look into the config file "/etc/logging.conf". There should be a section with "remote_ip", "remote_port", "remote_proto". The values in there get transferred into /etc/syslog-ng.conf by running "syslog-templateparser". The parser reads /etc/logging.conf and creates the syslog config file.

    Please check the files stated above. I can not imagine how something could go wrong with that mechanism, therefore I need you input on that.

    Regards,
    andreas
  • 0 in reply to andreas
    Thanks for the pointer to /etc/logging.conf, as I had not found that before.  Sure enough, there's the culprit:

    remote_port1 = 514
    remote_proto1 = tcpudp

    Before I upgraded to v5.015, I was running v4.021; so, I exported my settings, upgraded, imported the v4 settings.  I know the service definition for SYSLOG under v4.021 was:

    SYSLOG   tcp/udp   514

    It appears the "tcp/udp" imported directly.  Of course, with syslog-ng this is fine, since it supports both TCP and UDP connections; however, I don't believe you may specify them both in one remote configuration line.

    I appreciate your help.  I'm tweaking the /etc/logging.conf to set the remote_proto = udp.
  • 0 in reply to davidqdc
    You can do this via the WebAdmin under System->Remote Syslog. If you cycle the service to another service and back again to syslog, it should be fine. Doing that on the console should work, too :-)
    Thanks for the upgrade from 4.021 hint, I'll forward that to the devs responsible for the V4->V5 importer, most likely the bug can be found here.

    Regards,
    andreas