sebix's questions

I have a Postgresql 9.1+134wheezy4 running on Debian 7 Wheezy. From 2015-02-07 on (I guess it has been backported then, see below) I regularly see the following line in /var/log/postgresql/postgresql-9.1-main.log:

2015-02-07 11:08:33 CET LOG:  using stale statistics instead of current ones because stats collector is not responding

I shows a up few times a day, nothing spectacular or to worry about. But I don't get the meaning of the line and couldn't find documentation about it. It is mentioned in the changelogs for 9.3.6 and 9.4.1:

• Change "pgstat wait timeout" warning message to be LOG level, and rephrase it to be more understandable (Tom Lane)

  This message was originally thought to be essentially a can't-happen case, but it occurs often enough on our slower buildfarm members to be a nuisance. Reduce it to LOG level, and expend a bit more effort on the wording: it now reads "using stale statistics instead of current ones because stats collector is not responding".

Unfortunately, it does not explain the meaning. I also had WARNING: pgstat wait timeout until it changed in February as often as the new message. The information on the log line are also not helpful/constructive. A frequent advice is to restart the server or to remove the shared memory segment.

These are the logs for a postgresql restart:

2015-05-25 17:01:39 CEST LOG:  using stale statistics instead of current ones because stats collector is not responding
2015-05-25 18:00:04 CEST LOG:  received fast shutdown request
2015-05-25 18:00:04 CEST LOG:  aborting any active transactions
2015-05-25 18:00:04 CEST LOG:  autovacuum launcher shutting down
2015-05-25 18:00:04 CEST LOG:  shutting down
2015-05-25 18:00:04 CEST LOG:  database system is shut down
2015-05-25 18:00:06 CEST LOG:  database system was shut down at 2015-05-25 18:00:04 CEST
2015-05-25 18:00:06 CEST LOG:  database system is ready to accept connections
2015-05-25 18:00:06 CEST LOG:  autovacuum launcher started
2015-05-25 18:00:07 CEST LOG:  incomplete startup packet

Could it mean that the statistics collector is somehow broken or misconfigured? What is the reason for this behaviour and how can it be avoided?

How is it possible to disable Secure Client-Initiated Renegotiation in stunnel4? I'm using version stunnel 4.53-1.1ubuntu1 on Ubuntu 14.04 Trusty with OpenSSL 1.0.1f and stunnel 4.53-1.1 on Debian Wheezy with OpenSSL 1.0.1e.

The stunnel docs lists an option for that:

renegotiation = yes | no

support SSL renegotiation

but unfortunately, this leads to the following error:

Line 70: "renegotiation = no": Specified option name is not valid here

But where is this the option valid? I tried it for the single services (which makes no sense anyhow), but it didn't work either. The documentation is not very verbose about this, and I couldn't find any information about this with search engines.

Has anyone a clue, how to get this right?

I used the following minimal configuration:

pid=/stunnel4.pid
debug = 5
output = /var/log/stunnel4/stunnel.log
cert = /etc/ssl/certs/ssl-cert-snakeoil.pem
key = /etc/ssl/private/ssl-cert-snakeoil.key
renegotiation = no
[https]
accept  = 443
connect = localhost:8000

These tests showed, that Renegotiation is supported:

Qualys' ssltest shows:

Secure Client-Initiated Renegotiation: Supported DoS DANGER (more info)

Doing it manually with openssl, also confirms:

$ openssl s_client -connect localhost:443
CONNECTED(00000003)
[...]
---
R
RENEGOTIATING
depth=0 CN = mint.home
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = mint.home
verify return:1

I tried to search to Internet for a definition of a FQDN. Wikipedia says, a FQDN

specifies its exact location in the tree hierarchy of the Domain Name System (DNS) I would interpret this, that it's unambiguously resolvable (in DNS).

The example at WP (tough I don't want to use this as reference) states the use of hostname.example.com.

The RFCs I found (RFC 1035 was the only not-protocol-specific I found) were not informative on what does a FQDN qualify.

I thought that only an identifier like hostname.example.com is a valid FQDN (including all hostname, domain and TLD in separate), but this seems to be wrong.
Is it needed that a FQDN should always include a hostname beside the domain, even if the domain consists of only one host? Or is the only definition that a FQDN should be resolvable via DNS? E.g. the domain .tk is unambiguously resolvable, is this a FQDN?