TIP: Fixing "cannot stop listener socket" problems

"Bill Cole" <[email protected]> Thu, 07 Jul 2016 11:15:14 -0400
Newsgroups gmane.mail.cgatepro.general
Message-ID <[email protected]>
So, MAYBE it's just me.... I doubt it. So I'm dropping this here to make 
it findable for others.

I work with multiple CGP instances, mostly on FreeBSD but also 
occasionally MacOS X. Once in a while, when trying to stop CGP for 
upgrades or whatever, it hangs going down with a spew of "cannot stop 
listener socket" messages in the log about one listener or another. Not 
usually a huge problem because most of the time when I'm stopping CGP 
I'm also rebooting the system so eventually the system will 'kill -9' 
the process for me.   Most commonly I've seen this happen with SMTP but 
most recently on a standalone->cluster transformation project it 
happened with PWD after I had fixed it for SMTP, and of course in 
standing up a cluster doing shutdowns is a necessary part of testing so 
this was a showstopper.

It turns out the causes actually differed, unless you consider "multiple 
admins" a common cause.

For SMTP there was an obvious problem: Somehow Sendmail had been enabled 
on the loopback, but CGP thought IT owned 127.0.0.1:25, so it could not 
figure out why that listener didn't actually die. Easy fix: shut down 
and disable the sendmail MTA daemon, just keep the local submission 
queue runner (details vary by OS and version...) This also explains (I 
think) why I've seen this intermittently on MacOS, which historically 
has brought up Postfix temporarily whenever there's locally-submitted 
mail queued for it, complete with a smtpd on lo0.

For PWD the issue was stranger. For reasons no one can explain, there 
were 2 PWD listeners defined: one for "all addresses" without SSL and 
another for 127.0.0.1 with SSL enabled. This made no sense and I don't 
know why CGP failed to complain about it at startup, but removing the 
loopback+SSL listener entirely solved the problem.

There is a commonality that should help in troubleshooting any case of 
CGP being unable to stop a listener at shutdown: a listener that isn't 
what CGP thinks it should be. In both cases, the "cannot stop listener 
socket" messages coincided with CGP trying to make loopback connections 
to the port in question, succeeding to some degree, and disconnecting: 
apparently testing itself?

So in short: if you've got a problem with CGP not shutting down, look 
closely at what port it's trying to talk to itself on and make sure that 
it doesn't have something else listening OR a strange broken listener 
config.

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[email protected]>.
To unsubscribe, E-mail to: <[email protected]>
To switch to the DIGEST mode, E-mail to <[email protected]>
To switch to the INDEX mode, E-mail to <[email protected]>
Send administrative queries to  <[email protected]>