Abdullah Ibn Hamad wrote:
>
> What is the differene between -qqay -l 24h and -ay -l
> 24h ?
-qq suppresses stdout and stderr. Which can also be achieved by redirecting
stdout/stderr to /dev/null in the shell.
--
Paul Steven
--- Paul J Stevens <[EMAIL PROTECTED]> wrote:
> Checking that critical processes really are running
> is a general
> problem. I use snmpd combined with nagios but ymmv.
>
> > I have /usr/local/sbin/dbmail-util -cturpd
> > -l 24h -qq in my crontab at 3AM ...
>
> Mmm. The -r switch has been deprec
Thanx Paul !
Its done ... I think that was the tmpdir of mysql ... I change it
location ..
Paul J Stevens wrote:
Next time you see this: Before you restart lmtpd, don't mess with your
crime-scene: first find out what's eating your disk.
du -Sxm /var | sort -nr | head -20
should give you an
Next time you see this: Before you restart lmtpd, don't mess with your
crime-scene: first find out what's eating your disk.
du -Sxm /var | sort -nr | head -20
should give you an indication.
Alan Glait wrote:
> mmm strange thing
> Again ... I have 99% ... I /usr/local/etc/rc.d/dbmail-lmtpd.
mmm strange thing
Again ... I have 99% ... I /usr/local/etc/rc.d/dbmail-lmtpd.sh restart
and it goes to 13%
I saw pid 69622 (mysqld), uid 88 inumber 17015 on /var: filesystem full
in dmesg ... so ... mysql is writing to /var ... but why ... ? ?
thanx for any help
Paul J Stevens wrote:
Alan Glait wrote:
> I was checking my server ... so I saw /var at 92%
> I restart dbmail-lmtpd ... and it free to 20% ...
Since a lmtpd process doesn't use any diskspace to speak of, I'm
guessing here: lmtpd was down, so your mailq was getting rather big.
Starting up lmtpd allowed your mta
I was checking my server ... so I saw /var at 92%
I restart dbmail-lmtpd ... and it free to 20% ...
How I can to prevent this ?? I have /usr/local/sbin/dbmail-util -cturpd
-l 24h -qq in my crontab at 3AM ...
thanx for any help !
