At 7:58 AM +0100 3/19/01, Oliver Fleischmann wrote:
> > > I did strace on a hanging qpopper-process in an very early
> state (still
>> > running as user root, so the user has not authenticated yet):
>> >
>> > read(0, 0xbfffd68c, 1) = ? ERESTARTSYS (To be
>> restarted)
>> > - --- SIGHUP (Hangup) ---
>> > rt_sigaction(SIGHUP, {0x80505a0, [], SA_RESTART|0x4000000},
>> {0x80505a0, [],
>> > SA_RESTART|0x4000000}, 8) = 0
>> > rt_sigaction(SIGPIPE, {0x80505a0, [], SA_RESTART|0x4000000},
>> {0x80505a0, [],
>> > SA_RESTART|0x4000000}, 8) = 0
>> > sigreturn() = ? (mask now [ALRM])
>> > read(0, 0xbfffd68c, 1) = ? ERESTARTSYS (To be
>> restarted)
>> > - --- SIGHUP (Hangup) ---
>> > rt_sigaction(SIGHUP, {0x80505a0, [], SA_RESTART|0x4000000},
>> {0x80505a0, [],
>> > SA_RESTART|0x4000000}, 8) = 0
>> > rt_sigaction(SIGPIPE, {0x80505a0, [], SA_RESTART|0x4000000},
>> {0x80505a0, [],
>> > SA_RESTART|0x4000000}, 8) = 0
>> > sigreturn() = ? (mask now [ALRM])
>> > read(0, 0xbfffd68c, 1) = ? ERESTARTSYS (To be
>> restarted)
>> > - --- SIGTERM (Terminated) ---
>> >
>> > If I just do strace on the process, it sits in "read(0, "
>> forever. I then
>> > did a "kill -HUP" for two times an finally a "kill" on the process while
>> > running strace.
>>
>> I am confused. Are you running Qpopper in standalone mode? If not,
>> a HUP should cause it to clean up and go away. Also, if Qpopper is
>> waiting on user input then an strace(1) will of course show it
>> waiting on a 'read(0'. It should stay there until input arrives or
>> the timer expires.
>
> We are running qpopper via inetd. The HUP obviously does not make it
> clean up. That process was at least a day old or so, I don't remember
> the exact time. I'm sure there is no user connected any more, so there
> will never arrive any input. If I don't kill the process, it will
> stay forever!
>
> The fact is, these strange hangs occur not only after the user has
> logged in with user/pass, but sometimes (even more often) also before
> the user is authenticated and the spool file is locked.
>
>> > Processes hanging in a later state show the same strace output,
>> as far as I
>> > remember.
>>
>> What I'd like to see is the strace(1) for a process that has reported
>> the error and yet not gone away.
>
> As soon as it happens again, I will send the information.
>
> To make it clearer, the IN-USE error message is not created by the
> hanging qpopper, but by another qpopper if the users tries to fetch mail
> the next time.
Yes, but I thought the original pop session ended with Qpopper
reporting a POP EOF or similar error.
