On Wed, 2008-12-24 at 19:20 +0800, Stephen Liu wrote: > --- Yuriy Kuznetsov <yuriy.kuznet...@gmail.com> wrote: > > > Try to run the following on on your box and see what processes are > > listen to > > those ports: > > > > # netstat -lnp > > > > Normally these ports are used by imapd - normal and secure > > connections.
... > # netstat -lnp | grep 993 > tcp6 0 0 :::993 :::* > LISTEN 2846/couriertcpd > > # netstat -lnp | grep 143 > tcp6 0 0 :::143 :::* > LISTEN 2834/couriertcpd > > > Perdition also needs port 993 and 143. They are taken by courier. ... > # /etc/init.d/courier-imap stop > Stopping Courier IMAP server: imapd. ... > # netstat -lnp | grep 993 > tcp6 0 0 :::993 :::* > LISTEN 2846/couriertcpd > > > Why port 993 is still taken by courier? The latter is NOT running. The SSL one is. Try: # /etc/init.d/courier-imapd-ssl stop Now, on a slightly different topic: > # ps aux | grep perdition > root 3114 0.0 2.0 2864 692 pts/2 S+ 11:02 0:00 grep > perdition > > > # kill -9 692 > -bash: kill: (692) - No such process > > > # kill -9 2864 > -bash: kill: (2864) - No such process > > > # kill -9 3114 > -bash: kill: (3114) - No such process It's a good idea to have a think, and know what you're looking at before firing off "kill -9" at random numbers. If you can't remember what column is which (I can't), try something like this: $ ps aux|head -n1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND Your first attempt is at the RSS - Not a pid. There may have been a process with that pid, but you killed it, giving it no chance to clean up after itself. Your second attempt is at the VSZ - again, not a pid. Again, any process that may have had that pid is now gone. Your third attempt is indeed the pid - of the grep command you were using to find it. It's gone already by the time you tried to kill it. Also, please don't cc me on list mail. Richard -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
