0

I noticed in the mail log last night that I'm getting a new message:

MAIL (mailed XXX bytes of output but got status 0x0047#012)

The cron job did run successfully though (as it's a script that transmits to a third party API, and they confirmed that they received data), but I'm unable to see the status of the transmission on our end.

I'm thinking it might be related to amount of available disk space, but I have no way to be sure.

Here is the output of df-h

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      9.8G  9.7G     0 100% /
devtmpfs        1.9G   64K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvdb1       48G  6.7G   39G  15% /var/www

For reference, we're using Centos 6.6 on AWS

I tried looking online for the meaning of this message, but I was unable to find it. If anyone could shed some light on it, that would be great, thanks.

EDIT:

The answer marked as a dupe did not help me, as it's not related to my question and the user asking that question got a different error response.

  • What is the cron job? – Craig Watson Sep 29 '15 at 15:16
  • It pulls data from our database and sends it to a third party API. It calls a PHP script to handle that. – hugmungus Sep 29 '15 at 15:20
  • 1
    If the cron is outputting that error, perhaps you should look at the script itself. I doubt anyone here will be able to tell you what is happening inside your own script. – Craig Watson Sep 29 '15 at 15:21
  • 2
    possible duplicate of MAILTO is not working for CRON. How can I fix this? – Craig Watson Sep 29 '15 at 15:26
  • 1
    A simple web search for your error text turned up the above question. – Craig Watson Sep 29 '15 at 15:27
1

Your disk is indeed full, shown by the 100% used stat for /dev/xvda1, I've edited your question to include the output headers for the df command.

You need to clear space on your disk for your logs to continue.

0

So I got a hold of our system admin (we contract out to him, I'm just a dev at my company), and he said this was an issue with updating our AWS server. Basically we log to our /var/httpd folder since we have plenty of space there, but the update caused our pointers to go away. Here are the notes from him to help anyone in the future.

These notes relate to the issue in general, and the apache logs:

After a round of server updates last week, the apache logs were writing to the wrong location. This has been fixed and the logs are now properly writing to the /var/httpd volume again. We have the logs writing to the /var/httpd volume to keep it from suffocating the root volume. The root volume is 10GB and the /var/httpd volume is 50GB.

These notes are specific to the cron issue:

It was probably the root volume space issue. Mail servers write to queues which then send. If the volume was full then it couldn’t write to the queue.

I would still be interested in finding out where I can see a list of the status codes that cron uses, as that was my original question, and I can't seem to find this info. If I find this information out, I will update this answer with that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.