TLS distribution: unexpected message: {'EXIT',<0.178.0>,shutdown}

Questions / Help
,
1

Hi everyone,

We had a RabbitMQ user report an interesting log message during shutdown, which can be seen here:

What I find odd is that the {'EXIT',<0.178.0>,shutdown} message didn’t match the case clause here:

Note that Erlang 25.1.2 is being used.

Thanks for any insight, and apologies if I’m missing something obvious!

2 Likes
2

It didn’t match because HandshakePid is already bound in the function argument, but this pid is not the one who is asking the process to shutdown. The process is asked to shutdown by its supervisor, which is not HandshakePid. Also, this process has trap_exit set to true so exits are passed as messages to it.

So, every time the supervisor is shutting down this process, this warning will be generated I guess? I don’t know if this is wanted behavior.

3 Likes
3

Thanks. Someday using a bound variable later on won’t trip me up, but not today! :upside_down_face:

3 Likes
4

I believe it existed since OTP 24, and it is my fault.

This is benign message saying “a new TLS connection has been accepted while the node was shutting down, before handshake succeeded”. Essentially it’s noise (we suppressed it in the logger filter, and that’s why I forgot to follow it up).

IIRC the fix is to replace Reason =/= normal andalso with Reason =/= normal andalso Reason =/= shutdown andalso. I had it somewhere, thanks for a reminder. I’ll fire up a PR to remove the useless message.

In the meantime, you may just ignore the message, or suppress it in the logger handler.

3 Likes
5

Or we get the pin op :slight_smile:

1 Like
6

In that case pin would work against the intent of the diff. If someone asks me “what do you want to change in the base language” and ask “do you want a pinning operator”, I’d say “nope, please, but - please - let’s have a real string() class that’s not a list of characters, but a binary, probably UTF8/16/…”

2 Likes
7

Ahh I see. I didn’t see your reply, and even if I did, I probably still would have read it wrong, tricky little chunk.

But yes, agreed. There was discussion on slack not terribly long ago about migrating to binaries as the default such that "" becomes binary syntax using the new feature pragma. That’s another topic unto itself but yeah.

Thanks for your work in all the patches you submit to OTP :slight_smile:

1 Like
8

Submitted Do not emit "unexpected" message on shutdown by max-au · Pull Request #6810 · erlang/otp · GitHub

While “unexpected message” fix was, as I said before, trivial, looking into child_terminated errors led me into a rabbit hole. Well, it always happened to me. Looks like a 5-years old bug surfaced with the new supervisor goodness, “significant children” feature.

That naming made my wife staring scared at me, “does that mean there are some insignificant children?! What kind of parent are you” and I had no choice but to quite Shrek, “One of a kind”.

3 Likes
9

I’ve been saying this since 1980, when I discovered that
a text editor a friend of mine had written in PL/I and
was selling for $50 a copy could be written in about 1/4
as many pages of C precisely because C didn’t have a
string type and PL/I did :

STRINGS ARE WRONG.

Or as Alan Perlis put it

“The string is a stark data structure
and everywhere it is used there is much
duplication of process.”

What he didn’t say, but could have, is that
much of that duplication of process will be
both slow and buggy.

Strings are perfect for briefly holding onto
text you got from somewhere else and will pass
on like a hot potato having done as little
processing as possible. Otherwise, if you hold
any non-trivial amount of data as strings, you
are doing it wrong.

(By the way, if you like horror stories, read the
Unicode specification. If you really enjoy tales
of the crypt, look into the history of it and the
way they have flip-flipped on core design issues
a couple of times. Even “move forward one thingy
in this string” is a nightmare of “but what does
that actually MEAN?”)

2 Likes