On 24.06.2016 14:08, Hartmaier Alexander wrote: >> We also thought about further improvements for unexpectedly closed >> connections so that they can be logged and handled more easily. However, >> this is the first step before doing further changes.
> We still get the 'Could not get peer name on TacacsplusConnection > socket: Transport endpoint is not connected' log message without > additional infos for which endpoint. Please don't add an additional > debugging message but improve the existing one! The error getpeername() sees is just that: the connection has gone away (while it was just established) so there's not much to improve this message anymore. The additional message I mentioned is available at trace 4 and it can stay because it's logged at the moment when the remote IP and port are first and surely available. However, maybe you could see what it shows on trace 4 now. The further changes in logging are planned to make unexpectedly closed connections logged so that are, for example, logged at INFO or WARNING level (trace 3 or 2). This should keep the log littering down, successfully opened connections are now logged unless debugging is enabled, while unexpectedly closed and unsuccessfully established connections are logged at higher log level. Maybe you could use trace 4 now to see where the shortlived client connections come from? Thanks for your comments, Heikki -- Heikki Vatiainen h...@open.com.au _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
