As already pointed out in #10998, I would prefer to just disable logging again. We are running strongswan in debugging mode just because we found it runs more stable so.

I think we should maybe have a switch where debug logging can be enabled. But even that is in my view rather unnecessary.

I would like to hear Arne's opinion on this.

Well, I hate to disagree, but the load on the machine seems minimal and I never would have figured out the relay collision bug that sparked this discussion if it weren't for the additional info in the logs. 

It sure is nice to have the information available, and if there isn't a major cost to having it, what's the harm?

Any updates here? I know you guys are super-busy with Core 106 and everything else, but it really is impossible to 'tail -f' the kernel log looking for non-ipsec information. Using grep is OK, but only if you know what you're looking for.

Is this bug still valid?

I think so. As it stands now, trying to find anything in the kernel log that isn't logged by charon is near-impossible on any machine running Strongswan. Obviously, the problem gets far worse if you have multiple tunnels up, as the rekeying, DPD, etc spams everything up.

Perhaps this will sum it up better than anything else:

[root@ipfire ~]# grep charon /var/log/messages | wc -l
464399
[root@ipfire ~]# grep -v charon /var/log/messages | wc -l
139472

Basically, one of two things ought to be done (or perhaps both?).

1.) Reduce Strongswan log verbosity.
2.) Move Strongswan log to /var/log/ipsec (or similar).

I prefer option #2, as it does not preclude implementing option #1 at a later date and it provides one simple place to find any log messages related to charon. At the same time, finding entries for dhcp, etc will be that much simpler.

I agree that strongswan writes a lot of information to the logs (DPD, ...).

Reducing the verbosity is not an option for me, since in case you need to debug one connection you cannot change the loglevel on the fly.

So I assume it is better to move the stuff to a separate logfile completely.

FWIW, I spent a small amount of time messing about with this, and I think that this seems to be a good configuration for getting the IPSec log data out of the kernel log. I modified the "filelog" section of /etc/strongswan.d/charon-logging.conf" to be as follows:

        # <name> may be the full path to the log file if it only contains
        # characters permitted in section names. Is ignored if path is
        # specified.
        <ipsec> {

            # Loglevel for a specific subsystem.
            <subsystem> = <default>

            # If this option is enabled log entries are appended to the existing
            # file.
            append = yes

            # Default loglevel.
            default = 1

            # Enabling this option disables block buffering and enables line
            # buffering.
            flush_line = yes

            # Prefix each log entry with the connection name and a unique
            # numerical identifier for each IKE_SA.
            ike_name = no

            # Optional path to the log file. Overrides the section name. Must be
            # used if the path contains characters that aren't allowed in
            # section names.
            path = /var/log/ipsec

            # Adds the milliseconds within the current second after the
            # timestamp (separated by a dot, so time_format should end with %S
            # or %T).
            # time_add_ms = no

            # Prefix each log entry with a timestamp. The option accepts a
            # format string as passed to strftime(3).
            time_format =%b %e %T
         }

This puts information in /var/log/ipsec, and I presume that we would need to modify the line in /etc/logrotate.conf that reads "/var/log/messages /var/log/bootlog /var/log/dhcpcd.log {" to read "/var/log/messages /var/log/bootlog /var/log/dhcpcd.log /var/log/ipsec {"

Am I missing anything else?

Is this bug still valid. It seems that you can get just the charon logs by using the Logs - System Logs - IPSec options in the WUI.

I would argue that it is. The issue isn’t being able to find the Charon entries. The difficulty lies in trying to find anything else. Charon is so verbose that it ends up being very much like the Monty Python “Spam” sketch, where the singers belting out “Spammity Spam, wonderful Spam!” drown out everything else.

It would be nice to be able to feel the kernel log without having to try and block out all of the Charon noise.

You can also review the kernel logs on their own with out any charon inputs.

For the system side of the kernel you can look at the WUI Logs - System Logs - Kernel option.

For the firewall logs you go to the WUI Logs - Firewall Logs.

In both cases if the the amount that is shown on the screen is insufficient then you can export the output and you get a test list which you can do simple searches on in the browser or you can copy and past the export output into an editor or excel to do a more detailed searching on.

I periodically use the Firewall Logs exported output to search for any DROP_HOSTILE outgoing messages.

So you can get just the kernel logs without charon entries with the existing structure.

Certainly, but it’s still a PITA in the console, for example when using ‘tail -f’ while troubleshooting something. Once you have multiple tunnels, it becomes comical how much mess you’re working to ignore. 

I’m also struggling to figure out what the downside is to moving these messages to their own file.

(In reply to Tom Rymes from comment #11)
> Certainly, but it’s still a PITA in the console, for example when using
> ‘tail -f’ while troubleshooting something. Once you have multiple tunnels,
> it becomes comical how much mess you’re working to ignore. 

I am saying don't use the console, use the WUI, export the file which only has the kernel logs in it, into an editor and you can search and filter for the messages that you want.

> 
> I’m also struggling to figure out what the downside is to moving these
> messages to their own file.

The code for strongswan will need to be modified somewhere to change the log location, then there will need to be a change to the log rotate as the modified log location will need to be added to it and then the code for the System Logs as it will need to filter out from a different location.
Those locations needing changes are the ones that immediately come to mind. Not sure if there might be other locations such as the collect and rrd programs for the graphs etc that would need to also be altered.

Someone would have to do the above work and it just seems a bit pointless to me when you can do what you want with the existing WUI without going to the console.