Chris Hanlon wrote:
>On Friday I accidently deleted the /var/qmail directory (well actually my
>package manager did(I didn't realise qmail was taged for remove)). I
>restored qmail from a backup cd (several months old) and found out that
>long file nams were lost. I went to the qmail src directory and types
>make setup check. Anyway qmail-send is now using over 90% (60% system,
>30% user) of the cpu (on a celeron 366) even when there is nothing in the
>queue. Before Fridays incedent it used under 1% of the cpu. Any ideas?
qmail structures the queue by inode number. When the inodes and filenames
no longer match up as qmail expects, things can get silly. There are
restoration tools available at www.qmail.org - these enable you to rebuild a
queue after moving it, restoring it, or making other intrusive
modifications.
Another thing to check is that your trigger file is still intact. qmail
uses a named pipe as its trigger, if the pipe is lost, qmail-send will
refuse to run, and supervise will try restarting it. If your backup
software doesn't understand how to store or recover pipes, you'll need to
create it manually. If you find that the trigger is gone or has been
transformed into an improper type (it should be a named pipe, which ls will
show as p), use mknod to recreate it (possibly after removing the broken
file). In your queue directory, type "mknod trigger p", and use chown and
chmod to set its ownership and mode appropriately (UID qmails, GID qmail,
and mode 644).
Mark
--
Do not reply directly to this e-mail address
--
Mark Mentovai
UNIX Engineer
Gillette Global Network
