One of the returning questions I get at conferences in the US is if and how syslog-ng works on MacOS. Thanks to Yash Mathne, who worked on syslog-ng as a Google Summer of Code (GSoC) student this year, we have a much more precise answer now. To sum it up: Almost all features work, but syslog-ng cannot collect local log messages natively and misses two drivers (the SQL and SMTP destinations) due to dependency problems.
What does it mean to you? You can run syslog-ng as a server on MacOS with minimal limitations. You cannot store logs to SQL databases or send alerts through e-mail. These limitations are due to dependency problems: the libraries needed by syslog-ng fail to compile on MacOS. Luckily, based on discussions with users, these affect only a small percentage of users. However, all users are affected by the lack of native MacOS log collection capabilities in syslog-ng. Of course, there are workarounds, but you cannot fully replace syslogd with syslog-ng.
Installing syslog-ng on MacOS
Currently there are no easy-to-install syslog-ng binaries available for MacOS. You have to compile and install it from sources. Luckily, you do not have to compile dependencies yourself. You can use the Homebrew package manager for MacOS to install necessary dependencies.
The original syslog-ng MacOS installation guide is available at https://github.com/balabit/syslog-ng-gitbook/blob/master/chapters/chapter_0/section_3.md Yash made an updated version available at https://yash6866.gitbook.io/syslog-macos-testing/installation which has some additional information on openssl (syslog-ng does not compile yet with version 3.0). There is also a third guide, which is probably not up-to-date in every aspect, as it was written almost a year ago. However, this guide also describes how to start syslog-ng automatically using a job definition: https://medium.com/macoclock/how-to-install-syslog-ng-on-macos-965127f1c05c
All of the above guides describe how to do a minimal syslog-ng installation. If you want additional features, you need to install the dependencies from Homebrew and enable the feature with the related configure argument. If configure fails, you might need to pass additional parameters to get it working, similar to how bison and openssl are configured.
-
In the second half of the blog Yash explains how you can collect local log messages and provides you with some details about the dependency problems.
Taking right over from Peter, I will dive deep into collecting local log messages on macOS. While it's easy to get confused with the swiss army knife nature of syslog-ng, it's a logging daemon at its core. Thus, collecting system log messages is fundamental to its functioning.
If you've tried installing syslog-ng on macOS, you know you will run into the following error:
system(): Error detecting platform, unable to define the system() source. Please send your system information to the developers!; sysname='Darwin'
The reason is that system() source is not designed for macOS. At least not for now. So a quick fix to get things working is, of course, removing the system() source from the config file. However, this leaves you with no way to get the system logs. So let's talk about that.
An oversimplification of what the system() source does internally is that it reads the files where the given operating system stores the logs. Unfortunately, the mapping for the same does not exist for the macOS operating system, resulting in the aforementioned error.
On macOS, log files are stored in multiple locations.
-
"~Library/Logs" is your current Mac user account's user-specific application log folder.
-
"/Library/Logs" is the system-wide application log folder.
-
"/var/log/syslog.log" generally contains logs for low-level system services and kernel logs. (These are the log files one is primarily concerned with)
Given that the expected behaviour of system() source is to display system and kernel logs, we sought to achieve this using a file() source driver. To do so, one can simply replace the system() source with:
file("/var/log/system.log" follow-freq(1));
While reading this regular text file (/var/log/system.log) can be a good workaround for macOS, but the original intention with system() source is to replace the given system's syslog implementation and receive messages directly, or in case that's not possible (for example with systemd-journal), just read system logs in a native manner.
In this specific case, /var/log/system.log is a filtered textual output of Apple's syslogd and not obtained through native methods. MacOS uses its own structured/binary logging mechanism called ASL, which is a replacement for the standard syslog() interface on other operating systems. ASL provides a slew of read/query/search methods as well.
Work on this front isn't being done as this will soon be deprecated in favour of a higher level OSlog facility. At the same time, a pull request with /var/log/system.log is currently under review and will be supported till an OSLog-based driver is written if the team determines theirs to be a seamless upgrade path from using /var/log/system.log to OSLog.
If someone is interested in taking up this issue, please feel free to contact us on our socials provided below!
Other Issues
While most of the syslog-ng drivers work without a hunch on macOS, we do run into a few issues with some drivers due to dependency problems. Two such drivers identified amongst the drivers tested on macOS are the SMTP and SQL drivers.
SQL Destination Driver
This driver has multilevel dependencies. To compile, the driver needs the libdbi package, which is supported and updated on macOS.
However, to use any specific database system, you need the corresponding supporting system-specific packages as well. For instance, using mySQL requies the libdbi-dbd-mysql package. These database system-specific packages, unfortunately, are not supported on the latest version of macOS.
SMTP Destination Drivers
This driver has a dependency on the libesmtp driver. However, this driver does not compile on the latest version of macOS.
-
These issues, however, are due to the issues with the compatibility of the underlying dependencies not being updated for the major changes that macOS has gone through in recent years and we are confident that even these drivers will work seamlessly once the dependencies are updated for the same.