Error with gunzip during logrotate

Question

I'm using logrotate to rotate my Symfony2 logs on my webserver.
Everything works fine, but I wanted the old logs to be sent to me by emails.
So, I added some line in my logrotate conf file as you can see below

Logrotate config

/var/www/symfony/app/logs/prod.log {
        daily
        missingok
        rotate 5
        compress
        notifempty
        mail myemail@example.com
        su www-data www-data
}

Now I do get emails, but the content is not really what I expected.

Email received

/etc/cron.daily/logrotate:
error: mail command failed for /var/www/symfony/app/logs/prod.log.6.gz
error: uncompress command failed mailing /var/www/symfony/app/logs/prod.log.6.gz
run-parts: /etc/cron.daily/logrotate exited with return code 1

I did many reasearch for this error but I didn't find anything usefull. I've launched an strace in hope to gain some insight on the problem but it didn't work out as expected.

Strace command

strace -f -o ./strace.txt logrotate -d /etc/logrotate.d/symfony2

The generated file is quite big, but I think that the revelant part is the following

Strace output

6842 execve("/usr/bin/mail", ["/usr/bin/mail", "-s", "/var/www/symfony/app/logs/prod."..., "myemail@example.com"], [/* 18 vars /]
6841 <... setgid resumed> ) = 0
6842 <... execve resumed> ) = -1 ENOENT (No such file or directory)
6841 setuid(0) = 0
6841 execve("/bin/gunzip", ["/bin/gunzip"], [/ 18 vars */]
6842 exit_group(1) = ?
6841 <... execve resumed> ) = 0
6842 +++ exited with 1 +++
6841 brk(0
6840 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 6842
6841 <... brk resumed> ) = 0x85f010
6840 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6842, si_uid=0, si_status=1, si_utime=0, si_stime=0} ---
6840 write(2, "error: ", 7
6841 access("/etc/ld.so.nohwcap", F_OK
6840 <... write resumed> ) = 7
6841 <... access resumed> ) = -1 ENOENT (No such file or directory)
6840 write(2, "mail command failed for /var/www"..., 65

As you can see, gunzip command exit with the error code 1 and some very explicit question mark (?) in order to help me better understand what is happening. The only error I'm getting is "No such file or directory" which I find very weird because logrotate is supposed to handle the files rotation before sending emails.

My question, how to solve this problem with gunzip/logrotate in order to receive the rotated log file by email before it gets deleted ?

Here are some information on my server that might be relevant to the problem

root@someServer:/home/someUser# cat /etc/debian_version
8.1
root@someServer:/home/someUser# logrotate --version
logrotate 3.8.7
root@someServer:/home/someUser# gzip --version
gzip 1.6

Also, my logs files are quite small (~300-400 bytes) and If I use gunzip manually it works just fine.

---

Edit - adding logrotate output

Handling 1 logs

rotating pattern: /var/www/symfony/app/logs/prod.log forced from command line (5 rotations)
empty log files are not rotated, old logs mailed to someEmail@example.com
switching euid to 1000 and egid to 33
considering log /var/www/symfony/app/logs/prod.log
    log needs rotating
rotating log /var/www/symfony/app/logs/prod.log, log->rotateCount is 5
dateext suffix '-2016011811'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/www/symfony/app/logs/prod.log.5.gz to /var/www/symfony/app/logs/prod.log.6.gz (rotatecount 5, logstart 1, i 5),
renaming /var/www/symfony/app/logs/prod.log.4.gz to /var/www/symfony/app/logs/prod.log.5.gz (rotatecount 5, logstart 1, i 4),
renaming /var/www/symfony/app/logs/prod.log.3.gz to /var/www/symfony/app/logs/prod.log.4.gz (rotatecount 5, logstart 1, i 3),
renaming /var/www/symfony/app/logs/prod.log.2.gz to /var/www/symfony/app/logs/prod.log.3.gz (rotatecount 5, logstart 1, i 2),
renaming /var/www/symfony/app/logs/prod.log.1.gz to /var/www/symfony/app/logs/prod.log.2.gz (rotatecount 5, logstart 1, i 1),
renaming /var/www/symfony/app/logs/prod.log.0.gz to /var/www/symfony/app/logs/prod.log.1.gz (rotatecount 5, logstart 1, i 0),
old log /var/www/symfony/app/logs/prod.log.0.gz does not exist
renaming /var/www/symfony/app/logs/prod.log to /var/www/symfony/app/logs/prod.log.1
compressing log with: /bin/gzip
switching uid to 1000 and gid to 33
switching uid to 1000 and gid to 33
switching euid to 0 and egid to 0
error: mail command failed for /var/www/symfony/app/logs/prod.log.6.gz
error: uncompress command failed mailing /var/www/symfony/app/logs/prod.log.6.gz
switching euid to 0 and egid to 0

Full strace below :

 strace -vf -s 128 -e verbose=all -o ./strace.txt logrotate -d /etc/logrotate.d/symfony2

http://pastebin.com/C0uj0419

Answer 1

According to your strace, your problem isn't actually gzip.

Here is why gzip fails.

14972 write(1, "<Here is the content of my prod.log file>"..., 32768) = -1 EPIPE (Broken pipe)

The process is writing to stdout, the actual output of this however is the input to the mail command. If we check this:

14973 execve("/usr/bin/mail", ["/usr/bin/mail", "-s", "/var/www/symfony/app/logs/prod.log", "someUser@example.com"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41"..., "SUDO_USER=none", "SUDO_UID=1000", "USERNAME=root", "MAIL=/var/mail/root", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "PWD=/home/none", "LANG=en_GB.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/bash", "HOME=/root", "LANGUAGE=en_GB:en", "LOGNAME=root", "SUDO_GID=1000", "_=/usr/bin/strace"] <unfinished ...>
14973 <... execve resumed> )            = -1 ENOENT (No such file or directory)

When you try to execute the mail command, it fails because /usr/bin/mail doesn't exist. The program exits, the stdout of gzip returns SIGPIPE as the other end of the pipe has disappeared. Thus gzip exits with a 1.

What you need to do is install a mail command. Thats probably either bsd-mailx on debianesque systems or mailx on Redhat based ones.

Answer 2

Use a prerotate or postrotate script to send the logs yourself. This gives you the flexibility to send the logs as a compressed attachment if you prefer, or decompress them.

There are a number of options for sending attachments from the CLI.