Hi Jonas, Jonas Smedegaard <d...@jones.dk> writes: > I just noticed that kanla is growing a huge logfile, seemingly > consisting mostly of the following messages endlessly repeated: > > relaying: Hello, this is the "fail" plugin. If you read this message, your > setup seems to be working :-). > > That's not acceptable for a daemon expected to be turned on always. > > At a minimum the daemon should use logrotate, but really such flooding > with "ping" style messages should be avoided, to not shadow actually > useful log messages. Your bugreports reads a bit weird. The expectation here is:
1) If you install kanla, you will start configuring it. If you don’t intend to use it, why install it? Or at least why have it enabled? 2) When first configuring kanla, it is helpful to have a quick way of testing that messages successfully arrive at the destination address, which this default setting provides. 3) After removing the fail plugin from your configuration, you will only see this message when an actual failure is detected. That should be rarely, and in these cases it is more important to have a log message in case something went wrong, than to have a quiet log file. 4) When using systemd (and journald with that), you have logrotation by default (well, in Debian that is no persistent logging at all, and a memory ringbuffer currently). The legacy init support is intentionally quite sparse, because it doesn’t make sense to spend time on re-implementing the wheel in that area in 2013 (well, soon 2014 :)). In conclusion, I am not really sure what to do. From my current POV, this all works as intended, though it obviously surprised you. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org