Date: Thu, 3 Apr 2014 16:35:44 +0100 From: RW <rwmaillists@googlemail.com> To: ports@freebsd.org Subject: Re: Spamd Message-ID: <20140403163544.54a30abb@gumby.homeunix.com> In-Reply-To: <533D750B.2030209@infracaninophile.co.uk> References: <533D1366.7030607@webrz.net> <20140403110103.0b51d9fc@laptop.minsk.domain> <533D5AA9.4000904@webrz.net> <533D750B.2030209@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 03 Apr 2014 15:49:47 +0100 Matthew Seaman wrote: > On 04/03/14 13:57, Jos Chrispijn wrote: > > Sergey V. Dyatko: > >> use `sockstat -l4 -p783` instead. It show you what user-command-pid > >> listen that port > > > > I killed process 1402 and started Spamd. That did the trick, thanks! > > > > I am very curious: > > > > a. why Perl occupied that port. > > Tried to retrieve this information from logfiles in /var/log but no > > success. May that be an inward traffic issue on port 783 that > > triggered Perl and kept it occupied for Spamd? > > > > b. Is it unsafe or possible to let spamd use another port if 783 is > > occupied. May that be a security risk? > > Assuming 'spamd' here is part of spamassassin then it is a daemon > written in perl, and the command name will show up as perl in sockstat > listings. > > In my experience, it is quite common for this daemon to end up running > under a different PID than the one recorded under /var/run -- so the > system initialization scripts 'sa-spamd' think it isn't running, and > then you get the fight over access to port 783 the OP saw. Killing > the processes using port 783 and restarting spamd should work. > > The situation is complicated by the /other/ spamd -- which is an > OpenBSD thing which works via pf to implement greylisting, teergrube > and various other anti-spam things. Meaning the SpamAssassin > 'sa-spamd' startup script can't simply kill anything called spamd. Support for pid files is built into rcng and used a combination of pid and name, sa-spamd uses this and correctly passes the expected pid file path to spamd. In my experience it does normally work, unless spamd is started as an unprivileged user via the spamd_user variable in rc.conf, rather dropping privileges - that's not happening here because the existing process used port 783.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140403163544.54a30abb>