Missing pid from log file since ~5.19

Hi, After upgrading to stunnel 5.19 I noticed the log file no long reports the pid of stunnel processes. Instead I find the constant string [0]. Sep 14 12:15:30 hostname stunnel: LOG6[0]: SSL closed (SSL_read) This information is very useful to isolate individual connections. Do later stunnel versions report the pid correctly? I am using fork mode. My syslog is defined as local6.debug and stunnel.conf contains debug=local6.info. Thank you. -- Philippe Anctil

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14.09.2015 18:27, Philippe Anctil wrote:
After upgrading to stunnel 5.19 I noticed the log file no long reports the pid of stunnel processes. Instead I find the constant string [0].
https://www.stunnel.org/static/stunnel.html The option name is logId.
I am using fork mode. My syslog is defined as local6.debug and stunnel.conf contains debug=local6.info.
You are right. The default log id type (sequential) does not work with fork threads. Why do you use fork threads? Just don't do it. Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJV9viqAAoJEC78f/DUFuAUpVAP/iidhNZJqgF5/L7rHm9cLwjq r2Lo+iey92bndM9TrQagX2TQK/YVHaeijUEqKz0HGIMP6I+zd7h2Wv14VZ9UHd0R sQlnyMMNdCRVTE1x1g9p0qxG3AG1c0DZTg4P9b9RDYtdzm94LktR3mygd5Il3m3M iaEOZAcxPHKB0FpYYsT3biBp0pqtWhRnUnfaF+/Ef5HP6KuQnk5pXVZuwcGI0iJ7 YgraxPdLK9Yqg0kBVyXNmqk0chpeenjpSTk+gRE4n4QOgkCo6/H7PXcX1XGl+Uub FB3CQQZNGg+S22Ciru3UnP/mmuQQxyonTl+4yuRTLgwc0KlMIHpPYUMRnAw1TgwN 8qi3WL8xyJ4QV9tTk4lQJbRTfaZwLMVEiZiAwPl79ZJ1KBj8t2FLcbpquMM2K6uV Rj3ArEzu+1JV2P5j2MJqztfIeWdE/rAYuu7xbBjnrqwVrTrcVz2uoKO988tCbKoG +2dfU7BiN7H6I33o4LcqOX7EMPEX2mSNCYrcnULwTvIStNUJgbVJt8FizfrfDp9+ ujNHlLbD++rDrsyIGQdgnVb/tXDLiyucEV5Sn0hSTQ9/lSBNlF4l7//Lsi8x5ZGJ uSFfZq04LWz940y1/1+0mvJgNvSiBRM/ozjIpwQw9R+Z6vauvjYc4Owh8DkLvR8j W3kXBOqh4jnAdVewSQD3 =6vUS -----END PGP SIGNATURE-----

2015-09-14 12:41 GMT-04:00 Michal Trojnara <Michal.Trojnara@mirt.net>:
I am using fork mode. My syslog is defined as local6.debug and stunnel.conf contains debug=local6.info.
You are right. The default log id type (sequential) does not work with fork threads. Why do you use fork threads? Just don't do it.
Quite a while ago we tested the thread mode. We say memory leaks and went with fork for that reason. Thanks very much for the logId bit. logId=thread is exactly what I needed.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15.09.2015 23:08, Philippe Anctil wrote:
I am using fork mode. My syslog is defined as local6.debug and stunnel.conf contains debug=local6.info.
You are right. The default log id type (sequential) does not work with fork threads. Why do you use fork threads? Just don't do it.
Quite a while ago we tested the thread mode. We say memory leaks and went with fork for that reason.
I'll be glad to see the configuration that caused the per-thread memory leak. Are you sure it wasn't simply heap fragmentation? stunnel is way faster with PTHREADS, because SSL/TLS session cache doesn't work in stunnel with FORK threading.
Thanks very much for the logId bit. logId=thread is exactly what I needed.
Great. I have fixed incrementing the sequential thread number in the FORK threading mode. The fix will be included in the next release of stunnel. Thank you for reporting the problem. Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJV+v2WAAoJEC78f/DUFuAUIJsP/0HCxXHOx6AqXgkhSM1j8uKa X7ykCz5ovXL7WbzePqU+7s3HL3Yk+yiAz0muIPh7nRP5TMemgbVIFMTCRKtyAFCF bBlJlLMr3325Cg73VXbXUm37yUedzC9rX9qWaWnKBZtsxLK6EAEZO6M+LwWkRtsx YaPkWrVYKtdgxlDXHAHQZQ+T9EObdXpRHFZ29/zOKERbgctqItqXJdsqQz/4Yqde vb4du+G3lqmbP8kZQKPn8X6nKdISMb0fp245zae4RxUpmVgR/GtaNpS9GAHjLimi BTOSx+ZgLYqPvDyPUqWX/E1MeiADqAkoHBULAdqDyGOJrPg9dUneBPYNd+Kf7Jvx 3VfQg0Ll2R+IRT3tlPNEWnZSnvHVDrnAV4seaMzp+fYUkFbrVQ8fjGdLSpMPdRyd DSUIN7AzuhF5eB5TyVp2blX3wxVk37JmNbWhXTfDe4ggzbY72VzN89LakIRmzdJZ wknqNFzNkEGd/5C16vy1ra2Ky/ftHLLHfVhiDl8t27wLqazoMVa9h/7lHXJuuV4p 96UaY2b1e4y75SNce5zmbFyBFTYK8T8/W9RY5p8QQWDU5RduD81odO4ZmrFA4/7W RAARSlC9bVTx4VJO6mBPde3N/feCng5tw29wHZVULLBD7I+XychKRgT4g6XaNz4j n+VwdqD9ECirlzzrnyUh =8LRi -----END PGP SIGNATURE-----
participants (2)
-
Michal Trojnara
-
Philippe Anctil