Huge disk usage on /var/spool/clientmqueue
Dave
update 4, which has a 19 GB root file system.
bash-3.00$ df -h
Filesystem size used avail capacity Mounted on
/dev/dsk/c1t1d0s0 19G 18G 1.4G 93% /
/devices 0K 0K 0K 0% /devices
etc
This is almost fall so I investigated where all the space was being
used. A crash dump saved me 1.4 GB, but I seem to have tons of files in
/var/spool/clientmqueue
# pwd
/var/spool/clientmqueue
# ls -l
total 12586192
-rw-rw---- 1 smmsp smmsp 796 Oct 21 2007 Qfl9LBk0NV000842
-rw-rw---- 1 smmsp smmsp 1529 Oct 21 2007 dfl9LBk0NV000842
-rw-rw---- 1 smmsp smmsp 126 Apr 24 2008 dfm3OCZIAa007760
-rw-rw---- 1 smmsp smmsp 126 Apr 24 2008 dfm3OCeInk020635
-rw-rw---- 1 smmsp smmsp 126 Apr 24 2008 dfm3OCjIWk003585
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PBtIJx011556
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PC0IWA024271
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PC5JNC007064
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PCAI0F019739
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PCFINH002485
-rw-rw---- 1 smmsp smmsp 126 Apr 25 2008 dfm3PCeI9M004713
-rw-rw---- 1 lp smmsp 175 Apr 29 2008 dfm3T7wIw3010250
-rw-rw---- 1 lp smmsp 175 Apr 29 2008 dfm3T7wKrN010329
-rw-rw---- 1 smmsp smmsp 126 May 3 2008 dfm43MFJVB004889
and more, totalling over 6 GB. Some are pretty old too:
# ls -lt | tail -3
-rw-rw---- 1 smmsp smmsp 126 Apr 24 2008 dfm3OCZIAa007760
-rw-rw---- 1 smmsp smmsp 796 Oct 21 2007 Qfl9LBk0NV000842
-rw-rw---- 1 smmsp smmsp 1529 Oct 21 2007 dfl9LBk0NV000842
Any suggestions on what can, or can not be deleted?
Chris Ridd
All of them. They're probably happening because something (like cron)
has sent mail to the sendmail server on localhost, and that's not
configured to send mail anywhere. So it just builds up...
--
Chris
ThanksButNo
> On 2008-11-30 22:15:11 +0000, Dave <f...@coo.com> said:
>
> > # ls -lt | tail -3
> > -rw-rw---- 1 smmsp smmsp 126 Apr 24 2008 dfm3OCZIAa007760
> > -rw-rw---- 1 smmsp smmsp 796 Oct 21 2007 Qfl9LBk0NV000842
> > -rw-rw---- 1 smmsp smmsp 1529 Oct 21 2007 dfl9LBk0NV000842
>
> > Any suggestions on what can, or can not be deleted?
>
> All of them. They're probably happening because something (like cron)
> has sent mail to the sendmail server on localhost, and that's not
> configured to send mail anywhere. So it just builds up...
> --
> Chris
It's also possible that if your server is acting as a mail server, it
is
being bombarded with undeliverable spam messages. The spambots are
often
poorly configured. Sometimes they hold the connection for
interminable
periods while trying to brute-force guess which user names are
available.
Run "ps -ef | grep sendmail" and see if you have a lot of sendmail
processes running. If you have more running than you expect, you're
probably being hit. Repeatedly.
You might need to install a later version of sendmail that has more
anti-spam features. If the host is a mail server, that's a good idea
in any event. Visit www.sendmail.org to see if there are newer
versions
available.
Even if it's not a mail server, if it's connected to the Internet, and
sendmail is running, it's possible spammers have found it and are
trying
to crack it. If you're not using it as a mail server, consider just
shutting the service off.
Visit comp.mail.sendmail for more advice in this area.
======================= generic sig file ============================
===== Remember this advice is worth every penny you paid for it =====
=====================================================================
Cydrome Leader
uninstall sendmail and install postfix, then your mail will work. The
similar sizes of the messages suggest the messages are from the system
itself, and not spam.
kewlkat...@yahoo.com
> This is almost fall so I investigated where all the space was being
> used. A crash dump saved me 1.4 GB, but I seem to have tons of files in
> /var/spool/clientmqueue
Not really a Solaris question, but a sendmail question. sendmail runs
in two modes. The daemon mode listens on port 25, so it has to run as
root. Root privs are also needed to cause local delivery to users to
occur. In the old days, the sendmail binary would then be setuid
root which meant that local users could run it as root. They would
then have the chance to manipulate their local setup to try to cause a
buffer overflow to occur as root. So now sendmail is setgid smmsp.
When run by root with the -bd (become daemon) it runs as root and
binds to port 25 as needed. However, if a normal user runs sendmail
it runs with the group permissions. This happens, as mentioned
previously, with cron jobs, mail, mailx, pine, etc. Any program that
runs sendmail to send mail does this. The mail messages are then
queued up in clientmqueue, before getting passed over to the daemon
sendmail. If that is failing the messages will accumulate in
clientmqueue as mentioned. If you run "ps -ef | grep sendmail" you
should find that you have two running: /usr/lib/sendmail -bd -q15m
and /usr/lib/sendmail -Ac -q15m. The first is the sendmail daemon,
which also process the daemon queue directory (/var/spool/mqueue)
every 15 minutes. The second is the clientmqueue processor. The -Ac
option says "Act as client" which is how it knows to flush the queue
files. You might look in the qf and Qf files to see why the messages
aren't making it through to the daemon mode, and look at the df files
to see what the original messages were (careful though as some might
be user emails). In any case, you need to fix the problem stopping
mails from being forwarded to the main daemon, unless that error was
some temporary failure and the messages never got processed again.
And you need to see why your client queue runner isn't doing it's
thing. Otherwise, the mails will just build up again.
Craig
Dave
> On 2008-11-30 22:15:11 +0000, Dave <f...@coo.com> said:
>
>> I've got a Blade 2000 workstation (home computer), running solaris 10
>> update 4, which has a 19 GB root file system.
>>
>> bash-3.00$ df -h
>> Filesystem size used avail capacity Mounted on
>> /dev/dsk/c1t1d0s0 19G 18G 1.4G 93% /
>> /devices 0K 0K 0K 0% /devices
>>
>> etc
>>
>>
>>
>> This is almost fall so I investigated where all the space was being
>> used. A crash dump saved me 1.4 GB, but I seem to have tons of files
>> in /var/spool/clientmqueue
>>
>>
>> Any suggestions on what can, or can not be deleted?
>
> All of them. They're probably happening because something (like cron)
> has sent mail to the sendmail server on localhost, and that's not
> configured to send mail anywhere. So it just builds up...
Thank you. I have not configured sendmail, as I have no use for it - or
so I thought anyway. I had disabled the service:
# svcs sendmail
STATE STIME FMRI
disabled Sep_15 svc:/network/smtp:sendmail
Deleting the files in /var/spool/clientmqueue was not quite as easy as I
thought it would be:
# cd /var/spool/clientmqueue
# rm *
/usr/bin/rm: arg list too long
I appear to be having a bit more luck with:
# find . -type f -exec rm {} \;
as it is increasing the amount of free disk space *slowly*.
I guess at 6 GB, with most files being less than 200 bytes in length,
there are around 32 million files in that directory! No wonder rm was
not too happy!
dave
Casper H.S. Dik
>Thank you. I have not configured sendmail, as I have no use for it - or
>so I thought anyway. I had disabled the service:
># svcs sendmail
>STATE STIME FMRI
>disabled Sep_15 svc:/network/smtp:sendmail
You should probably enable it just to make sure that at and cron job
output is delivered. You can configure sendmail such that it doesn't
accept remote SMTP connections.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
John L
"Casper H.S. Dik" <Caspe...@Sun.COM> wrote in message news:493501ed$0$189$e4fe...@news.xs4all.nl...
> Dave <f...@coo.com> writes:
>
> >Thank you. I have not configured sendmail, as I have no use for it - or
> >so I thought anyway. I had disabled the service:
>
> ># svcs sendmail
> >STATE STIME FMRI
> >disabled Sep_15 svc:/network/smtp:sendmail
>
> You should probably enable it just to make sure that at and cron job
> output is delivered. You can configure sendmail such that it doesn't
> accept remote SMTP connections.
>
Yes, and in general this is how sendmail should be configured.
But remember to log in and deal with this mail, otherwise instead
of filling your disks with undelivered mail, you will be filling them with
unread mail which is an improvement (fewer files, fewer inodes
used, and not boosted by undelivered emails to postmaster
complaining that mail cannot be delivered) but only a slight one.
If your Sun is a server which is expected to just sit there and get on
with life without having people logging in every day, then it may be
better if cron and at did not send mail at all. On Solaris this is not
easy to configure but you can at least redirect stdout and stderr to
/dev/null for each command. (Or maybe you could treat root's mailbox
as a log file and rotate it automatically.)
--
John.