I had a look at the library interaction like:
$ dist=ubuntu; rm libpostfix-tls.so.${dist}.ltrace; cp -v libpostfix-
tls.so.debug${dist} /usr/lib/postfix/libpostfix-tls.so; ltrace -f -s 128
--no-signals --library=libpostfix-tls.so posttls-finger
mx.dmz.tait.net.nz >libpostfix-tls.so.${dist}.ltrace 2>&1
$ rm libpostfix-tls.so.${dist}.ltrace; cp -v libpostfix-
tls.so.debug${dist} /usr/lib/postfix/libpostfix-tls.so; ltrace -f -s 128
--no-signals --library=libpostfix-tls.so posttls-finger
mx.dmz.tait.net.nz >libpostfix-tls.so.${dist}.ltrace 2>&1
I thought I could go in depth onto the function results, but TBH.
In the Ubuntu case it didn't call into the library at all ?!
But only one of them had hits in ltrace at all?!?
I realized that ltrace tried to fool me here.
With --library=libpostfix-tls.so it identifies the symbols in there, and logs
calls to those names.
But it is not guaranteed that they will be redirected elsewhere (man ltrace).
A ltrace call without --library=libpostfix-tls.so does NOT list any library
calls in both cases.
So something is odd here in regard to where this code really comes from.
With -x @libpostfix-tls.so just as without any -l/-e/-x there was no report at
all.
This is interesting as we clearly see the exchange of the library having an
effect.
How would it do so it really would not be called.
Could it be that it only uses the data segment of the library and that
might differ - sounds like a too crazy theory to me ...
Maybe we can squeeze out of GDB where the text segment of e.g.
tls_log_mask really is from while executing?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885403
Title:
posttls-finger fails to connect to private/tlsmgr
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1885403/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
