syslog-ng-ctl config to print pre-processed configuration

[Kokan]

Currently there is no way to tell what configuration syslog-ng has in effect.
Sure the file in the disk can be checked, and most of the time it would be save to assume the active config and the disk content are equal.

This gives an opportunity to both get the content of the top level configuration file and also the preprocessed configuration.

The way it could be queried via syslog-ng-ctl:

> syslog-ng-ctl 
Syntax: /tmp/install/sbin/syslog-ng-ctl <command> [options]
Possible commands are:
    stats                Get syslog-ng statistics in CSV format
...
    config               Print current config

This prints the top level configuration file:

> syslog-ng-ctl config

With an option --preprocess it prints the preprocessed version of the config:

> syslog-ng-ctl config --preprocessed

[bazsi]

This is a good idea, but is it also that it gives you the preprocessed configuration? I would have the assumption that it would return the one that matches the disk file.

OTOH, it is true, that include files wouldn't be part of that, whereas this one contains them.

In that case, I think I would rename the syslog-ng-ctl command to reflect this fact, e.g. syslog-ng-ctl preprocessed-config (which I don't like too much) or running-config (if that's enough to indicate that it might not be equal to disk file) or something else. the key that it should be clear that it is different.

[Kokan]

I was thinking about to make it possible to provide the original configuration and in such case add an additional option to syslog-ng-ctl config for example --preprocessed.

It was a quick patch, I did not want to complicate things. But you have a valid point, this should be cleared now.

Does this alternatives look good to you ?
syslog-ng-ctl config would return with the config without preprocessing.
syslog-ng-ctl config --preprocessed would return with the preprocessed configuration

This syntax would support an option like --verify later on, which could check against the config stored on disk.

[kira-syslogng]

Build SUCCESS

[kira-syslogng]

Build SUCCESS

[furiel]

Optional:
If the goal is just to read the content, you could use g_file_get_contents.
https://developer.gnome.org/glib/stable/glib-File-Utilities.html#g-file-get-contents

Though in the end you need GString, though I would still use a library function to read into cstring, then convert to glib, as it would result in cleaner code, and performance is not important here.

[Kokan]

Thanks, actually I wanted to get such function but my query was not successful, and I did not try that hard.

[furiel]

It would be nice to log the reason here.

[Kokan]

The file is opened again where the reason not able to open a file is logged. I wanted to avoid logging the same thing twice (the two open's result could differ, but I think that has a low chanse, while this failing this open is not critical, while the other is.)

[kira-syslogng]

Build SUCCESS