Zygo Blaxell wrote:

I have exim configured in daemon mode and I use xinetd instead of inetd.

The last two security updates left me with no running exim daemon and
nothing listening in port 25.  The latest one was nice enough to create
an /etc/inetd.conf that was empty except for this line:

smtp stream tcp nowait mail /usr/sbin/exim exim -bs


That is expected behaviour.

The postinst runs update-inetd to install in inetd.conf if it isn't there already. It can't tell that you've deliberately deleted it, so helpfully creates one for you.

The startup script for the daemon only runs it if it isn't running from inetd, in order that you don't get both trying to run. I suppose I could check that inetd is running, though that would only work if exim starts before inetd (which by default it will, but I wouldn't want to rely on that always being the case, especially since there's no obvious reason why it should matter).

Had you left an inetd.conf file with a commented-out exim entry, all would be well.

Having said that the behaviour is expected, that doesn't mean that it's nice. Partly this is due to what I would consider to be flaws in the design of update-inetd, partly due to an inevitable result of using inetd, and probably also partly my fault. I wish I had never supported using inetd, but it's a bit late to change that now.

The exim package is nearing the end of its life (it will remain in the next debian release, but will no longer be the default mailer, as exim4 will replace it), This means that a) I'm not inclined to put a lot of effort into changes to the package, and b) I don't want to do anything that increases the risks of upgrade. So I don't want to force people to run as a daemon or any other major change like that. However, I am open to suggestions for minor changes that will make things easier for users like this, which is why I've copied this to debian-devel.

One I am considering is only running "update-inetd --add" on a new install, and just "update-inetd --enable" on an upgade. I think this should solve this particular problem; what do people think of it?

The other common problem, which it wouldn't solve, is people who think that using update-inetd to disable something is a good idea - update-inetd should only be used by maintainer scripts, but this isn't made clear enough to users. So they disable something using it, and then are surprised when it comes back on an upgade.

[Debian-devel: note that this is also copied to the bug report. Leave this in or take it out of your replies as appropriate. Please leave me in anyway as I don't normally read debian-devel. Oh, and thanks in advance for your help]





Reply via email to