Hello,

it seems that UW-IMAPD (2004g) crashes inetd. I have the following
entries in my /etc/inetd.conf:

imap stream tcp nowait root /usr/bin/imapd imapd
imaps stream tcp nowait root /usr/bin/imapd imapd

When doing inetd start and stop, it works fine. However, inetd restart
crashed inetd, no connections are being accepted on any
inetd-controlled daemons. Commenting out imap(s) cures the problem.

Any ideas? Is my inetd.conf entry above right?

Thanks
Florian

It is impossible for imapd to crash inetd. Only a system manager, doing
something wrong, can crash inetd. imapd is simply a bystander.

Did you read the man page for inetd on your system?

Did you compare these imap entries with other entries in your
/etc/inetd.conf file to ensure that they follow the same form? There are
variations of inetd, and thus variations of what goes into the
/etc/inetd.conf file!

How did you "restart inetd"?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Hi Mark,

I run Debian 3.1 with the default-shipped inetd (package netkit-inetd,
version 0.10-10). The entries in my inetd.conf read:

ftp stream tcp nowait root /usr/local/sbin/proftpd proftpd
pop3 stream tcp nowait root /usr/local/sbin/popper qpopper -S -f
/etc/qpopper.conf
pop3s stream tcp nowait root /usr/local/sbin/popper qpopper -S -f
/etc/qpopper-ssl.conf
imap stream tcp nowait root /usr/bin/imapd imapd
imaps stream tcp nowait root /usr/bin/imapd imapd

I have found out that when doing inetd restart (via the Debian-supplied
init script), in about 25%, inetd stops accepting connections on all
mentioned daemons. After a inetd restart, it works fine again.

When I remove the last two lines (regarding imap), it works flawlessly.

Florian

Since you say that it works 75% of the time, this suggests that there's
some sort of timing problem.

The best that I can guess is that there is something buggy either in your
copy of inetd or in the init script. The entries look fine, and there
should be no difference between using tab or space to delimit the fields.

The first thing that I suggest is to try restarting inetd manually instead
of using the init script. That way, the init script is removed from
consideration. If everything is faultless, then the problem is in how
that init script works.

To restart inetd manually, determine the process number of inetd, e.g., by
using
ps aux | grep inetd
or by seeing if something writes inetd's PID someplace. Then, become
root and use the command
kill -HUP #####
where ##### is the inetd process number.

In any case, there is nothing that imapd can be do that can cause this
problem. You may have to inquire in some of the Debian forums for more
.

Many people don't understand the role of inetd and/or xinetd. These
programs do the actual TCP listening and starting of the server when a
client connects. The server doesn't even start until that time.

Let me emphasize this; imapd doesn't run at all until inetd starts it.
Those new lines in /etc/inetd.conf simply add rules to inetd to run imapd
for connections on port 143 and 993. Since, when you have the failure,
imapd never starts, it can't do anything to crash inetd.

I assume that you have verified that, when inetd starts with imapd, you
get listening on both the IMAP (port 143) and SSL IMAP (port 993)
services?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Hi Mark,

thanks for the explanations. Yes, of course I know how inetd works, the
curious thing just was that the problems only appeared after I have
added imapd.

I tried manually restarting inetd (killall -HUP inetd), and that seems
to be just fine, so I think the problem really lies in the inetd init
script provided by Debian. I have filed a bug report with the Debian
Bug Tracking System.

Thanks for your !
Florian