Mailing List CGatePro@mail.stalker.com Message #106108
From: Bill Cole <cgp-2015@billmail.scconsult.com>
Subject: TIP: Fixing "cannot stop listener socket" problems
Date: Thu, 07 Jul 2016 11:15:14 -0400
To: CommuniGate Pro Discussions <cgatepro@mail.stalker.com>
X-Mailer: MailMate (1.9.4r5234)
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.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster