even bigger problems - urgent!

[manarak]

BTW: Did you remove the virusscanner from all .qmail files?

huh?

 

[manarak]

seems the qmail-send process doesn't want to get killed

what's that with the virusscanner and .qmail files?

 

[CoKo]

That was only to see if you're really awake

Sorry, I mixed that one up with another thread I did today - but on the other hand it gives an interesting idea.

BTW: kill -ALRM does not kill anything. It sends an ALRM to the process which wakes it up and should start queue processing.

Before killing the queue there is one final thing we can try:

service xinetd stop
service crond stop
service qmail stop
mv /var/qmail/bin/qmail-queue /root/.
mv /var/qmail/bin/qmail-queue.orig /var/qmail/bin/qmail-queue
service xinetd start
service crond start
service qmail start

With this you replace the original qmail-queue file and avoid all virus- and spam scanners of your system (ok, not all) give it a try.

 

[manarak]

No reaction. Still 239

This means killing the queue?

 

[CoKo]

If you don't see anything in the log file WHY it is not processing the queue - I fear, yes.

But first let us undo the last change:

service xinetd stop
service crond stop
service qmail stop
mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-queue.orig
mv /root/qmail-queue /var/qmail/bin/.
service xinetd start
service crond start
service qmail start

When this is done, here comes the tough part killing the whole queue and re-creating a new one:


/etc/init.d/qmail stop
/etc/init.d/crond stop
/etc/init.d/xinetd stop

# Check for running qmail processes and kill'em all
killall -9 qmail-rspawn
killall -9 qmail-lspawn
killall -9 qmail-send
killall -9 qmail-clean

cd /var/qmail/queue
rm -rf info intd local mess remote todo
mkdir mess
for i in `seq 0 22`; do mkdir mess/$i; done
cp -r mess info
cp -r mess intd
cp -r mess local
cp -r mess remote
cp -r mess todo

chmod -R 750 mess todo
chown -R qmailq:qmail mess todo
chmod -R 700 info intd local remote
chown -R qmailq:qmail intd
chown -R qmails:qmail info local remote

/etc/init.d/xinetd start
/etc/init.d/qmail start
/etc/init.d/crond start

 

[manarak]

what effect will the part after the last change undo have?
will it erase the messages?

 

[manarak]

wait - I still get tons of "wrong owner" messages in the maillog ???
what the...

somehow all the /mess are owned by root, group nofiles??

what is the correct setting for that?

 

[CoKo]

Yes. Immediately and forever. That's why I wrote:

When this is done, here comes the tough part killing the whole queue and re-creating a new one:

I would recommend trying other things - but the queue will run more and more full...

One final thing I would check before killing: Check if the ownership of the files in the queue is correct. Eg. all files below mess shoud be owned by qmailq and files below info or remote by qmails

After that I'm out of options, sorry

 

[CoKo]

wrong owner again?

Then please check the files in the queue as mentioned in my last post - and please give another look on

ls -al /var/qmail/bin

 

[manarak]

somehow all the /mess are owned by root, group nofiles??

 

[manarak]

VICTORY

the /mess files has the wrong owner!

now I would like to know the name and address of the idiot responsible for the update script. Please. I have some russian friends who would love to pay him a visit...



CoKo, you're god-like !

 

[CoKo]

The "funny" thing is: Those problems occure during all updates I made randomly:

7.1.1 => 7.1.5
7.1.5 => 7.5.2
7.5.2 => 7.5.3

And now to 7.5.4 also. Seems their learning curve is really flat

Whatever, you saved your mails and your system is working again - that's all what counts...

 

[manarak]

thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you - thank you

I can't tell it often enough.



ey...
what is all this spam flooding my mailbox...
JUST KIDDING!!!