ick, you should never -9 a process unless it's absolutely necessary.
why not -HUP or -PIPE the process and let qpopper handle moving the
tempdrop back to the spool??
-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
[EMAIL PROTECTED] Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.org http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Thu, 21 Dec 2000, Ricky Crow wrote:
> I've found that you not only have to kill off the linkering process that
> is running (ps -auxww | grep pop then search for the PID, and kill -9
> that process), then what I do is just do a "cat .username.pop > username"
> in the /var/spool/mail directory... Then I just rm the .username.pop
> file. Hope that helps....
>
> Ricky
>
>
> On Thu, 21 Dec 2000, Brian Curtis wrote:
>
> > A response to the last thread "need help" reminded me of a question I've
> > been meaning to ask...
> >
> > Is there a quick remedy to fixing a users mailbox when their connection is
> > terminated abnormally resulting in a lingering .username.pop lockfile?
> >
> > Right now I just tell them to wait a short while, and the mailbox will
> > unlock itself. However, I'm waiting for the user that says "I need my mail
> > immediately!".
> >
> > I've tried copying the .pop file back to the normal mail spool file and
> > deleting the lockfile, but that produced some strange results.
> >
> > More specifically, I needed to check email from a remote location over a
> > dialup to find that someone sent an unwanted 5mb attachment. I terminated
> > the remote connection, copied the .pop lockfile back to the spool file,
> > deleted the lockfile, used an mua server-side to delete the email w/
> > attachment, then used my remote mua to check mail again just to find it was
> > downloading the same email w/ attachment that I thought I had removed.
> >
> > Checking the mail spool directory again, I saw that the .pop lockfile was
> > recreated with the original filesize of the mail spool before removing the
> > attachment, even though the current spool file was considerably smaller in
> > size.
> >
> > Did I miss a step, did I go about this the wrong way, or should I have never
> > even tried this in the first place?
> >
> > Running Qpopper 3.1.2 via inetd on a RHL 6.1 box.
> >
> > Thanks,
> >
> > --
> > Brian Curtis
> >
> >
>
>
