Bug 148563

Summary: poll25 in /etc/init.d/sendmail returns "failed" but sendmail starts and poll25 takes more than 2 seconds
Product: [openSUSE] SUSE Linux 10.1 Reporter: Seth Chaiklin <seth>
Component: OtherAssignee: Reinhard Max <max>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Minor    
Priority: P5 - None CC: werner
Version: Beta 3   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Seth Chaiklin 2006-02-06 22:36:44 UTC
rpm -q sendmail
sendmail-8.13.5-4

from beta3 found /pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/i586

/etc/init.d/sendmail start returns "failed" but sendmail has actually started.

If "poll25" is commented out in /etc/init.d/sendmail then "done" is
returned.

According the comment for poll25, it should take 2 seconds.
In fact, it takes much longer.
Comment 1 Dr. Werner Fink 2006-02-07 15:06:41 UTC
Never seen such a slow system.  How long this takes on your system?
Btw: there have to be more than one sendmail process: the master for
port 25 with root privileges and the client running as non-root process
for local mail handling.
Comment 2 Dr. Werner Fink 2006-02-07 16:50:43 UTC
I'm using now 10 seconds, if this is not enough then please reopen.
Comment 3 Seth Chaiklin 2006-02-07 22:07:57 UTC
Werner:  Maybe I did not explain clearly enough.  I will provide
some more information about the times and the system.  

First, in all cases, all the expected sendmail processes are started

 7329 ?        Ss     0:00 sendmail: accepting connections
 7745 ?        Ss     0:00 sendmail: Queue control
 7748 ?        S      0:00 sendmail: running queue: /var/spool/clientmqueue

Second, to make things work well, I first commented out "poll25" in /etc/init.d/sendmail

Note that sendmail starts quickly and reports "done"

time sudo /etc/init.d/sendmail start
Initializing SMTP port (sendmail)                                     done

real    0m0.214s
user    0m0.012s
sys     0m0.040s

Third, the problems I want to report are when I put back poll25 in, as it normally should be.
Mote that it reports "failed" and takes 25s to start.

time sudo /etc/init.d/sendmail start
Initializing SMTP port (sendmail)                                     failed

real    0m25.752s
user    0m3.064s
sys     0m15.733s

I do not think this can be explained by the hardware. Also, I had sendmail installed from beta2 and did not have these problems.

(hardware information)

model name      : AMD Athlon(tm) XP 2600+
stepping        : 0
cpu MHz         : 2090.760
MemTotal:       711364 kB
SwapTotal:      393552 kB
SwapFree:       393532 kB

I would be happy to test your new version if you want.

I will leave the bug closed and let you decide what to do.


Comment 4 Seth Chaiklin 2006-02-07 23:45:06 UTC
I just upgraded to the beta4 kernel (2.6.16_rc2-3) as opposed to the beta3 kernel (2.6.16_rc1-git3).  This helped with a problem with apache and a port, but it did not help with poll 25.  Here is another timing.  (Again, the sendmail daemons are started -- but it takes a long time, and the init script reports "failed")  

time sudo /etc/init.d/sendmail start
Initializing SMTP port (sendmail)                                     failed

real    0m23.752s
user    0m2.928s
sys     0m15.749s

I think I will reopen the bug for now.
Comment 5 Dr. Werner Fink 2006-02-08 10:07:06 UTC
The problem is: I can not verify this and as long this is not
possible I'm not able to debug this.
Comment 6 Dr. Werner Fink 2006-02-08 10:24:59 UTC
The problem is: I can not verify this and as long this is not
possible I'm not able to debug this.  Therefore I need your
help.  Please use the poll25() shell funtion within a normal
interactive shell and try to call

           set -x
           poll25

with a running sendmail and also without a running sendmail.
I'd like to see where the problem occurs and why 2 seconds
are expanded to more the 20 seconds.
Comment 7 Dr. Werner Fink 2006-02-08 10:29:34 UTC
Args ... it seems that fuser has a problem with the exit
status in the case of using the option -s for silent operation:

       fatou:/suse/werner # fuser -n tcp 25 && echo true
       25/tcp:               4259
       true
       fatou:/suse/werner # fuser -sn tcp 25 && echo true
       fatou:/suse/werner # 
Comment 8 Dr. Werner Fink 2006-02-08 10:49:23 UTC
Thanks Reinhard, he has a fix for fuser.
Comment 9 Reinhard Max 2006-02-08 11:01:58 UTC
In silent mode, fuser ignored any matches and always returned with 1.

Fixed package submitted.
Comment 10 Seth Chaiklin 2006-02-11 16:09:52 UTC
Just a confirmation that I have tried the new package and everything works again as normal.