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?